[r6rs-discuss] Re: [Formal] eq?/eqv? misbehave around NaNs

From: Alan Watson <alan>
Date: Thu Nov 23 16:37:11 2006

Per Bothner wrote:
> Alan Watson wrote:
>
>> Per Bothner wrote:
>>
>>> Is there any scenario where you'd want anything other than:
>>>
>>> (eqv? +nan.0 +nan.0) => #t
>>
>>
>> If inexacts are unboxed and +nan.0 has only one representation, then
>> the implementor can most simply implement eqv? on inexacts with a
>> bitwise comparison. In this case, you get #t.
>>
>> If inexacts are boxed, then the implementor can most simply implement
>> eqv? on inexacts with a numerical comparison. In this case, you get #f.
>
>
> "can most simply implement" != "you would want" or "the right thing".

Yes, but it can mean "the right thing in the absence of a good argument
against this".

> If inexacts are boxed, then the implementor can easily implement
> eqv? on inexacts by comparing their bits.
>
> I think it is important to not break:
> (eq? x x) implies (eqv? x x)
> and:
> (let ((x expr)) (eq? x x))
> which seems to imply little choice but:
> (eqv? +nan.0 +nan.0) => #t

I agree that it is important not to break these, but I believe you can
get around this by implementing eqv? roughly as:

   (or (eq? x y)
       (if (and (number? x) (number? y))
           (= x y)
           ...))

This would mean, for example, that

   (let ((x +nan.0) (y +nan.0)) (eqv? x y))

need not yield the same result as

   (let ((x +nan.0)) (eqv? x x))

but I think something like this is inevitable when you try to combine
Scheme's ideas about eq? and eqv? with IEEE 754-1985's ideas about NaNs
and =.

Regards,

Alan
Received on Thu Nov 23 2006 - 16:36:10 UTC