On Oct 23, 2005, at 2:39 PM, Thomas Bushnell BSG wrote: > Aubrey Jaffer <xxxxxx@alum.mit.edu> writes: > > >> | 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> >> > > 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, ...)
