Re: +-Inf and NaN

Re: hardware:

Hmmm...   In just the Intel processor category, there are probably millions of combinations
of HW specs, so 'close to the HW' is exceedingly ill-defined.  E.g., I understand that Windows-11
will no longer boot on Intel HW that doesn't have a popcount instruction ?!?

Re: Common Lisp:

Common Lisp is a dead language, in the sense that there is no existing organization that can
make any changes/improvements to the CL spec.  We're in roughly the same position as the
Supreme Court, which can 'interpret' the language spec, but can't (shouldn't ?) make any changes.
CL's current viability depends critically on *backwards compatibility*, so destroying that compatibility
will also eliminate the value of the CL language.

Re: IEEE 'compatibility':

The GPU folk have moved well beyond the original IEEE float spec, and given the $$$$ behind
them, you're not going to be able to fight their interpretations.  Better look to them for inspiration
of how to proceed.

-----Original Message-----
From: Camm Maguire <[email protected]>
Sent: Feb 21, 2024 7:55 AM
To: Raymond Toy <[email protected]>, Stavros Macrakis <[email protected]>, Richard Fateman <[email protected]>, <[email protected]>
Cc: <[email protected]>, Robert Dodier <[email protected]>, <[email protected]>
Subject: Re: [Maxima-discuss] +-Inf and NaN

Greetings, and thanks for your feedback!

Raymond Toy 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 [email protected]
> ==========================================================================
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah

--
Camm Maguire [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah


_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss