[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers
> Noah Lavine <noah.b.lavine@x> writes:
>> The 'eqv?' predicate on two elements of S must return #t if its
>> arguments are the same member of S, and #f otherwise. Note that a
>> single member of S may have different representations, but arithmetic
>> operations are defined on the abstract set S and not on the
>> The goal is basically to push parts of the definition of eqv? down to
>> implementations, but do it in a structured way. This would require
>> that (eqv? 1.0 1.0) => #t,
> It is a mistake to try to ensure that (eqv? x y) => #true when x and y
> represent the same numeric value in different representations. You are
> trying to make 'eqv?' act like '=', and that is a fundamental error, and
> a very common one.
I meant to include a specific example of why (eqv? 1.0 1.0) should
sometimes return #false, if those two arguments are represented
Suppose those two arguments are represented with different precisions.
For example, one might be a 64-bit IEEE double and the other might be a
32-bit float, or perhaps an MPFR big float. Now consider the following
(define (foo? x) (zero? (/ x (expt 10 400))))
If one uses the usual precision-propagation rules, then (foo? 1.0) will
return #true if its argument is an IEEE double or float, but might
return #false if its argument is a MPFR big float.
Therefore, 'eqv?' must distinguish between inexact numbers of different
precisions, otherwise memoization does not work.
Consider a square root procedure, where the precision of the result
depends on the precision of its argument. So (sqrt 2.0) will return a
more precise answer if its argument if an MPFR big float. This
procedure can only be properly memoized if 'eqv?' distinguishes numbers
of different precisions.
Scheme-reports mailing list