Re: +-Inf and NaN

Here's a paper from 1982 on IEEE floats and higher level languages:
https://dl.acm.org/doi/pdf/10.1145/357162.357168
(I wrote it...)
The CL standard does not consider IEEE nuances, partly because not all
hardware
supports it, and (historically at least) those that do tend to support it
badly/expensively requiring trap handling
and other ways of avoiding yet more hardware.

The IEEE standard is more oriented toward languages like FORTRAN in which
the notion of
type is tied to a name/storage location  rather than a value.

I suppose that, even if x is a NaN,   (eq x x) should be true, since eq
should be able to compare two
memory locations and see they are the same.  (= x x), maybe not, if x is a
float and a NaN.  Should
(numberp x) be true, given it is *Not* *A Number* *?*

The details of traps and signalling NaNs presumably can be introduced to a
Common Lisp
implementation, given a compliant hardware and operating system base, but
it may be
more difficult than for C or FORTRAN.

Another look at this would be to say all objects look like floats.  Normal
floats are numbers.
NaNs are "other stuff".  For instance, the "payload" of the NaN could say
"this is a pointer to
an atom/cons/array/bignum/polynomial/...   And a whole lisp-like system
could be built around
trap handling for NaNs.

See the paper for different suggestions.  Note that the paper preceded the
adoption of the
standard, so no guarantees that it reflects entirely what happened.
I don't know if it solves any problems for NaNs, Infinities...
Note  that real numbers form a mathematical field, and computer arithmetic
sort of mirrors
the relevant operations.  Undefined (e.g. NaN) or Infinities are not
elements of the real field
and so the operations cannot always succeed  with those values.  This is an
unsatisfactory
answer as to "what should we do, nevertheless".  The IEEE standard tries to
offer some
answers, but CL was not foremost in the minds of the committee members.
Even me.

RJF


On Tue, Feb 20, 2024 at 5:13 PM Stavros Macrakis <[email protected]> wrote:

> Signaling NaNs are another matter.
>
> But preventing, say, IEEEinf-IEEEinf from returning 0 is really important
> in numeric code.
>
> On Tue, Feb 20, 2024 at 7:40 PM Henry Baker <[email protected]> wrote:
>
>> A while ago I reported some experiments with 'signalling' Nan's, and
>> concluded that they were worthless, as there wasn't enough info left
>> at interrupt time to do anything interesting, and if you built the
>> structures
>> needed to do something interesting, then you would still be better off
>> with an explicit check and explicitly branch to the corresponding code.
>>
>> I came away from that experience with a really bad taste in my mouth
>> w.r.t. NaN's, so I would be very supportive of getting NaN's out of the
>> way of doing more important things.
>>
>> -----Original Message-----
>> From: Camm Maguire <[email protected]>
>> Sent: Feb 20, 2024 3:58 PM
>> To: Robert Dodier <[email protected]>, <[email protected]>, <
>> [email protected]>
>> Cc: <[email protected]>
>> Subject: [Maxima-discuss] +-Inf and NaN
>>
>> 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).
>>
>> 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.
>>
>> 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
>> to do likewise on return, so the signatures would remain the same but
>> the user could still access the values when compiling at (safety 0).
>> Thoughts?
>>
>> Take care,
>> --
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> Maxima-discuss mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
> _______________________________________________
> Maxima-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

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