On Wed, May 9, 2012 at 1:45 AM, Ray Dillinger <[email protected]> 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
[email protected]
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
