Email list hosting service & mailing list manager


Re: arithmetic issues Aubrey Jaffer 23 Oct 2005 18:18 UTC

 | From: Thomas Bushnell BSG <xxxxxx@becket.net>
 | Date: Sat, 22 Oct 2005 17:47:25 -0700
 |
 | Aubrey Jaffer <xxxxxx@alum.mit.edu> 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>