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

Re: reading NaNs

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: Thu, 27 Oct 2005 13:00:02 -0700
 | From: Alan Watson <a.watson@xxxxxxxxxxxxxxxx>
 | ...
 | 
 | I do think your suggestion of context is a good one, provided it is
 | optional and does not interfere with bit patterns. It can be
 | accomodated by:
 | 
 | (a) "write" writes NaNs with a bit pattern and a possible context
 | (for example, #<NaN #x12345ef expt>). If the implementation does
 | not support context or if the NaN is not associated with any
 | context, "write" omits it (for example, #<NaN #x12345ef>).
 | 
 | (b) "display" writes NaNs without a bit pattern but with a possible
 | context (for example, #<NaN expt>). If the implementation does not
 | support context or if the NaN is not associated with any context,
 | "display" omits it (for example, #<NaN>).
 | 
 | (c) If a bit pattern is present, "read" produces a NaN with the
 | same bit patterm. This maintains read/write equivalence.
 | 
 | (d) If no bit pattern is present, but a context is present, and if
 | the implementation supports contexts, then "read" produces a NaN
 | with the same context. This may be a different bit pattern as the
 | reading and writing implementations may encode the context
 | differently.
 | 
 | (e) If neither a bit pattern nor a context is present, "read"
 | produces a contextless NaN.
 | 
 | Basically, write/read would preserve bit patterns and display/read
 | would attempt to preserve context.  What do you think?

It looks a reasonable system for read/write invariance.

I think there is a practical problem with "designer-NaNs" in that,
unlike all other IEEE-754 number objects, they cannot be constructed
by IEEE-754 floating-point operations alone.

For example, SLIB/bytenumb.scm has R5RS code which converts between
numbers and byte representations of IEEE-754 numbers.
<http://savannah.gnu.org/cgi-bin/viewcvs/slib/slib/bytenumb.scm?rev=HEAD&content-type=text/vnd.viewcvs-markup>
In an SRFI-70 compliant implementation with bignums and flonums, all
single or double float numerical values are converted uniquely.  But
only one NaN value is converted because IEEE-754 operations provide no
way to distinguish NaNs.

Mandating more than one portable NaN value will necessitate
non-IEEE-754 mangling of flonums.  The ultimate extension of this idea
is the NaN-based pointer regimes mentioned in SRFI-70 discussions:
<http://srfi.schemers.org/srfi-70/mail-archive/msg00079.html>

 | > One could use NaNs for all sorts of purposes.  I think they are
 | > most useful when they flag impossible and unplanned-for numerical
 | > errors.

IEEE-754:1985 section 6.2:
 ...
 Quiet NaNs should, by means left to the implementor's discretion,
 afford retrospective diagnostic information inherited from invalid or
 unavailable data and results.

 | That's a valid opinion, but I do not share it.  I use them quite
 | usefully to flag possible and planned-for events for which there is
 | no other good answer.

Such reasonable disagreement is why R6RS should *not* specify a read
or write syntax for NaNs.  Implementations should be free to have
read/write syntax for NaNs or not.