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

Re: [Scheme-reports] Formal Comment: R7RS 'eqv?' cannot be used for reliable memoization



Alex Shinn <alexshinn@x> writes:

> 2012/11/23 8:16 "Mark H Weaver" <mhw@x>:
>>
>> Alex Shinn <alexshinn@x> writes:
>>
>> > On Fri, Nov 23, 2012 at 2:25 AM, Mark H Weaver <mhw@x>
> wrote:
>> >
>> >     John Cowan <cowan@x> writes:
>> >
>> >     > How about this compromise:  simply remove the clause
> defining
>> >     `eqv?` on
>> >     > non-IEEE flonums?  It is arguably not a proper domain for
>> >     standardization
>> >     > anyway, since there are no such implementations today.  That
>> >     would allow
>> >     > future implementations to return `#t` or `#f` at their
>> >     discretion.
>> >
>> >
>> >     This would be *vastly* better than the current situation.  If
> it's
>> >     the
>> >     best we can hope for, then _please_ do this.  This would make
> it
>> >     very
>> >     likely that implementations would correctly extrapolate the
>> >     definition
>> >     of 'eqv?' to other representations.
>> >
>> >
>> > This has been mentioned multiple times, and I think
>> > would be vastly inferior to the current situation.  It
>> > means that eqv? is basically unspecified on inexacts -
>> > you couldn't even rely on (eqv? 1.0 1.0) => #t.
>>
>> You already can't rely on that, even with the current R7RS wording.
>  If
>> those two arguments are IEEE but of different precisions, then the
>> current R7RS definition requires that the result be #false.  If one
> is
>> an IEEE number and the other is a non-IEEE inexact, then the current
>> definition fails to specify anything.
>
> Read/write invariance ensures that 1.0 is always the same value.

Okay, so your point was that if the source code literally contains the
expression (eqv? 1.0 1.0), that the result is guaranteed to be #true?
Who cares?

If the property you desire is to have any importance whatsoever, it must
hold in the more general case of (eqv? x 1.0), where 'x' is inexact and
numerically equal to 1.0.  And my point is that you can't rely on that,
even with the current R7RS-draft-7 wording.  'eqv?' is simply the wrong
tool for that job.

You already have a tool to do the job you need.  It's called '='.

For those of us to need reliable memoization, regardless of what numeric
representation is used, what tool shall we use?

     Mark

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports