[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

+nan.0 problems

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.

 | 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].

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


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


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.