Thank you for the well reasoned formal comment. Note the formal comment period ended June 30, and we've published a draft which many people are now reviewing and will be used for the ratification vote. I will discuss with the WG, but it is unlikely we would consider such a change at this late time.
In particular, the issue you bring up was already voted on twice. The definition of eqv? has historically been strongly contended, and there is simply no way to make everyone happy on this point. -- Alex On Mon, Nov 12, 2012 at 4:48 AM, Mark H Weaver <[email protected]> wrote: > Formal Comment > > Submitter's name: Mark H Weaver > Submitter's email: [email protected] > Relevant draft: R7RS draft 7 > > Type: defect > Priority: major > Relevant section of draft: Equivalence predicates > > Summary: 'eqv?' cannot be used for reliable memoization > > The definition of 'eqv?' requires that (eqv? -0.0 +0.0) => #true when > the arguments are inexact real numbers not conforming to IEEE 754-2008, > even if -0.0 and +0.0 are not operationally equivalent. > > This will cause eqv?-based memoized numerical procedures with a branch > cut on the real or imaginary axes to sometimes return incorrect results. > For example, if a memoized reciprocal procedure is first evaluated at > -0.0 (returning and memoizing -inf.0), and then later evaluated at +0.0, > it will return -inf.0, which is incorrect. > > Why is this important, when almost all implementations that support > signed zeroes also conform to IEEE 754-2008? > > GNU MPFR is a popular and efficient arbitrary-precision arithmetic > library that is likely to be supported by some implementations in the > future. Although it supports signed zeroes, its does not support > gradual underflow, and thus does not conform to IEEE 754-2008. > Therefore R7RS requires that (eqv? -0.0 +0.0) => #true when the > arguments are represented using MPFR, thus making reliable memoization > impractical using R7RS. > > The minimum requirement for reliable memoization is that 'eqv?' must > return #false when its arguments are not operationally equivalent. As > currently written, R7RS will be the first Scheme standard to violate > this requirement for the numbers discussed in the standard. > > Mark > > _______________________________________________ > Scheme-reports mailing list > [email protected] > http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports >
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
