[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Inexact numbers and `eqv?`: the post I didn't want to make
John Cowan <cowan@x> 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?
Scheme-reports mailing list