[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Numerical Comparison: "required coercions"
Date: Wed, 25 Mar 87 14:52:35 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Section 12.3 of CLtL, when speaking of the numerical comparison
functions -- =, /=, <, etc. -- says that each one works on all types
of numbers (unless otherwise indicated), and that any "required
coercions" are performed when the arguments are of different type.
This part of the book is particularly unclear, but since pages 196 and
199 both use the same "required coercions" phrase I think they must both
be referring to the coercions described in section 12.1.
....
Wouldn't it make more sense to consider the phrase "required coercions"
to mean that when a rational is compared to a float, it is the float
that is "coerced" rather than the rational?
Offhand it seems like it would make more sense. I would certainly feel
better if Common Lisp's = and EQUALP functions were transitive. But I
think CLtL as currently written could only be saying that the rule of
floating-point contagion is to be followed, the opposite of your
suggestion.
In short, I don't think the original intent was that "=" be a "fuzzy"
operation. Rather it should be mathematically consistent, even if the
interpretation of "precision" for floating-point numbers is open to
question.
Well, it's pretty clear that the original intent wasn't as fully
thought-out as we would like!
Do you propose that = of two floating-point numbers of different
precision use the longer of the two precisions (which appears to be what
CLtL prescribes), or use the shorter of the two precisions (which would
cause fewer surprises to people who don't really understand what
floating-point is and is not)?
May I suggest writing this proposal up more formally and running it
through the X3J13 cleanup subcommittee? That seems like a good way to
ensure that all the ramifications get considered.
The IEEE floating-point standard may speak to mixed-mode and
mixed-precision comparisons; I don't know about that, but if it does,
Common Lisp ought to follow it.