Hi John,

John Cowan <cowan@mercury.ccil.org> writes:
> I thought hard before making this post, because I hate allowing material
> non-public information to affect a standards process, and especially
> when the information is about intentions rather than present facts --
> life is short, and we all change our minds.
>
> But I have been told by one Scheme implementer that he plans to add
> a second, non-floating-point, type of inexact numbers to his Scheme.
> Insofar as I understand the mathematics of them -- which is only slightly
> more than not at all -- there will be no negative zero or NaN(s), and
> perhaps no infinities either.  But there will (I think) be more than
> one possible representation of a given number.
>
> 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.

The assertions of the preceding paragraph require justification,
and I see none here.  A few questions arise:

* 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?

* If 'eqv?' and '=' must agree, then why not use '=' instead?

* Why does this application need two primitives to do the same
  job, leaving none that can be used for memoization?

> However, there is (I think)
> more than one representation for a given mathematical number, so a
> "same-bits" standard will not work either: it will create unpredictable
> fluctuations in the use of `eqv?`, such that in principle
> (eqv? (+ 1.0 3.0) (+ 2.0 2.0)) might be #f, because the representation
> of a number depends on how it is computed.

Can you please provide an example of an application that requires
(eqv? (+ 1.0 3.0) (+ 2.0 2.0)) => #t and cannot be implemented in
another way?

Note that if an implementation can prove that two different
representations of the same number are operationally equivalent,
then my proposed definition permits 'eqv?' to return #t.

If the implementation can prove that numerical equality implies
operational equivalence for some class of inexact numbers, then my
proposed definition permits 'eqv?' to be implemented in terms of
'=' for those numbers.  If this implication cannot be proven, then
it is a mistake to equate 'eqv?' and '=' for that class of inexact
number, because that would violate the guarantee needed to
implement memoization.

What's the compelling argument to outweigh the needs of
memoization?  What application requires hard guarantees that
'eqv?' will return #t for distinct representations of the same
inexact number?

    Regards,
      Mark

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