Greetings! I know this has been discussed before, but I would like to
explore the possibility of defining these bit patterns as members of a
special type orthogonal to common-lisp::number. This is prompted by the
NaN blockage on the compiler optimizing (= a a) (or equivalent bindings)
to t, and indeed the common lisp spec appears to specify that eq implies
=. I think maxima tries to detect NaNs using (/= a a).
When a is a floating-point number (= a a) should not be optimized to T. Likewise (/= a a) should not be optimized to NIL. I'm pretty sure IEEE754 says that NaN is never = to itself or another NaN or any other number.
We also have the following charming behavior:
(typep nan 'long-float) ->t
(typep nan '(long-float 0) ->nil
(typep nan '(long-float * 0)) ->nil
(typep nan '(or (long-float 0) (long-float * 0))) ->nil
but the first and last types are of course identical.
Isn't the last one a bug? Should the compiler convert (or (long-float 0) (long-float * 0)) to just long-float?
I'm not sure what the second and third cases returning nil really means in practice. I think even if you declare a function as only taking and returning (long-float 0), you can have operations return NaN, even if the inputs are non-negative floats.
If NaN was truly 'not a number', the numerical functions would trigger
an error on input only when compiled with safety, and might be arranged
I think I would defer to whatever the HW does and the floating point traps that are enabled. If the invalid trap is enabled, then we get errors. If the invalid trap is disabled, NaN gets returned.
The subject also mentions +/= inf. Did you forget to mention issues with infinities?
Take care,
--
Camm Maguire camm@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah