John Cowan <cowan@mercury.ccil.org> writes:

> Mark H Weaver scripsit:
>
>> > 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.
>>
>> * 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?
>
> The shoe's on the other foot.  Can you provide an example of an
> application that requires them to disagree on inexact numbers that
> exclude NaN and negative zero?

Yes, my formal objection already provided such an example:

Conflict Example 2: Multiple precision arithmetic
=================================================

Implementations may provide multiple representations of inexact numbers
with different precisions, and primitive arithmetic operations may
compute a result whose precision depends on the precision of the
arguments.  For example (sqrt x), where (= x 2.0), may yield a different
result depending on the precision of 'x'.

In order to memoize 'sqrt' properly, it must be possible to distinguish
a low-precision representation of 2.0 from a high-precision
representation of 2.0, although those two numbers are '='.

>> * If 'eqv?' and '=' must agree, then why not use '=' instead?
>
> Because there are things that have `eqv?` hard-coded into them,
> like `case`.

'case' is simply the wrong tool for comparing numerical equality.
Anyone who wants to dispatch on specific inexact values can easily
build their own case-like macro that uses '='.

Memoization has no such workaround.

Do you have an example of an application that is impossible to
implement unless 'eqv?' and '=' agree for inexacts?

       Mark

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