[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Strong win later reversed: Real numbers have imaginary part #e0
John Cowan <cowan@x> writes:
> leppie scripsit:
>> > R6RS and R7RS-draft-8 require that (eqv? +0.0 -0.0) => #f
>> R6RS says eqv? should behave like =.
> Actually not. For one thing, 2.0 and 2 have been different in
> the sense of `eqv?` ever since R3RS.
Since R2RS actually, if one pays attention to "will return #!false"
language in the first sentences of the definition instead of the
"Generally speaking ... should be used" language near the bottom.
In the presence of the exact/inexact distinction, those two parts of the
definition contradict each other, so it is impossible to satisfy them
both. We must choose.
I'm not sure why anyone would choose to ignore the clearly stated
(and fully general) requirements in the first two sentences in favor of
the "Generally speaking ... should be used" language near the bottom.
> But what's relevant here is all that blibberty-blibber in the R6RS
> definition of `eqv?` about being indistinguishable by any finite
> composition of Scheme's standard arithmetic procedures. In particular,
> (/ 0.0) is +inf.0, and (/ -0.0) is -inf.0, so they are obviously
> distinguishable, and `eqv?` must not treat them as the same.
Indeed, thanks for pointing this out!
> As long as
> your inexact reals are IEEE binaries, you can just distinguish this one
> case and then fall back to =.
Not quite. One must handle cases such as (eqv? 1+0.0i 1-0.0i) => #f.
Also, if multiple precisions are supported (e.g. singles/doubles),
and if the result of any standard arithmetic procedure depends on the
precision of its operands, then 'eqv?' must distinguish numbers based on
precision as well. For example, if (sqrt 2.0d1) returns a more precise
answer than (sqrt 2.0s1), then (eqv? 2.0d1 2.0s1) must return #f.
Scheme-reports mailing list