> (numberp (/0.0 0.0)) returns t. That seems like a bug to me.
Maybe it is, maybe it isn't. (elisp)Arithmetic Operations says:
If you divide an integer by 0, an `arith-error' error is signaled.
(*Note Errors::.) Floating point division by zero returns either
infinity or a NaN if your machine supports IEEE floating point;
otherwise, it signals an `arith-error' error.
So if the machine supports IEEE floating point (most modern machines
do), you aren't supposed to get `arith-error' in this case. Maybe
this is a bit counter-intuitive for someone who never did futz with
NaNs, but at least Emacs behaves consistently with the docs.
I didn't say above that (/0.0 0.0) should give `arith-error'. I suggested
that perhaps `numberp' should return nil for a NaN argument, since "NaN"
means "not a number" and "numberp" means "a number". NaN is a floating-point
value, but is it a number?
As for a way to test for a NaN, try this:
(= (/ 0.0 0.0) (/ 0.0 0.0))
It should evaluate to nil, since a NaN is defined to fail _any_
arithmetic comparison, even a comparison to itself.
That doesn't tell me how to test if `foobar' is a NaN. See my previous
email: I knew I could test `(equal foo 0.0e+Nan)', but I thought I would
need to test against all of the possible NaN values.
A bit of experimenting shows, however, that, at least on my system, the
mantissa doesn't matter: (equal 0.0e+NaN -0.0e+NaN) is `t', as is (equal
1.0e+NaN -99.5e+NaN). There is effectively only a single NaN value.
So I guess the answer to my original question is this:
(and (condition-case nil (setq foo (/ 0.0 0.0)) (arith-error nil))
(not (equal 0.0e+NaN foo)))
Ugly, perhaps, but usable.
BTW, here is something I didn't expect:
`M-: 0.0e+NaN' returns -0.0e+NaN
`M-: -0.0e+NaN' returns 0.0e+NaN
The reader seems to flip the (irrelevant) sign.
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
