[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:
> the only potential difference between the
> current draft and your proposal is with -0.0,

That's not true.  It is also important to distinguish numbers with
different precisions or exponent ranges, as discussed in my other email.
Bradley Lucier understood that, which is why his "samebits" eqv? test
specifically includes both precision and maximum exponent in the list of
fields that are compared.

> I do not consider this a serious flaw.  I dislike it and
> voted against it, but it's a reasonable specification of
> eqv?.

Indeed, you distinguished yourself as the _sole_ member of the working
group who voted for (eqv? +0.0 -0.0) => #true even for IEEE-754 floating
point numbers, thus demonstrating a lack of understanding of what 'eqv?'
is for.

With that in mind, it is not surprising that you do not see this as a
serious flaw.

I would not hold this against you if not for your utter unwillingness to
listen to reason.  The needs of memoization have not convinced you, nor
have the past definitions of 'eqv?' in RRRS and R3RS.  I suppose that
Will Clinger's description of 'eqv?' in SRFI-85 and the discussions of
'eqv?' leading to R3RS by Jonathan Rees and others would similarly fail
to sway you.

Apparently you see no need for an operational equivalence test, but a
predicate for which (eqv? 0 0.0) => #false and (eqv? +0.0 -0.0) => #true
sounds good to you.

I really don't know what more to say.  Clearly, I will have to appeal to
others with more authority than you, because you are impervious to
reason.

     Mark

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