[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: reading NaNs
| 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
| (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.
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:
| > 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.