Contagion on numerical comparisons

[Jon L White <edsel!jonl@labrea.stanford.edu>]

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
     Now      
       (<=   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 --