[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Contagion on numerical comparisons
- To: Greenwald@stony-brook.scrc.symbolics.com, Moon@stony-brook.scrc.symbolics.com
- Subject: Contagion on numerical comparisons
- From: Jon L White <email@example.com>
- Date: Wed, 20 Jul 88 01:36:34 PDT
- Cc: firstname.lastname@example.org
- In-reply-to: Michael Greenwald's message of Tue, 19 Jul 88 17:33 EDT <19880719213338.0.GREENWALD@SWALLOW.SCRC.Symbolics.COM>
re: [Jonl: the CL numeric comparisons should be transitive functions.]
[Moon: this violates CLtL; shouldn't we have a cleanup issue for it?]
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.
This "proposal" has been on my list of items "to be submitted". A hardcopy
of this list was passed-out to cl-cleanup committee members who were actually
present at the March 1988 meeting in Palo Alto, and commentary was invited.
The relevant paragraph was:
``Specify that the numerical comparison functions (CLtL, p196) are
transitive operations; thus the phrase "required coercions" can't
be interpreted to mean "float contagion" (probably "rational contagion"
is needed for comparisons, whereas "float contagion" is needed for the
other operations). Although this contradicts the statement on p194,
third paragraph, but the mathematics is much better.''
Only a handful of persons actually gave me feedback on priorities for this
list, and the numeric-comparison transitivity issue didn't rate very high
in anyone's book.
Note that your(plural) examples were all malice-aforethought cases on
numerical-equality; but numeric inequalities are involved also, and are
probably even more important [because doing an EQL comparison between a
float and a rational that can't be exactly represented by a float is
probably a conceptual bug; but doing a < or <= comparison is still
meaningful, modulo "fence-posts"]. For a world with 24-bit mantissas
(e.g., ieee "single-floats") float-contagion on comparisons will lead to
the following absurdity:
(setq i #x2000000) ==> 33554432
(setq fx (float i)) ==> 3.3554432E7
(<= fx (+ i 1)) ==> T
(< (+ i 1) (+ i 2)) ==> T
(<= (+ i 2) fx) ==> T
which is summarized by:
fx <= i+1 < i+2 <= fx
Or, put bluntly, fx < fx, an absurdity.
Maybe it will be impossible to get complete consensus on this issue, as
some dyed-in-the-wool FORTRANer's may insist that compatibililty with the
1950's behaviour is preferable to transitivity. But at Lucid, some time ago,
we finally decided to bite the bullet, knowing that the fix will hardly break
any reasonable programs, and not fixing it will break some obscure programs.
I plan to submit a select subset of my "to be submitted" list as proposals
to the x3j13 cleanup committe sometime well before mid-September.
-- JonL --