Re: IEEE Inf and NaN support for numbers.c

[Marius Vollmer]

"John W. Eaton" <address@hidden> 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 <address@hidden> before
doing this, however, since he's doing quite a rewrite of numbers
currently.