# EQUAL, and hash tables, and value/object distinctions

• 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

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

```