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