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

*To*: Hans_Boehm.PARC@xerox.com, RRRS-Authors@mc.lcs.mit.edu*Subject*: Re: transitivity requirement on scheme comparison and rational?*From*: William Clinger <will@cs.uoregon.edu>*Date*: Mon, 17 Feb 92 18:16:39 -0800

....But this means that unless I have an "inexact rational" number representation... the following can generate a divide by zero error: (if (= x y) (...) (/ (- x y))) Right. People who compare inexact numbers using = had better know what they're doing. That's why there's a warning note in the description of the = predicate. Presumably (if (zero? (- x y)) (...) (/ (- x y))) is what was intended. Matters get considerably worse if I decide to use interval arithmetic.... Right. ....Thus my only real option is to define no two intervals (with nonzero size) as equal.... Wrong. It is possible to implement the Scheme number system using IEEE floating point numbers with (either symmetric or asymmetric) error bounds, and that would be a very useful thing to do. With symmetric error bounds, the difference between this and conventional interval arithmetic is a bit subtle. One difference is that Scheme's comparison predicates would use the locally best approximation, ignoring the error bounds. Another difference is that the midpoint of an interval is seldom the same as the locally best approximation, and the midpoint might not be an IEEE floating point number anyway. In short, an IEEE floating point number with error bounds is more expensive to compute than an interval, but it also gives more information, especially with asymmetric error bounds. The non-transitive relations that pay attention to whether the intervals (obtained from the error bounds) overlap could be provided, but they couldn't be Scheme's standard comparison predicates. There are other interpretations one could give to the comparison predicates that would satisfy the Scheme standard in an implementation that uses interval arithmetic, but the implementation sketched above has long seemed best to me. It was one of the implementations I kept in mind as the standard was being drafted. ...I interpret the scheme standard to mean that in current implementations (rational? (sqrt 2)) will evaluate to #t. Right. It seems to provide useful information only if I include an algebraic number package or something similar. This is probably not practical, and furthermore standard scheme doesn't give me the primitives to compute an arbitrary algebraic number, I believe. So I would need to add primitives in any case. Similarly, NUMBER? will be the same as COMPLEX? unless new primitives are added. The standard anticipates the possibility of new primitives without suggesting what they might be. You might also look at the specification of NUMBER->STRING, which is well-specified only for complex numbers with rational rectangular components, and was carefully left unspecified for other numbers. Will

**Follow-Ups**:**Re: transitivity requirement on scheme comparison and rational?***From:*Hans_Boehm.PARC@xerox.com

- Prev by Date:
**Re: (rational? (sqrt 2))** - Next by Date:
**Re: transitivity requirement on scheme comparison and rational?** - Prev by thread:
**transitivity requirement on scheme comparison and rational?** - Next by thread:
**Re: transitivity requirement on scheme comparison and rational?** - Index(es):