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

Exactness contagion and wired numeric predicates



Not to belabor a belabored point, but this exactness issue you raised seems
interesting in its own right...

       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.

Yow!  I guess if we don't coerce all of them to inexact if even one of them is
inexact then we could reveal the evaluation order of the sequence.  To point:
verifying monotonic increasing can be done by verifying monotonic decreasing
in the other direction.  If you go left to right where the left is inexact and
the right is exact [Fig.0] then you coerce the exact to an inexact for the
comparison.

  Fig.0:   (< inexact exact exact)

The question is, do you use this inexact coerced value for the comparison with
the number to the right or not?  If so, then you will not be consistent with
the right to left comparison (assuming this right to left likewise uses the
coerced value for the continued ``AND accumulation'').

 However, in the re-write rule that I sketched in the original message, I
(unwittingly) arranged to NOT use the coerced value for the subsequent
comparison.  The re-write rule looked like...

 (let iter (lambda (current-expr rest-exprs)
    ...
    (let ((next-expr (car rest-exprs)))
      (and (< current-expr next-expr)		; Maybe Coerce next-expr here
           (iter next-expr (cdr rest-exprs))))	; But that does not mutate it!
    ...))

 In fact, I don't see a reasonable way to ``get a handle on'' the coerced
value (used internally for the <) so that you could propagate this
`inexactness contagion'.  If we were to define the < et al.  by the above
re-writing then the issue is mute.  (Granted, the above rule specifies
left-to-right but we could remedy this by writing:

 (let ((list-of-comparees (reverse-or-not comparees)))
   ...<rule>...)

...where reverse-or-not non-deterministicall reverses a list or doesn't. This
is no more (or less) offesive than using PERMUTE in the semantics to
intentionally ambiguate the evaluation order of argument lists.

Anyway, I thought this amusing.					Cheers,
								~Ziggy