[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using the GNU GMP Library for Bignums in Emacs

From: Paul Eggert
Subject: Re: Using the GNU GMP Library for Bignums in Emacs
Date: Sun, 22 Jul 2018 09:44:43 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

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 

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]