> John Cowan wrote:
>
>> That's what is so excellent about the R6RS definition. 0/0 is undefined
>> because any number times 0 is 0, and so a NaN is a maximally inexact
>> number: it could be any real number or even +inf or -inf.
>>
That's wrong. NaN is not an interval.
All normal floating point numbers are intervals. The infinities are
half-infinite
intervals. The presence of these values in the result of an inexact
computation
amounts to an existence proof that, at all steps in the computation, it
was possible
to pick some Real in each of the intervals and come up with a Real in the
interval of the result (the particular choices not being independent of one
another, of course).
But NaN itself is not an interval. It's presence in a result is not an
existence
proof that there is some Real that is consistent with the results. That's
why NaN is infectious in computations -- it is a form of "named bottom".
Having named bottom values forces us to adjust our notion of
strictness. Procedures can be completely non-strict in an argument,
or strict in the ordinary way, or they can be "guardedly strict" meaning
that they are strict in the names of named bottom values and
ordinarily strict for all other values. The procedure DISPLAY
is an example of one that is guardedly strict with respect to NaN-type
bottom values.
What, then, of a constructor for complex numbers?
Just as non-NaN floating points represent an existence proof about
Real numbers, an ordinary COMPLEX? value should represent
an existence proof about Complex numbers.
Therefore, the result of *any* numeric computation that is
strict (ordinary sense) in a complex number *must* result in
some bottom if it is given a complex number constructed from
a NaN. If you try to construct a complex from NaN for the
real part and 1.0 for the imaginary part, then ask back for the
imaginary part, you should get NaN or some other bottom.
Otherwise, the existence proof implicit in the floating point
result fails to hold.
NaN checks are needed, therefore, but there is still room for
implementors to differ in where they should be placed. Constructing
a complex from a NaN must yield a named bottom, but it is
optional whether or not it must specifically return NaN. Some
thought is needed to figure out how writer and reader should
handle named bottoms named something other than NaN.
What matters most is that procedures which are strict (ordinary)
in their arguments, like math operators, should give a named
bottom for all named bottom argumetns (including those formed by
attempting to construct a complex from a NaN), while
guardedly strict procedures (e.g., WRITE) can still handle
these values.
-t
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.r6rs.org/pipermail/r6rs-discuss/attachments/20070622/ee462769/attachment-0001.htm
Received on Fri Jun 22 2007 - 14:26:34 UTC