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, ...)