| Date: Fri, 21 Oct 2005 22:03:12 -0400
 | From: "John.Cowan" <xxxxxx@reutershealth.com>
 |
 | bear scripsit:
 |
 | > >> Being error objects, syntax for NaNs should be unspecified.
 | >
 | > >I don't see how that follows.
 | >
 | > He means that NaNs should arise from error operations, not from
 | > the normal functioning of the reader.  If (read) returns an error
 | > object, it should mean that (read) encountered an error.
 |
 | Since NaN is part of the prescribed behavior of IEEE floats, it is
 | not an error object in that sense; in particular there are
 | operations defined on NaN that do not produce NaN, notably the
 | relational ones.

The total order of the reals is a crucial property for many
applications.  Any subset of the reals has a total order.  The reals
with +inf.0 and -inf.0 have a total order.

But the reals with +inf.0, -inf.0, and +nan.0 do not have a total
order [because (<= 5 +nan.0) and (>= 5 +nan.0) would both be false].

SRFI-77 states:

  This SRFI regards +nan.0 as a real number whose value is so
  indeterminate that it might represent any real number within the
  closed interval [-inf.0,+inf.0].

+nan.0 being real conflicts with the total order of the real numbers.
This could be resolved by either:

  (real? +nan.0)  ==> #f and (complex? +nan.0)  ==> #f

or

  Stop using the term `real' to refer to IEEE flonums.  How about
  RIEEEL?

			      -=-=-=-=-

The line:

  (real? +nan.0)                         ==>  #t

occurs twice in the "Numerical Type Predicates" section.

			      -=-=-=-=-

There is one occurrence of -nan.0 in SRFI-77:

  Furthermore inf.0, +inf.0, -inf.0, nan.0, +nan.0, and -nan.0 are
  external representations for flonums.