I wrote:
> Noah Lavine <noah.b.lavine@gmail.com> 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
>> representations."
>>
>> 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
differently.

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
predicate:

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

     Mark

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports