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
>
Received on Fri Jun 22 2007 - 16:01:57 UTC