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

*To*: Moon@STONY-BROOK.SCRC.Symbolics.COM, edsel!jonl@labrea.stanford.edu*Subject*: EQUAL, and hash tables, and value/object distinctions*From*: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>*Date*: Tue, 19 Jul 88 17:33 EDT*Cc*: Greenwald@STONY-BROOK.SCRC.Symbolics.COM, jrose@sun.com, goldman@vaxa.isi.edu, common-lisp@SAIL.STANFORD.EDU*In-reply-to*: <19880719152249.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

Date: Tue, 19 Jul 88 11:22 EDT From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Date: Tue, 19 Jul 88 00:05:31 PDT From: Jon L White <edsel!jonl@labrea.stanford.edu> ....numerical equality and inequalities are not information losing, and should in fact be transitive relations. About one year ago, I pointed out this difficulty to Guy Steele with some well- chosen examples; and he was quite shocked -- indeed it was his intention that "=" be a true equivalence predicate. I agree that = should be transitive even when floating-point numbers are involved. I.e. (= (/ 10.0 single-float-epsilon) (1+ (floor (/ 10.0 single-float-epsilon)))) should be NIL, since (= (/ 10.0 single-float-epsilon) (floor (/ 10.0 single-float-epsilon))) is certainly T and (= (floor (/ 10.0 single-float-epsilon)) (1+ (floor (/ 10.0 single-float-epsilon)))) is certainly NIL. To understand this example better, it helps to realize that (= (/ 10.0 single-float-epsilon) (+ (/ 10.0 single-float-epsilon) 1.0)) is true in all implementations. Without using the epsilon case: (= 1234d20 (FLOOR 1234d20)) => T (= 1234d20 (1+ (FLOOR 1234d20))) => T but obviously (= (FLOOR 1234d20) (1+ (FLOOR 1234d20))) => NIL Or, one of my favorite screw cases along these lines: (LET ((A 1234d10)) (<= A (1+ (FLOOR A)) (COERCE A 'SINGLE-FLOAT) (FLOOR A))) Since CLtL p.194 expressly forbids this, requiring the first form above to return T, shouldn't somebody submit an X3J13 Cleanup subcommittee proposal before it's too late? I'll point out that in March 1987 JonL proposed the same thing, and Moon suggested that the proposal be written up and submitted to the X3J13 committee. From this exchange can I conclude that nothing *was* submitted? I'd guess that this suggestion is probably futile unless someone actively volunteers to write up, and submit, the new floating point contagion rule for comparisons. Lucid's 3.0 release performs "appropriate contagion" in the case of numerical comparisons, in order to preserve transitivity. I'm a little surprised that Lucid would change their implementation incompatibly with both CLtL and previous Lucid implementations without first getting some concensus that the current definition of Common Lisp is wrong and in fact will change. I know Symbolics specifically decided not to "fix this bug" unilaterally when we noticed it some time ago, considering that compatibility was more important. Chacun a son gout.

**Follow-Ups**:**Contagion on numerical comparisons***From:*Jon L White <edsel!jonl@labrea.stanford.edu>

**References**:**EQUAL, and hash tables, and value/object distinctions***From:*David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

- Prev by Date:
**EQUAL, and hash tables, and value/object distinctions** - Next by Date:
**EQUAL, and hash tables, and value/object distinctions** - Previous by thread:
**EQUAL, and hash tables, and value/object distinctions** - Next by thread:
**Contagion on numerical comparisons** - Index(es):