Robert Latest wrote On 04/19/06 11:13,:

> On Wed, 19 Apr 2006 10:29:15 -0400,

> Eric Sosman <(E-Mail Removed)> wrote

> in Msg. <1145456956.867691@news1nwk>

>

>> No. The Standard permits floating-point implementations

>>that support the notion of "not a number," or NaN. In IEEE

>>implementations, NaN is unequal to all floating-point values,

>>including itself (so `x == y' is false)

>

>

> Makes sense. What about the non-NaN case?
The up-thread code was

>>> double x = some_value_from_somewhere;

>>> double y = x;

>>>

>>> if ((x == y) && ((x - y) == 0)) {

>>> puts("This is what I want");

>>> }
puts() will not be called if `some_value_from_somewhere'

is a NaN, and I think it will also remain uncalled if the

value is an infinity. Even for finite values I think you are

at the mercy of the implementation. Some systems compute

intermediate values to more precision than `double' will

hold, rounding or truncating when the value is actually

stored. On such a system, the result could depend on just

what the optimizer decides to do: if `some_value_from_somewhere'

carries extra precision it is at least possible that the

generated code might do something like

compute_high_precision some_value_from_somewhere

store_rounded x

store_rounded y

compare_to y

.... thus re-using the extra-precise `some_value_from_somewhere'

instead of the normally-precise `x', and the comparison could

yield non-equal.

Floating-point implementations have a lot of quirks, even

today, and it is no wonder that the C committee decided not to

try to iron them out by fiat. Thus, the specifications of F-P

behavior in C are awfully loose, and the corner cases tend to

yield different answers on different systems. I've heard it

said (though I'm not enough of an F-P specialist to evaluate

the argument) that no high-level programming language provides

a correct implementation even of IEEE binary floating-point.

--

(E-Mail Removed)