Re: Using the GNU GMP Library for Bignums in Emacs

[Paul Eggert]

Ken Raeburn wrote:
> If we’re going to treat NaNs as having distinguishable bit patterns so we can 
> tell whether two are the same or not, should we also have printable/readable 
> forms that distinguish them? If not, how do we create and use distinguishable 
> NaNs?

Good point. It'd make sense to have printable/readable forms; please see below.

> are we guaranteed that operations like (/ 0.0 0.0) will always generate NaNs 
> with the same bit pattern?

No, and this is an issue even with older Emacs. For example, (format "%s" (/ 0.0 
0.0)) returns different strings on different platforms, because some machines 
return a negative NaN whereas others don't.

> I would’ve guessed that it might be preferable to go the other direction, and 
> use one canonical NaN value in Lisp, which would thus always be eq/eql to all 
> other NaN expressions.

For some time Emacs has been able to distinguish negative from nonnegative NaNs. 
Functions like 'format' and 'copysign' depend on a NaN's sign, and (- x) 
reliably changes the sign of a NaN.

I see three ways to go here.

1. We change eql, memql, sxhash-eql, etc. to treat all NaNs alike, so that there 
is just one NaN value from the Lisp point of view. We also change 'format', 
'copysign' etc. to ignore a NaN's sign, and look through any other use of 
floating-point values to make sure that NaN signs are ignored.

2. We change eql, memql, sxhash-eql, etc. so that only the sign (not the 
significand) of a NaN is looked at, so that there are just two NaN values from 
the Lisp point of view.

3. We alter 'read', 'format' etc. to read and generate NaN significands. For 
example, (format "%s" NaN) could return "0.1e+NaN" if the significand's 
low-order bit was set.

(1) sounds too drastic, as the sign of a NaN can be useful in some cases and 
Emacs has long provided for obtaining the sign of a NaN. Although either (2) or 
(3) would be OK, I'm inclined to go for (3) as I expect it would be a bit 
cleaner and more useful.