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

Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers



Hello,

I'm posting this now, even though I know that it is too late in the R7RS process to change things, because I hope we can at least generate some good discussion, and that could become part of R8RS (or an erratum, or something similar).

The definition you posted has the problem that two NaNs are never /substantially different/. But they might in fact be different, if they are different types of IEEE NaN (I don't know if MPFR has a similar concept). I would like to suggest an alternate way of defining numbers, which I have actually been avoiding suggesting for quite a while, but I unfortunately see no way around. It goes something like this:

    "An implementation may provide a set S of inexact number objects. If it provides them, the set S must be some subset of the complex plane, perhaps augmented with other objects (NaNs) to represent the results of undefined operations, and infinity objects to represent infinities. An implementation may provide zero, one, or many distinguished NaN objects.

    The arithmetical operations on S must be consistent with (approximate) complex number arithmetic when applied to complex numbers. The result of doing arithmetic on a NaN is another NaN, unless the implementation can prove that the result would be the same if the NaN were replaced by any rational number.

    The 'eqv?' predicate on two elements of S must return #t if its arguments are the same member of S, and #f otherwise. Note that a single member of S may have different representations, but arithmetic operations are defined on the abstract set S and not on the representations."

The goal is basically to push parts of the definition of eqv? down to implementations, but do it in a structured way. This would require that (eqv? 1.0 1.0) => #t, and (eqv? 1.0 2.0) => #f. It would leave the question undefined for NaNs, but I think in a way that would make clear what an implementation should do - if it provides multiple NaNs, then they must be distinguishable by eqv? If it provides only one NaN, then it is not eqv? to anything but itself.

I can certainly see the argument that this is too vague to be useful, but I don't know how to definite it more while still leaving room for different implementation strategies.

Noah Lavine


On Sun, Nov 11, 2012 at 11:37 PM, Mark H Weaver <mhw@x> wrote:
I have drafted a new definition of 'eqv?' for inexact real
numbers, to replace both the IEEE and non-IEEE clauses in
R7RS-draft-7.  I believe it overcomes the flaws of the R6RS
definition while remaining true to the principle of operational
equivalence, and without making assumptions about the numeric
representation(s).

The novel feature of this definition is the auxiliary predicate
/substantially different/, which is needed to gracefully avoid
circularities and the problems associated with NaNs, both of
which plagued the R6RS definition.

The NaN problem is addressed by making sure that no two NaNs are
/substantially different/ from each other.  The circularity
problem is addressed by defining /substantially different/ on
inexact numbers in terms of = instead of eqv?, provided that they
are not both NaNs.

Note that there is considerable freedom in how /substantially
different/ is defined.  As long as it is capable of making the
most coarse distinctions between numbers, that's good enough,
because it is always possible to choose a procedure 'f' that
amplifies even the finest distinction between any two inexact
numbers that are not operationally equivalent.

For example, suppose that in addition to the usual +0.0 and -0.0,
an experimental numeric representation was able to distinguish
(x/y+0.0) from (x/y-0.0) for any exact rational x/y.  It would
still be possible to amplify that distinction to an infinite
difference by subtracting x/y and then taking the reciprocal.

I struggled with the choice of operators to allow in the
construction of 'f', but came to realize that it doesn't matter
much.  The main requirements are that procedures should not cause
visible side effects, and that their return values should depend
only on their arguments, i.e. they should be pure functions.  It
needn't be a comprehensive set.  As long as one is able to
amplify arbitrary fine distinctions into coarse ones that are
/substantially different/, that's good enough.

Comments and suggestions solicited.

      Mark


Objects obj_1 and obj_2 are /substantially different/ if and only
if one of the following holds:

* obj_1 and obj_2 are both inexact real numbers, are not =, and
  are not both representations of NaNs.

* obj_1 and obj_2 are both inexact complex numbers whose real or
  imaginary parts are /substantially different/.

* obj_1 and obj_2 are not both inexact numbers, and are not eqv?.

Inexact real numbers x_1 and x_2 are /operationally equivalent/
if and only if for all procedures f that can be defined as a
finite composition of the standard numerical operations specified
in section 6.2.6, (f obj_1) and (f obj_2) are not /substantially
different/.

The eqv? procedure returns #t if one of the following holds:
[...]

* obj_1 and obj_2 are both inexact real numbers, are not both
  representations of NaNs, and the implementation can prove that
  obj_1 and obj_2 are /operationally equivalent/.

The eqv? procedure returns #f if one of the following holds:
[...]

* obj_1 and obj_2 are both inexact real numbers, are not both
  representations of NaNs, and the implementation cannot prove
  that obj_1 and obj_2 are /operationally equivalent/.

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

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