EQUAL, and hash tables, and value/object distinctions

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

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?

    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.