EQUAL, and hash tables, and value/object distinctions

[Michael Greenwald <Greenwald@STONY-BROOK.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.