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

From: Alan Watson <alan>
Date: Fri Nov 24 15:37:34 2006

Per Bothner wrote:
> Alan Watson wrote:
>> According to page 35 of the draft, eqv? returns #t if:
>>
>> Obj1 and obj2 are both inexact numbers, are numerically equal (see =,
>> section 9.10), and yield the same results (in the sense of eqv?) when
>> passed as arguments to any other procedure that can be defined as a
>> finite composition of Scheme's standard arithmetic procedures.
>>
>> One could imagine an implementation that implemented singles and
>> doubles, but promoted singles to doubles whenever they were used in
>> arithmetic (in the style of early C compilers) and implemented
>> real->single such that it gave a single result. I think on such an
>> implementation 1f0 and 1d0 would have to be eqv?.
>
>
> The wording is wrong. It is either incomplete or non-computable.
> The intent, presumably, should be that if the implementation
> can *prove* that the values are equivalent then it can/should
> return #t. It is implementation-specific how it goes about
> doing this, but I would not consider two different
> IEEE precisions as being the same value.

Be careful. A single and a double can easily have the same *value*, even
though their *representations* are different.

Other than using eqv?, how would one distinguish between a single and a
double, when both have the same finite value? One could evaluate:

   (eq? (infinite? (+ x FLT_MAX FLT_MAX FLT_MAX))
        (infinite? (+ y FLT_MAX FLT_MAX FLT_MAX)))

(where FLT_MAX is the largest finite single). In a Scheme with singles
and doubles that preserved precision, this would indeed yield #f if x
and y were of different precisions. However, on a Scheme with singles
and doubles that promoted singles to doubles before arithmetic, it would
yield #t.

One could also evaluate:

   (string=? (string->number x) (string->number y))

This might work, but it is not guaranteed. (And further it is irrelevant
in the context of eqv? because even if string->number is considered an
"arithmetic" procedure, the useful comparision procedure on strings is
equal?, not eqv?.)

> They have the same *base type*. 9.1. does not say that singles
> and double have the same type.

I read "base type" in 9.1 to mean "a type defined in the base library"
and not as a reference to the root of a type hierarchy. I could be
wrong, and perhaps this is a place that the wording could be improved.

In practice, the main use of eqv? seems to be in making case useful for
numbers and characters. Can you give examples of why requiring (eqv?
+nan.0 +nan.0) to be true and (eqv? 1f0 1d0) to be false are useful?

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

Regards,

Alan
Received on Fri Nov 24 2006 - 15:36:36 UTC