Formal comment #11 (defect)

NaN is not a real number
Reported by:	Aubrey Jaffer

Component:	arithmetic
Version:	5.91

Page 10: 2.4. Infinities and NaNs 

A NaN is regarded as a real (but not rational) number whose value is
so indeterminate that it might represent any real number, including
positive or negative infinity, and might even be greater than positive
infinity or less than negative infinity.

+inf.0 and -inf.0 are real numbers because they are part of the total
ordering of that subset of the real numbers represented in Scheme. NaN
is not part of that ordering; thus it is not a real number. It is,
however, a complex number.

(/ 0.0 0.0) is NaN because any finite number satisfies the equation: 
  z * 0.0 = 0.0.

And that includes any finite complex number! Restricting NaN to be
real is wrong.

In page 10, "2.4. Infinities and NaNs", I propose the sentence should
be changed to read:

A NaN is regarded as a complex number whose value is so indeterminate
that it might represent any complex number.

On page 38, the line: 
  (real? +nan.0) ==> #t

should be changed to: 
  (real? +nan.0) ==> #f

Because it doesn't participate in the ordering, +nan.0 is not an
acceptable argument to numerical-ordering predicates (<, <=, >, >=,
negative?, positive?, etc).

On page 100, the lines 
  (fl= +nan.0 fl) ==> #f
  (fl< +nan.0 fl) ==> #f

should be removed.

RESPONSE:

In the draft R6RS, a NaN is regarded as a real (but not rational)
number.  To make NaNs non-real, as formal comment #11 proposes, would break
the primary closure property that allows the operations of (r6rs
arithmetic flonum) to be implemented efficiently, often as a single
machine instruction.  Formal comment #11 would also degrade the performance
of generic arithmetic on flonums in compilers that use flow analysis
to improve the efficiency of generic arithmetic.

To forbid comparisons between a NaN and a flonum, as Formal comment #11
proposes, would be incompatible with other programming languages'
interpretations of IEEE-754 and with hardware, making it more
difficult for Scheme to interoperate with other languages or to
make effective use of standard hardware.

In particular, the IEEE-754 standard requires equality tests
that involve a NaN to come out false.  If the central proposal
of Formal comment #11 were accepted, then implementations of Scheme
could not implement inexact real arithmetic that is compatible
with IEEE-754 or IEEE-754R.