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

*To*: Alex Shinn <alexshinn@x>*Subject*: Re: [Scheme-reports] EQV? on numbers should be based on operational equivalence*From*: Mark H Weaver <mhw@x>*Date*: Tue, 08 May 2012 00:59:02 -0400*Cc*: John Cowan <cowan@x>, scheme-reports@x*In-reply-to*: <CAMMPzYN4PYXfjQOO3dhGXqKA1NHjuQD4JwK3ozUkXdDCqDbSvQ@mail.gmail.com> (Alex Shinn's message of "Tue, 8 May 2012 12:23:00 +0900")*References*: <87zk9jor6s.fsf@netris.org> <20120507213136.GA12719@mercury.ccil.org> <8762c7o8we.fsf@netris.org> <CAMMPzYMjv1jbMFAvzB7fQqbf69uCZg-0+Nwz-Nq+7Jrtd6QMUQ@mail.gmail.com> <87wr4nmo7f.fsf@netris.org> <CAMMPzYN4PYXfjQOO3dhGXqKA1NHjuQD4JwK3ozUkXdDCqDbSvQ@mail.gmail.com>

Alex Shinn <alexshinn@x> writes: > On Tue, May 8, 2012 at 10:55 AM, Mark H Weaver <mhw@x> wrote: >> Alex Shinn <alexshinn@x> writes: >>> On Tue, May 8, 2012 at 8:42 AM, Mark H Weaver <mhw@x> wrote: >>>> John Cowan <cowan@x> writes: >>>>> Mark H Weaver scripsit: >>>>> >>>>>> In particular, on platforms with signed zeroes, the R7RS should mandate >>>>>> that (eqv? 0.0 -0.0) => #false. >>>>> >>>>> R6RS mandates that, but R7RS currently leaves it unspecified. >>>> >>>> How would you suggest implementing memoization in a portable R7RS >>>> program? >>> >>> It must be unspecified in R7RS because R7RS >>> does not require that implementations distinguish >>> between 0.0 and -0.0, nor that they provide +inf.0 >>> or -inf.0. >> >> That's why I qualified my statement with "on platforms with signed >> zeroes". All I am advocating is that EQV? be based on operational >> equivalence, i.e. that we mandate (eqv? 0.0 -0.0) => #true if and only >> if 0.0 and -0.0 are operationally equivalent. > > The problem is an implementation may have a > different representation for -0.0 but still not > support +/-inf.0. Division is not the only operator that distinguishes 0.0 and -0.0. Signed zeroes are also relevant for any operation involving branch cuts along the real or imaginary axes. When I have written "on platforms with signed zeroes", that is a shorthand for "in implementations where 0.0 and -0.0 are not operationally equivalent". If 0.0 and -0.0 are indistinguishable, then effectively the implementation does not have signed zeroes. > Trying to to list every case manually would result in a long chain of > if/then/else statements. It's much better if the desired results fall > out naturally from a simple rule. Agreed, and the simple rule is the one given in the R3RS: The eqv? procedure implements an approximation to the relation of operational equivalence. It returns #t if it can prove that obj1 and obj2 are operationally equivalent. If it can't, it always errs on the conservative side and returns #f. where operational equivalence is defined as follows: Two objects are operationally equivalent if and only if there is no way that they can be distinguished, using Scheme primitives other than eqv? or eq? or those like memq and assv whose meaning is defined explicitly in terms of eqv? or eq?. It is guaranteed that objects maintain their operational identity despite being named by variables or fetched from or stored into data structures. For the usual numeric representations, an implementation should be able to determine whether two numbers are operationally equivalent. However, it should be noted that there are some exotic numeric representations such as infinite-precision reals (e.g. based on continued fractions or continued logarithms) where operational equivalence cannot always be proved. The R3RS wording above allows for this case. > This is why we're revisiting all eqv? tickets as a single item in the > next ballot - we should have a single consistent rule and stick to it. Agreed. Mark _______________________________________________ Scheme-reports mailing list Scheme-reports@x http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports

**Follow-Ups**:**Re: [Scheme-reports] EQV? on numbers should be based on operational equivalence***From:*Alex Shinn <alexshinn@x>

**References**:**[Scheme-reports] EQV? on numbers should be based on operational equivalence***From:*Mark H Weaver <mhw@x>

**Re: [Scheme-reports] EQV? on numbers should be based on operational equivalence***From:*John Cowan <cowan@x>

**Re: [Scheme-reports] EQV? on numbers should be based on operational equivalence***From:*Mark H Weaver <mhw@x>

**Re: [Scheme-reports] EQV? on numbers should be based on operational equivalence***From:*Alex Shinn <alexshinn@x>

**Re: [Scheme-reports] EQV? on numbers should be based on operational equivalence***From:*Mark H Weaver <mhw@x>

**Re: [Scheme-reports] EQV? on numbers should be based on operational equivalence***From:*Alex Shinn <alexshinn@x>

- Prev by Date:
**Re: [Scheme-reports] EQV? on numbers should be based on operational equivalence** - Next by Date:
**Re: [Scheme-reports] EQV? on numbers should be based on operational equivalence** - Previous by thread:
**Re: [Scheme-reports] EQV? on numbers should be based on operational equivalence** - Next by thread:
**Re: [Scheme-reports] EQV? on numbers should be based on operational equivalence** - Index(es):