[r6rs-discuss] [Formal] Formal Comment: NaN should be considered a number, not a real

[Arthur Smyles]

William D Clinger wrote:
> Arthur Smyles wrote:
>>   Your concept of inexact numbers is incorrect. An inexact number with
>> respect to the standard, has to do with whether a computer can represent
>> the number perfectly or not.
> 
> Your understanding of inexact numbers in Scheme is
> incorrect.  With respect to the Scheme standards,
> 1.0 is inexact, and that has nothing to do with
> whether the computer is capable of representing
> the number 1.

I agree, because it uses the floating point number. See slide 42 from
your links earlier.

> 
>> NaN follows none of those
>> properties. Further, there is no concept of it for any description of
>> reals that I have read. If there is a mathematical basis for it to be a
>> real, please enlighten me.
> 
> Mathematically, IEEE double precision floating point
> numbers are the union of these disjoint finite sets:
> 
>     2^64 - 2^53 - 3 specific rational numbers
>     { -0.0 }
>     { +inf.0, -inf.0 }
>     2^53 error values, known as NaNs
> 
> The NaNs are regarded as reals because that fiction
> causes the IEEE double precision "numbers" to remain
> closed under all of the standard arithmetic operations.

IEEE does not have a concept of complex numbers, hence why (sqrt -1)
would also produce NaN. However we need to integrate complex numbers and
still be compatible.

> 
> This is a useful fiction.  It is also an important part
> of an IEEE standard.  For an explanation, I recommend
> David Goldberg's paper on "What Every Computer Scientist
> Should Know About Floating-point Arithmetic", especially
> the sections on NaNs and infinities [1].  See also Doug
> Priest's addendum to that paper [2].
> 
>>> That's where the sticky bit is.  Instead of compnum addition involving
>>> adding real parts and imaginary parts, there now have to be complicated
>>> and annoying NaN checks.
>> No. Anytime you do any mathematical operation with a NaN, the result
>> must be a NaN, according to IEEE. So it has to be checked anyway.
> 
> That checking is already being done by hardware, thanks
> to near-universal acceptance of the IEEE-754 treatment
> of NaNs.  If Scheme were to prescribe a semantics for
> NaNs that is at odds with the IEEE-754 standard and with
> current hardware, then Scheme's arithmetic operations
> could not rely on the hardware to deal with NaNs; extra
> checks would be required in software, and arithmetic
> would become correspondingly slower.
> 
> The advantages of ignoring established standards do not
> compensate for the disadvantages of being unable to use
> current hardware effectively.
> 
> Will

I completely agree. The changes that I've requested would not affect the
 calculations using NaN. I only want it's user visible type changed. So

Changes

(real? nan.0) => false
(complex? nan.0) => false

These would still hold
(number? nan.0) => true
(nan? nan.0) => true
 All IEEE-754 mathematical operations with nan.0

In addition to mathematical consistency, I believe these changes are
perfectly compatible with IEEE-754.

Arthur
> 
> 
> [1] David Goldberg.  What every computer scientist should
> know about floating-point arithmetic.  ACM Computing
> Surveys, 23(1), March 1991, pages 5-48.  Online at various
> places, including http://www.validlab.com/goldberg/paper.ps
> 
> [2] Doug Priest.  Differences Among IEEE 754 Implementations.
> Addendum to the Goldberg's paper [1].  See p 248-264 of
> http://www.validlab.com/goldberg/paper.ps
>