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

Re: arithmetic issues

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 Oct 23, 2005, at 2:39 PM, Thomas Bushnell BSG wrote:

Aubrey Jaffer <agj@xxxxxxxxxxxx> writes:

 | From: Thomas Bushnell BSG <tb@xxxxxxxxxx>
 | Date: Sat, 22 Oct 2005 17:47:25 -0700
 | Aubrey Jaffer <agj@xxxxxxxxxxxx> writes:
 | > ...
| > That still prevents an implementation from displaying information
 | > about what type of NaN was returned.  Such information could be
 | > helpful to find the call which generated the NaN.
 | Huh?  How does it prevent such?  We *could* mandate a readable
| written representation for NaNs without manding that printing a NaN | should produce that representation, since it would still be allowed
 | to signal an error.  (And then, once it is signalled, it could
 | print *anything it wants*.)
| Moreover, nothing prevents the mandated written representation from
 | optionally including implementation defined contents, if that
 | should be useful.

When different NaNs are returned depending on the circumstances
creating them, I would like my implementation to display them like

  #<not-a-number expt>

Sure, that seems fine.  We could mandate that as the readable written

If "expt" means exponent, then you don't get any more information--- in IEEE arithmetic, the exponents of all NaNs of a given precision are the same.

Brad (who doesn't really want to get into this, ...)