There are no values of a where a * a * a differs from a * (a * a), because floating-point multiplication is commutative.
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).
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.
You're right of course. I was thinking about associtivity, not seeing what's really written. Sorry. I didn't expect discussing commutativity in the context (it's the non-associativity that doesn't allow all the "automatic" optimizations expected by some) where the formula in the same sentence is with three elements and the different order of computation. Which doesn't change the fact that I've made an error.
Yep grouping can lead to better real accuracy. But then you lose exact IEEE compatibility (get slightly different results that will fail a comparison).
Pure cargo-culting. There are circumstances in which it’s perfectly appropriate to compare floating-point data for equality. There are also circumstances in which a comparison with some tolerance is more appropriate. Understand what situation you’re in, and understand the tools that you’re using.
Oh, there must be a Common Lisp predicate that addresses this. prettymuchequalsp?
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.
Comments
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?
There are no values of a where a * a * a differs from a * (a * a), because floating-point multiplication is commutative.
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.
You have to be kidding. Otherwise, read up on the definition of “commutative” here: http://en.wikipedia.org/wiki/Commutative_property
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.
You're right of course. I was thinking about associtivity, not seeing what's really written. Sorry. I didn't expect discussing commutativity in the context (it's the non-associativity that doesn't allow all the "automatic" optimizations expected by some) where the formula in the same sentence is with three elements and the different order of computation. Which doesn't change the fact that I've made an error.
No, fp (IEEE-745) + and * are both commutative. They aren't associative or distributive in general.
Yep grouping can lead to better real accuracy. But then you lose exact IEEE compatibility (get slightly different results that will fail a comparison).
Thanks, I now see more clearly why this is important for comparisons :)
Speaking of comparisons... -Wfloat-equal will warn whenever you attempt to compare floats or doubles for equality.
Rule number one of floats: don't use == on them.
Pure cargo-culting. There are circumstances in which it’s perfectly appropriate to compare floating-point data for equality. There are also circumstances in which a comparison with some tolerance is more appropriate. Understand what situation you’re in, and understand the tools that you’re using.
Comparing floats for equality is equivalent to comparing them with tolerance that you don't control. I don't see a good reason to risk like that.
Comparing floats for equality is equivalent to a comparison with zero tolerance, not an uncontrolled tolerance.
Consider storing a timestamp as a number of seconds since the epoch. We might use == to check if the timestamp has changed.
Read the wikipedia entry on IEEE754-1985 (it has better diagrams than the main 754 entry): http://en.wikipedia.org/wiki/IEEE_754-1985#Representation_of...
Knowing is better than fearing.
No, it's not equivalent to that at all. Why would you think such a thing?
Oh, there must be a Common Lisp predicate that addresses this. prettymuchequalsp?
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.
Comparing floats is sometimes useful. For example, if you are testing that you have copied a data structure correctly.