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

From: Alan Watson <alan>
Date: Mon Nov 27 12:33:56 2006

Per Bothner wrote:
> Alan Watson wrote:
>
>> Be careful. A single and a double can easily have the same *value*,
>> even though their *representations* are different.
>
>
> They can be the same *number*, but not the same *value*. Just
> like the integer 1 and inexact/float 1.0.

I meant what I said when I used the word value. For mean you can have
inexact numbers with different representations, but to standard
procedures they appear to have the same values.

>> Can you come up with a description of eqv? that obtains the behaviour
>> you want on singles and doubles without reference to their
>> representation? (Not refering to "representation" is important because
>> one could implement doubles using different representations, say boxed
>> and unboxed, and one presumably wants (eqv? 0.0d0 0.0d0) to always be
>> true.)
>
>
> I'm not sure one can, but that's not needed. One can say:
>
> A flonum can only be eqv? another flonum.
> A flonum that is represented by an IEEE binary ?oating
> point number [compare 16.4 page 100, though I would refer to a
> later IEEE standard that also covers decimal floating point]
> is only eqv? another flonum that uses the same representation,
> and that is bit-for-bit equal, except that an implementation
> may optionally treat all NaN values of the same representation as
> eqv? if they are otherwise indistinguishable by procedures in [R6RS].

Ughh. Just for starters, "flonums" need not cover all of the cases; an
implementation could implement both singles and doubles but use only one
of these for "flonums". Presumable, though, one wants to specify similar
behaviour for all types of inexacts.

I think it might be easier to say that for any inexact number obj,

   (let ((x obj)) (eqv? x x))

yields #t. This makes (eqv? +nan.0 +nan.0) yield #t and allows you to
memoize, although it leaves open the possibility of different types of
NaN being either eqv? or not.

An implementor could implement eqv? on singles or doubles either as a
bitwise comparison (which would make NaNs with different bit patterns
not eqv?) or with something like:

   (or (and (nan? x) (nan? y))
       (= x y))

which would make NaNs with different bit patterns eqv?. Both of these
might be slower on implementations that use unboxed representations, but
that might be a price worth paying.

Regards,

Alan
Received on Mon Nov 27 2006 - 12:32:48 UTC