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 <[email protected]> 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
> [email protected]
> http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
>
_______________________________________________
Scheme-reports mailing list
[email protected]
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
