Re: transitivity requirement on scheme comparison and rational?

[William Clinger <will@cs.uoregon.edu>]

    ....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