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

Re: +nan.0 problems

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.




On Sun, 23 Oct 2005, John.Cowan wrote:

>Aubrey Jaffer scripsit:
>
>> SRFI-77 states:
>>
>>   This SRFI regards +nan.0 as a real number whose value is so
>>   indeterminate that it might represent any real number within the
>>   closed interval [-inf.0,+inf.0].
>
>Thanks for pointing this out.  The SRFI is of course wrong:  the paradigm
>case of +nan.0 is (/ 0.0 0.0), and the value of this is not any of the
>real numbers.

Ehhh. 0.0 is such a beast anyway....  An 0.0 encountered in source
code is zero, but one "encountered in the wild" as a result of
computation is frequently just an underflow - a real, nonzero
number that is nevertheless too small to be represented in
whatever format the implementation uses.

If both your 0.0's happen to be underflows in this sense, then the
actual value of the above expression is in fact a "real number whose
value cannot be determined."  But if, as in source, both are truly
zeros, then it's an error operation and you have a clear case for
a NaN.

Anyway, in a programming language you have to make a decision about
what the expression returns, because if you're using IEEE floats, you
can't tell the difference between an underflow and a zero.

				Bear