From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: IEEE Inf and NaN support for numbers.c Date: 24 Apr 2002 21:11:51 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <87g01koqrs.fsf@zagadka.ping.de> References: <15494.39950.119995.223196@segfault.bogus.domain> <87lmcuyifu.fsf@zagadka.ping.de> <15514.19909.408835.204209@segfault.bogus.domain> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1019678607 1474 127.0.0.1 (24 Apr 2002 20:03:27 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 24 Apr 2002 20:03:27 +0000 (UTC) Cc: guile-devel Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 170Sz9-0000NQ-00 for ; Wed, 24 Apr 2002 22:03:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 170Syu-0002qZ-00; Wed, 24 Apr 2002 16:03:12 -0400 Original-Received: from dialin.speedway42.dip97.dokom.de ([195.138.42.97] helo=zagadka.ping.de) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 170S7k-0003xg-00 for ; Wed, 24 Apr 2002 15:08:16 -0400 Original-Received: (qmail 8420 invoked by uid 1000); 24 Apr 2002 19:11:51 -0000 Original-To: "John W. Eaton" In-Reply-To: <15514.19909.408835.204209@segfault.bogus.domain> Original-Lines: 94 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:505 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:505 "John W. Eaton" writes: > | > guile> (/ 0) > | > Inf > | > | This is not a good print syntax for the new "inf" value. It looks > | like a symbol, while it really is a number. Likewise for "NaN". > | > | What about using "1/0" for inf and "0/0" for NaN. Does this fit with > | the IEEE rules? > > I suppose it would work, but it is a bit misleading, because Inf and > NaN can be generated in ways other than just 1/0 and 0/0. Yes, it also touches on the issue of exactness. 1/0 would be an exact infinity, while we can currently only produce inexact exceptional values. We would need to write #i1/0, which is not as elegant. > | When this works, we don't need the 'inf' and 'nan' procedures. > > Sure, but perhaps it is nice to have a way to request a NaN or Inf > value without having to perform additional arithmetic operations? The 1/0 construct would be specially recognized as meaning infinity. In case you are not aware of it: x/y is Scheme syntax for literal fractions. (Guile does not have exact rationals, but it might in the future.) These fractions are 'evaluated' by the "read" function, not as part of running the program. The fraction "1/0" can be specially recognized by "read" and converted to IEEE +infinity (just as "23" is converted into the integer 23). I'm only really concerned here about read/write consistency. Say you compute some list of numbers, write them to a file with "write", and read them back in with "read". The new list should contain the same numbers, of course. When you write something like (1 2 Inf 4) and read this back in, you will get a list with two numbers, a symbol, and another number. Therefore, we need to find a way to represent infinity and the other exceptional values that doesn't clash with the rest of Scheme syntax. (I think you know all this, but I couldn't stop myself from exlaining it anyway.) The cleanest way that I can think of right now is to use the hash-comma reader extension: #,(+inf) #,(-inf) #,(nan) #,(nan 0.42345) Unfortunately, this mechanism is optional and currently only available when (srfi srfi-10) has been loaded. We would need to make it mandatory, which is entirely reasonable, I'd say. PLT Scheme uses +inf.0 -inf.0 +nan.0 which are not really numbers, syntaxwise, but I think its OK to make this extension. The PLT Scheme docs say specifically: The following are inexact numerical constants: +inf.0 (infinity), -inf.0 (negative infinity), +nan.0 (not a number), and -nan.0 (same as +nan.0). These names can also be used within complex constants, as in -inf.0+inf.0i. The special inexact numbers +inf.0, -inf.0, and +nan.0 have no exact form. Dividing by an inexact zero returns +inf.0 or -inf.0, depending on the sign of the dividend. The infinities are integers, and they answer #t for both even? and odd?. The +nan.0 value is not an integer and is not = to itself, but +nan.0 is eqv? to itself. Similarly, (= 0.0 -0.0) is #t, but (eqv? 0.0 -0.0) is #f. Does this sound reasonable to you? If yes, can you adapt your patch accordingly? > Eventually, I'd like to be able to make it possible to control what > happens when Inf and NaN are generated. For example, generate an > exception instead of simply continuing. In that case, it might be > good to have another way to get at Inf and NaN without generating the > exception. Yes, there is no problem with having procedures that return Inf and Nan, etc. Sorry for giving the impression that I didn't want them. > BTW, would people object to reformatting numbers.c to follow the GNU > coding standards? I wouldn't. Please talk to Rob Browning before doing this, however, since he's doing quite a rewrite of numbers currently. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel