Eliminate the baroque floating-point operators a la !<>=
Don
nospam at nospam.com
Sun May 17 13:07:24 PDT 2009
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.
More information about the Digitalmars-d
mailing list