Greetings, and thanks for your feedback!
Raymond Toy <toy.raym...@gmail.com> writes:
> 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.
Why not? I agree the 'C' IEEE operator of similar name ('==') should be
left untouched, but the spec for common-lisp::= clearly implies that
the *same* NaN should be '= to itself, and even that different boxed
versions of the same bit patterns should be. I am suggesting that (/= a
a) not be a NaN detector, but to provide some other means (described
below).
I agree on 'staying close to the hardware', and one could just as well
say who cares on a practical violation of the spec. In general I am
sympathetic to such a point of view, but here it seems unnecessary.
Lisp after all is just a bunch of hardware instructions with optional
type checking layered on top :-). #'car on a long-float should trigger
an error, and does at certain safety levels, but compile at safety 0,
and one gets the 'hardware' car which will return a value however
dubious it may be. The same could be the case for '=. Say NaN was
boxed with identical layout to a long-float, but with a different
type-word denoting something orthogonal to 'number, say 'ieee-special-64
or some such. '= will then signal an error on nan input, except when
compiled at safety 0, in which case the NaN can be read as before in
boxed or unboxed form. The compiler would then simplify '= to t on
equivalent bindings, and we could use #'si::isnan or even (typep nan
'ieee-special-64) as a detector.
>
> 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 don't think so. (typep a '(or b c)) == (or (typep a b) (typep a c))
> 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.
>
It means that NaN does not fit into a total ordering scheme of say
long-floats, and the type explicitly recognizes and denotes ordered
subsets.
> 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.
>
I think we can have our cacke and eat it too. We can still compile at
safety 0 and proceed with errors optionally triggered only when setting
FPE traps. But when interpreted or compiled with safety, standard type
errors would be triggered.
> The subject also mentions +/= inf. Did you forget to mention issues
> with infinities?
>
I am much less bothered by these, though they do make
most-positive-long-float meaningless. They are in fact quite useful in
bounds checking arithmetic in the compiler. Maybe
most-positive-long-float == +inf?
Can anyone without too much effort summarize how other lisps handle
this? Can one access/manipulate nan at the lisp prompt level?
Take care,
> Take care,
> --
> Camm Maguire c...@maguirefamily.org
> ==========================================================================
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
--
Camm Maguire c...@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
