John Cowan wrote:
> Arthur Smyles scripsit:
>
>> NaN describes specific situations in math that are undefined, like
>> 0/0.
>
> That's what is so excellent about the R6RS definition. 0/0 is undefined
> because any number times 0 is 0, and so a NaN is a maximally inexact
> number: it could be any real number or even +inf or -inf.
That is precisely why it is not a real number. There is no one to one
correspondence to a line in the case of a NaN
See
http://en.wikipedia.org/wiki/Category:Real_numbers
The same
> story with (- +inf +inf) and its algebraic equivalents, which is the other
> main way to generate a NaN.
FYI:
http://en.wikipedia.org/wiki/Indeterminate_form
http://en.wikipedia.org/wiki/NaN
>
> As long as complex numbers are primarily viewed as rectangular and
> potentially of mixed exactness, it's quite plausible to allow NaN as
> either componenent. Mathematically, you could allow NaN to be
> a non-real complex number, but pragmatically that turns out to be
> undesirable, given the behavior of floating-point hardware.
> Doing so requires every floating point operation on real and imaginary
> parts to include an extra check.
>
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. Might as well represent it as such when constructing
the complex number. Also, it just so happens that it is not a complex
number according to this definition:
http://en.wikipedia.org/wiki/Complex_number. A complex number requires
that in a+bi, a and b must be reals.
Further, This simplification is both cheaper in terms of memory and
processing.
Further, not fixing this increases the burden of users of the language.
Right now, I'd have to create functions really-real? and really-complex?
in order to find out what it is.
The changes that are required is minimal. Here they are:
(complex? +nan.0) => #f
(real? +nan.0) => #f
And changing the language for the definition of a NaN to(I've changed
this from my formal comment):
"NaN is an indeterminate number"
And finally simplifying the complex number constructor to return a NaN
if either the real or imaginary parts are NaN.
Perhaps it would also be wise to look at any math in the arithmetic
model that is unspecified and use NaN or throw an error instead.
I don't believe the rest of the arithmetic model needs to change since
the IEEE spec handles NaN properly.
Arthur
Received on Fri Jun 22 2007 - 10:40:10 UTC