Are there cases where a program says a * a * a
but evaluating it as a * (a * a) would be wrong?
I gather (at least in your examples) that dealing with bigger numbers first typically affords more 'real' accuracy?
I gather (at least in your examples) that dealing with bigger numbers first typically affords more 'real' accuracy?
With arbitrary numbers a, b, and c, it would be a different story for a * b * c. Without further knowledge of a, b, c, there would be no particular reason to do the operations in one order or another, but the result of a * b * c and a * (b * c) could definitely differ by one ULP, probably by two in ordinary cases, by more if underflow occurred (but one of the variables would already have to be very small for this to happen).
It's not, except in the special case of one and the same number.
Look for the first occurrence of the word “commutative” in this page: http://en.wikipedia.org/wiki/Floating_point
But remember, if both the Wikipedia editors and I are wrong, you only need to produce one pair of operands a and b such that a * b does not produce not the same result(1) as b * a to be vindicated.
(1) I suggest we consider all NaN values to be “the same result” for the purpose of this challenge.
Knowing is better than fearing.
Consider storing a timestamp as a number of seconds since the epoch. We might use == to check if the timestamp has changed.
More seriously, I remember APL\360 SETFUZZ from long before many of you whippersnappers were born, which told the system to disregard so-many bits in an 'equals' evaluation.
FP implementations are generally evil, and errors cascade in irritating fashion. 50% of a numerical analysis class I took once was dedicated to error estimation. Stick to rationals if you can - it'll save your hairline.