[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: arithmetic issues
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