Eliminate the baroque floating-point operators a la !<>=

[Don]

dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>> Hello,
>> I think the floating-point operators:
>>    a !<>= b
>>    a !<> b
>>    a <> b
>>    a <>= b
>>    a !> b
>>    a !>= b
>>    a !< b
>>    a !<= b
>> are useless. A simple peephole optimization in the compiler can
>> automatically rewrite NaN test followed by regular operations into the
>> operations above, for example:
>> isNaN(a) || isNan(b) || a >= b
>> is the same as
>> a !< b
>> This is in keeping with what the compiler does when seeing code like:
>> a = x / y;
>> b = x % y;
>> There's a peephole optimization that groups the / and the % together
>> into an assembler operation that does both. If this is the way to go, we
>> better be congruent and use explicit isNaN tests (that are then
>> optimized) instead of defining eight extra operators.
>> Andrei
> 
> I personally would like to see the whole NaNs not having a defined ordering thing
> done away with entirely.  This probably won't happen b/c it's (I would guess) in
> the IEEE standard.  However, the fact that a NaN is not less than, equal to, or
> greater than, anything creates an extremely annoying special case when doing
> generic programming for anything that requires a total ordering, such as trees and
> sorting.

Agreed. It's quite ridiculous that x==x fails for some values of x 
(namely NaN). On this NG, I've mentioned the rationale for why that is 
(eg, if NaN==NaN, then sqrt(-4) == sqrt(-9)). But unfortunately, in 
solving an obscure corner case, the IEEE standard destroyed one of the 
most basic axioms in mathematics. It's one of those things that Seemed 
Like A Good Idea At The Time. The cure is a millions times worse than 
the disease. But it's in hardware, so it's Too Late Now.