Re: [Scheme-reports] EQV? on numbers should be based on operational equivalence

[Emmanuel Medernach <emmanuel.medernach@x>]

On Wed, May 9, 2012 at 1:45 AM, Ray Dillinger <bear@x> wrote:

Internal objects (characters, numbers, etc) ought to be treated
purely as values.  If there is a "hack" by which we can see their
bit layouts, or even distinguish bit layouts of otherwise operationally
identical objects, I say that an abstraction barrier has been violated
and the bug that allowed it needs to be fixed.

 

Thanks for sharing your opinion. I agree with you that the binary format of a particular NaN is not that interesting.

I think we have to remind what are the purpose of NaNs :

  - allowing computation to continue even in the presence of incorrect computation, instead of aborting with an error.
  
  - to be able to discover what kind of error has been encountered if needed, by propagating NaN value.

    For instance, some even recommends to use NaNs value to uninitialize arrays of reals. In that case, the NaNs could contain the index in order to help debugging.
    
If one implementation distinguishes NaN then :

  - it may simply have only one general value for NaN.
  
  - or be IEEE 754 conformant. In that case, There is not a unique NaN value, but a set of NaNs values.

    - From the purpose of NaNs IMHO we have to be able to distinguish between NaNs. John suggests to have a WG2 "dissecting NaN" library for that and I agree with him.
    
    - The IEEE standard recommends to provide a function to distinguish NaNs but if no function is provided then the test (= x x) has to be false for a NaN. IMHO it is merely an hack.

A few design questions:

  - Do we really need the reader to be able to read NaN ? What are the use cases ? 
  
  - As we provide nan? do we have to follow the IEEE advice about (= x x) => #f ?
  
Cheers,
--
Emmanuel
_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports