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

On Thu, 27 Oct 2005, Aubrey Jaffer wrote:

> The precision available in NaNs is a hardware attribute.  How can it
> be settable?

It seems that most current hardware supports several different 'widths'
of floating-point numbers.  Also, the concept of NaN is easily applicable
to extended float types handled in software.

> If program B reads lists, association lists, or vectors containing
> numbers, then your approach must descend data structures looking for
> NaNs -- all this effort for a case which shouldn't occur.  Should this
> input vetting also check for embedded end-of-file objects?

See, I have a different problem.  Suppose implementation A has a
wider floating-point representation than that in implementation B,
or bignums in vector indices (probably with a sparse-vector
implementation underneath) and implementation B doesn't.  When A
produces a datastream for B to read, it may include a floating-point
format of greater magnitude than B can read, or a vector whose
indices exceed what B's can represent.  So, deep down inside the
reader, something returns a NaN, signals, and traps, with the
reader returning the NaN.  From the call site, the difference
between this "live error" NaN and a NaN that has merely been read
may not be obvious.

Similar things are going to happen when one implementation supports
the new decimal formats in IEEE-754R and has exact decimal floating-point
constants, and another implementation doesn't, or whatever.  We have
to be able to tell the difference between a read error and a NaN
result being correctly read.

So if we're going to have a NaN read/write syntax, we *MUST* require
implementors to guarantee that, no matter what, their reader will
never throw an error and return a NaN. More generally, we have to
have a defined behavior for what read has to do when it reads an
object that cannot be represented in its own implementation - for
example an IEEE-754R exact decimal float in data to be read by an
implementation that doesn't use that representation.  If it silently
coerces all floats to inexact, the program may be incorrect as a