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 this: #<not-a-number expt>Sure, that seems fine. We could mandate that as the readable written representation!
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, ...)