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

[Andrei Alexandrescu]

Don wrote:
> 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.

Yah, there was a discussion on the C++ standardization mailing list too. 
It turns out that x == x is a pretty fundamental concept and if a type 
as common as float breaks it with panache, then it's pretty complicated 
to change language fundaments to account for such a case.

Andrei