[r6rs-discuss] [Formal] Formal Comment: NaN should be considered a number, not a real

From: Thomas Lord <lord>
Date: Fri, 22 Jun 2007 15:54:06 -0700

You should understand "nan" to mean "a value that may
be passed to math operations without causing an error but
which we do not know is or is not a number". They
call nan "not a number" but, really, it is "don't know if it
is a number or not".


(let ((x ...well, not sure exactly. It might be
               a number or it might not...))
  (real? x))

=>

...well, not sure if that's supposed to be true, or
   false, or just an error...



So, "nan.0" is "...might or might not be a number...".

And "#NaB" (aka "not a boolean") is "....not sure....".



>>> These would still hold
>>> (number? nan.0) => true
>>>
>>>
>> No way, please. A NaN result from an
>> FPU signals that no proof has been found that any
>> number exists which is the requested result.
>>
>>
>
> But then operations on numbers is no longer algebraically closed. I
> think that this is an important property to maintain.
>
>


It's important (for performance and simplicity of code) that the math
operations
like + - * / are closed. They would be, under NUMERIC?, see below.


-t



>> The most logical thing would be to have two procedures:
>>
>> NUMERIC?
>> and
>> NUMBER?
>>
>> NUMERIC? returns #t only if its argument can be
>> passed to math operations without causing an error.
>>
>> NUMBER? returns #t only if there exists a number
>> consistent with the history of how its argument was
>> computed.
>>
>>
>> (number? nan.0) => #NaB
>> (numeric? nan.0) => #t
>>
>>
>>
>>
>>> (nan? nan.0) => true
>>> All IEEE-754 mathematical operations with nan.0
>>>
>>>
>>>
>> Yes. NaN is a bottom value but there can still be some
>> type structure among bottom values that can be effectively
>> recognized.
>>
>> -t
>>
>>
>
>
Received on Fri Jun 22 2007 - 18:54:06 UTC