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

*To*: Mark H Weaver <mhw@x>*Subject*: Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers*From*: Noah Lavine <noah.b.lavine@x>*Date*: Mon, 12 Nov 2012 08:47:57 -0500*Cc*: scheme-reports@x*In-reply-to*: <87y5i7h1wh.fsf@tines.lan>*References*: <87k3tr9azi.fsf@tines.lan> <87y5i7h1wh.fsf@tines.lan>

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

**Follow-Ups**:**Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers***From:*Mark H Weaver <mhw@x>

**Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers***From:*Mark H Weaver <mhw@x>

**References**:**[Scheme-reports] Formal Comment: R7RS 'eqv?' cannot be used for reliable memoization***From:*Mark H Weaver <mhw@x>

**[Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers***From:*Mark H Weaver <mhw@x>

- Prev by Date:
**Re: [Scheme-reports] Formal Comment: R7RS 'eqv?' cannot be used for reliable memoization** - Next by Date:
**Re: [Scheme-reports] Comment on draft 7 regarding <non-digit>** - Previous by thread:
**[Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers** - Next by thread:
**Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers** - Index(es):