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

*To*: John Cowan <cowan@x>*Subject*: Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers*From*: Mark H Weaver <mhw@x>*Date*: Tue, 13 Nov 2012 00:16:52 -0500*Cc*: scheme-reports@x*In-reply-to*: <20121113030949.GD17680@mercury.ccil.org> (John Cowan's message of "Mon, 12 Nov 2012 22:09:49 -0500")*References*: <87k3tr9azi.fsf@tines.lan> <87y5i7h1wh.fsf@tines.lan> <20121113030949.GD17680@mercury.ccil.org>

John Cowan <cowan@x> writes: > Mark H Weaver scripsit: > >> The eqv? procedure returns #t if one of the following holds: >> [...] >> >> * obj_1 and obj_2 are both inexact real numbers, are not both >> representations of NaNs, and the implementation can prove that >> obj_1 and obj_2 are /operationally equivalent/. > > What is the operational definition of "can prove"? I say my > implementation can't prove anything about inexacts, and then > (eqv? inexact1 inexact2) always returns #f. It is easy to prove that numbers represented by the same bit patterns are operationally equivalent, given that the arithmetic operations are all pure functions. This "same bits" approach is a perfectly good way to implement 'eqv?'. Anyway, there is a longstanding precedent for this "implementation can prove" language in section 1.1. This text has not changed since the RRRS: All objects created in the course of a Scheme computation, including procedures and continuations, have unlimited extent. No Scheme object is ever destroyed. The reason that implementations of Scheme do not (usually!) run out of storage is that they are permitted to reclaim the storage occupied by an object if they can prove that the object cannot possibly matter to any future computation. You could just as easily say: What is the operational definition of "can prove"? I say my implementation can't prove anything about whether an object matters to future computations, and then no memory will ever be freed. Mark _______________________________________________ Scheme-reports mailing list Scheme-reports@x http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports

**Follow-Ups**:**Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers***From:*John Cowan <cowan@x>

**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:*John Cowan <cowan@x>

- Prev by Date:
**Re: [Scheme-reports] Formal Comment: R7RS 'eqv?' cannot be used for reliable memoization** - Next by Date:
**Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers** - 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):