[Gcl-devel] Re: printing IEEE 754 special values (inf, nan)

[Raymond Toy]

Robert Dodier wrote:
> Hi Ray, you wrote:
>
>
> > I think that if you have readable NaN's, you should make
> > it so that what you read is what was written.  It would
> > certainly break people's expectation if all printed NaN's
> > got read as the same NaN.
>
>
> Well, I'm not sure that anyone actually expects the
> input string "NaN" to read the same as the floating point
> object of which it is a representation.

Well, in lisp, an input string "Nan" is a string. :-)


> For what it's worth, the two numerical packages
> I'm familiar with, Octave and R, both allow NaN to be
> read in as a string, and it's the same string that is
> printed to represent any floating point NaN.
> I claim this is evidence indistinguishable NaN's are OK.

And I see it as evidence that they don't care.  Should Lisp care?  I 
don't really know.

> > Also, I think implementations are free to encode whatever
> > they want in the bits, so it might be important for the 
> > implementation.  But I might be wrong here.
>
>
> Does any Lisp implementation do so? Does CMUCL? GCL? 

Do what?  Encode stuff?  I doubt it, and I'm pretty sure CMUCL doesn't 
do anything to the NaN.  The stuff I was thinking of comes from the FPU 
itself.  It might encode information about what caused the NaN or 
something.  Anyway, I don't think the spec really says anything about 
NaN except when they occur.  And any information in them would certainly 
be implementation specific.

Also, there are 2 types of NaN's: signaling and non-signaling.  I think 
signaling NaN happens when the FPU is set to trap on NaN.  Non-signaling 
is what you get when the NaN exception is masked.  This is why CMUCL 
prints out #<Quiet double-float NaN> (or something like that).

Anyway, I suspect 99 and 44/100% of the people don't care about NaN.

Ray