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

From: Arthur Smyles <atsmyles>
Date: Fri, 22 Jun 2007 17:17:12 -0400

Thomas Lord wrote:
> Arthur Smyles wrote:
>> Changes
>>
>> (real? nan.0) => false
>> (complex? nan.0) => false
>>
>
> Honestly? No.

Well then you're not going to like the current spec either which says
that those operations return true.

>
> It would make more logical sense to add a new value
> to the language, "#NaB" (pronounced, "not a boolean"),
> and have:
>
> (real? nan.0) => #NaB
> (complex? nan.0) => #NaB
>

I thought of these functions as describing sets(types) of numbers. So
you could determine whether NaN is in that set or not.

>
> The following should be (an example of) an error:
>
> (if #NaB 'yes 'no) => ...error...
>
>
> NaN is a bottom value and (ordinary) type predicates are strict in
> the type of their arguments. Bottom values have no
> type other than "bottom".
>
> (real? _|_) => _|_
>
> therefore
>
> (real? nan.0) => #f
>
> is bogus.
>

I interpret the real? function differently from you. (real? _|_) is
asking is the bottom value real? We both agree that the answer is no. So
 I don't understand why you can't say #f.


>
>
>
>
>> 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.

> 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 - 17:17:12 UTC