🚀 go-pugleaf

mfinney@inmind.com wrote:
[ snip snip ]
>
>The problem is not defined < in terms of > or vice versa, but defined <= in
>terms of >.  In a linear order there are three possibilities, a < b, a = b or a > b.
>In a partial order there are four possibilities, a < b, a = b, a > b or a >< b (using
>operator >< () mean "not comparable).
>
>For a linear order, a <= b is equivalent to not (a > b).  However, that fails to
>be true for a partial order because there is an extra possiblity.
>
>If <= were defined in terms of > (or >= in terms of <) for IEEE floating point
>then even there there would be a problem because there are NaNs (not a number)
>objects in IEEE floating point which are not comparable to anything else,
>including other NaNs.
>
>This is why the definitions are wrong.
>

I disagree. If a and b are not ordered (ie not comparable), it is an
error to try to compare them. Hence a < b (or any of the other 5 operators)
are free to do whatever they like - throw an exception, return a random
value or start up a game of tetris.

-- 
Mike Chapman, Munich                                       
   Some programming languages manage to absorb change,     
   but withstand progress.                                 
       -- Epigrams in Programming, ACM SIGPLAN Sept. 1982
.................................................................
.................................................................
.................................................................
.................................................................
(For the benefit of my brain dead news host.)