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

Re: reading NaNs

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 wrote:
 | Aubrey Jaffer wrote:
 | > Having a universal read/write representation for arbitrary bit
 | > patterms prevents including information like the procedure
 | > causing the NaN in its printed representation.
| | I don't see this. Can you elaborate?

Suppose Scheme implementation X distinguishes NaNs by the procedure
producing them and makes that information part of the printed
representation for NaNs:

  (expt +inf.0 0)    ==>  #<not-a-number expt>
  (+ -inf.0 +inf.0)  ==>  #<not-a-number +>
  (/ (* 0 -inf.0) 3) ==>  #<not-a-number *>
  (+ 5. (/ 0.0 0.0)) ==>  #<not-a-number />

If R6RS has a universal read/write representation for arbitrary bit
NaN patterns, then R6RS must assign bit patterns for all possible
#<not-a-number {*}> syntaxes.  If some future IEEE-754 hardware
returns more than one NaN code, then its assignments are very unlikely
to match the R6RS codes.

To me a compromise would be to standardize a simple #<not-a-number>;
implementation X can allow users to change how NaN are to be printed
via parameters (in the srfi-39 sense).

Btw - I agree that #<not-a-number +> is a little more helpful than
#<not-a-number> during debugging, but if there is no source location
information to find the actual + producing the NaN then the
helpfulness is limited.

Jens Axel Søgaard