Re: +-Inf and NaN

The timing of the standardization is somewhat beside the point, because the
design
of the IEEE floating point goes back quite a bit in time. The CL was forced
on the
community by DARPA, where people were concerned about the incompatibility of
Interlisp (BBN lisp) Maclisp, Stanford, CMU Lisp, and several Lisp machines
Symbolics, LMI, PERQ, Dandelion, ....

IEEE float came out of a collaboration between Kahan (at Berkeley) and
people in
industry, mostly Intel, Motorola, National Semiconductor, Zilog. It started
circa 1977
The AI lab people at MIT, Stanford, CMU were not interested in floats
(except maybe Guy Steele Jr).
Their prime directive was to steer CL to be compatible with whatever they
were already doing.
Thus the UNIX/Berkeley suggestions that CL should use upper and lower case
was rejected
out of hand, because the heritage PDP-10 36-bit word dictated otherwise...
etc.  Vax "franz lisp",
the widest used implementation of lisp was disparaged..

So the idea that other foreign thoughts (like IEEE NaNs) should invade the
historical precedent
of PDP-10 Lisps was not much considered.



On Wed, Feb 21, 2024 at 2:01 PM Raymond Toy <[email protected]> wrote:

>
>
> On Wed, Feb 21, 2024 at 1:20 PM Stavros Macrakis <[email protected]>
> wrote:
>
>> On Wed, Feb 21, 2024 at 1:46 PM Raymond Toy <[email protected]>
>> wrote:
>>
>>> ...
>>> I think CLHS isn't really super clear on IEEE floats.
>>>
>>
>> CL was defined before IEEE floats existed.
>>
>
> I used to think that too, so I checked before I wrote that.
> https://en.wikipedia.org/wiki/Common_Lisp says ANSI CL was published in
> 1994.  IEEE-754 <https://en.wikipedia.org/wiki/IEEE_754> came out in
> 1985.  But perhaps the basics were already set in CL via CLtL2 in 1984 or
> so, and not much got updated afterwards.  CLtL2 does mention signed numbers
> (I think) and uses some definitions of the special functions from Kahan,
> who was intimately familiar with IEEE-754 and signed zeroes.
>
>> ...I agree with what Robert says.  Compilation safety here should change
>>> the computed results for valid inputs.
>>>
>>
>> I think you mean *should not change*, right?
>>
>
> Sorry, yes. I meant they should not change.
>
>>
>> >  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
>>>>
>>>
>> Don't agree. If you're doing a calculation with more than one result, it
>> is perfectly reasonable for some of the results to be NaNs and other
>> results to be valid. Aborting the calculation is not the right thing to do.
>>
>> Ray Toy:
>>
>>> NaN is an important part of preventing numeric calculations from giving
>>> incorrect results.
>>>
>>
>> Not quite sure what you mean by this because NaN is, in a sense, an
>> incorrect result because we couldn't represent what was asked, like 0d0/0d0
>> or inf-inf.
>>
>>
>> It isn't "incorrect", it's invalid. And arithmetic with it should
>> preserve invalidity. The incorrect result happens if 0.0*NaN gives 0.0
>> rather than NaN, so you think you have a valid result when you don't.
>>
> Ok, I understand what you're saying.
>
> --
> Ray
>

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