[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: arithmetic issues

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.



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!