[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: Noah Lavine <noah.b.lavine@x>*Subject*: Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers*From*: Mark H Weaver <mhw@x>*Date*: Mon, 12 Nov 2012 12:53:54 -0500*Cc*: scheme-reports@x*In-reply-to*: <87625ahgj9.fsf@tines.lan> (Mark H. Weaver's message of "Mon, 12 Nov 2012 12:34:02 -0500")*References*: <87k3tr9azi.fsf@tines.lan> <87y5i7h1wh.fsf@tines.lan> <CA+U71=MviDMYuKEYo5+04rSLOdprpjjXa2Z7-BCN8YS7-j5pAg@mail.gmail.com> <87625ahgj9.fsf@tines.lan>

I wrote: > 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 >> 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@x http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports

**References**:**[Scheme-reports] Formal Comment: R7RS 'eqv?' cannot be used for reliable memoization***From:*Mark H Weaver <mhw@x>

**[Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers***From:*Mark H Weaver <mhw@x>

**Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers***From:*Noah Lavine <noah.b.lavine@x>

**Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers***From:*Mark H Weaver <mhw@x>

- Prev by Date:
**Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers** - Next by Date:
**Re: [Scheme-reports] **-copy! doesn't specify when start and end is omitted** - Previous by thread:
**Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers** - Next by thread:
**Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers** - Index(es):