Don wrote:
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@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
