[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
| Date: Fri, 21 Oct 2005 22:03:12 -0400
| From: "John.Cowan" <jcowan@xxxxxxxxxxxxxxxxx>
| 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].
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
Stop using the term `real' to refer to IEEE flonums. How about
(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.