Weird numeric predicates?

[Alan Bawden <Alan@AI.AI.MIT.EDU>]

    Date: Fri, 17 Mar 89 11:26:05 -0500
    From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
    I haven't thought about it carefully, but it may not be reasonable
    (unless it is defined that way) to implement n-ary < and friends as
    the "AND accumulation" of binary <.  Comparisons between exact and
    inexact numbers should coerce the exact numbers to inexact, and this
    value may have to be used consistently afterwards.

If <= is to behave transitively, even on inexact arguments, then you have
to coerce inexact number to exact numbers in order to perform comparisons.
(Or you must behave as if you did.)  To see why, consider the following
three numbers:
  
  (DEFINE A (- (EXPT 10 38) 1))
  (DEFINE B 1E38)
  (DEFINE C (+ (EXPT 10 38) 1))

Assuming your implementation has an exact representation for A and C
(probably as a BIGNUM) and the inexact B is represented in a floating point
format with less (probably far less!) that 38 digits of precision, then
coercing either A or C to inexact will most likely return B.  If comparison
predicates coerce EXACT->INEXACT, then the following will be true:

  (<= C B)	==>  #T
  (<= B A)	==>  #T
  (<= C A)	==>  #F

Perhaps worse:

  (= C B)	==>  #T
  (= B A)	==>  #T
  (= C A)	==>  #F

If instead comparison predicates coerce INEXACT->EXACT then consistently
transitive answers will be obtained.