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

*To*: John Cowan <cowan@x>*Subject*: Re: [Scheme-reports] Inexact numbers and `eqv?`: the post I didn't want to make*From*: Mark H Weaver <mhw@x>*Date*: Mon, 26 Nov 2012 01:00:14 -0500*Cc*: scheme-reports@x*In-reply-to*: <20121126020004.GQ23962@mercury.ccil.org> (John Cowan's message of "Sun, 25 Nov 2012 21:00:04 -0500")*References*: <20121126020004.GQ23962@mercury.ccil.org>

Hi John, John Cowan <cowan@x> writes: > I thought hard before making this post, because I hate allowing material > non-public information to affect a standards process, and especially > when the information is about intentions rather than present facts -- > life is short, and we all change our minds. > > But I have been told by one Scheme implementer that he plans to add > a second, non-floating-point, type of inexact numbers to his Scheme. > Insofar as I understand the mathematics of them -- which is only slightly > more than not at all -- there will be no negative zero or NaN(s), and > perhaps no infinities either. But there will (I think) be more than > one possible representation of a given number. > > For this sort of non-IEEE exact number, = is the Right Thing for `eqv?`. > There are no special cases of numbers that should be distinguished even > though they are not mathematically equal. The assertions of the preceding paragraph require justification, and I see none here. A few questions arise: * Can you provide an example of an application that requires 'eqv?' and '=' to agree for this type of number, and that cannot be implemented in another way? * If 'eqv?' and '=' must agree, then why not use '=' instead? * Why does this application need two primitives to do the same job, leaving none that can be used for memoization? > However, there is (I think) > more than one representation for a given mathematical number, so a > "same-bits" standard will not work either: it will create unpredictable > fluctuations in the use of `eqv?`, such that in principle > (eqv? (+ 1.0 3.0) (+ 2.0 2.0)) might be #f, because the representation > of a number depends on how it is computed. Can you please provide an example of an application that requires (eqv? (+ 1.0 3.0) (+ 2.0 2.0)) => #t and cannot be implemented in another way? Note that if an implementation can prove that two different representations of the same number are operationally equivalent, then my proposed definition permits 'eqv?' to return #t. If the implementation can prove that numerical equality implies operational equivalence for some class of inexact numbers, then my proposed definition permits 'eqv?' to be implemented in terms of '=' for those numbers. If this implication cannot be proven, then it is a mistake to equate 'eqv?' and '=' for that class of inexact number, because that would violate the guarantee needed to implement memoization. What's the compelling argument to outweigh the needs of memoization? What application requires hard guarantees that 'eqv?' will return #t for distinct representations of the same inexact number? Regards, Mark _______________________________________________ Scheme-reports mailing list Scheme-reports@x http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports

**Follow-Ups**:**Re: [Scheme-reports] Inexact numbers and `eqv?`: the post I didn't want to make***From:*John Cowan <cowan@x>

**References**:**[Scheme-reports] Inexact numbers and `eqv?`: the post I didn't want to make***From:*John Cowan <cowan@x>

- Prev by Date:
**Re: [Scheme-reports] formal comment: Using "scheme" for standard library is problematic** - Next by Date:
**Re: [Scheme-reports] Formal Objection: Memoization is not possible in portable R7RS** - Previous by thread:
**[Scheme-reports] Inexact numbers and `eqv?`: the post I didn't want to make** - Next by thread:
**Re: [Scheme-reports] Inexact numbers and `eqv?`: the post I didn't want to make** - Index(es):