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

From: Arthur Smyles <atsmyles>
Date: Fri, 22 Jun 2007 13:57:40 -0400

John Cowan wrote:
> Arthur Smyles scripsit:
>
>> That is precisely why [NaN] is not a real number. There is no one to one
>> correspondence to a line in the case of a NaN
>
> *Every* inexact number represents a segment of the real number line
> (or a region of the complex plane, if you prefer), finite in the case
> of the rationals, infinite in the case of +inf and -inf and +nan.

  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. So the ratio 1/3 would be exact, but (div 1
3) would be inexact. It's irrelevant as far as what type of number a NaN
is.
Second, +inf and -inf are not ranges they are points. They lay on both
ends of the real numbers, they follow most of the properties of real
numbers, and it is established in mathematics. 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.


>
> Floating-point arithmetic is not real arithmetic; it's not even
> associative.
>
>> The question is: what should (nan? nan.0+1i) return. First, NaN is
>> created by an indeterminate form. Second, NaN is contagious since any
>> mathematical operation that recieves it, must return it. Therefore it
>> should return #t.
>
> Currently nan? is only defined on real numbers, and ditto finite?
> and infinite? I wouldn't be opposed to extending those to complex
> numbers.

nan? should return true if it's argument is a NaN, false otherwise.
>
>> And finally simplifying the complex number constructor to return a NaN
>> if either the real or imaginary parts are NaN.
>
> 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.
Besides, you would never create a complex number for nan.0+1i, you would
convert it to nan.0 instead.

  The whole point of NaN is *not to have to
> check* until the inner loop finishes: only then do you find out whether
> your results are rubbish.
>

My proposed changes don't affect that.

Arthur
Received on Fri Jun 22 2007 - 13:57:40 UTC