# Floating point addition not associative

Can anybody explain the following behavior?

x = 0.2 + (0.3 + 0.1);
y = (0.2 + 0.3) + 0.1;
x == y (* -> True *)


But actually the variables do not exactly contain the same values:

x // FullForm (* -> 0.6000000000000001 *)
y // FullForm (* -> 0.6 *)


The example was taken from Mike Croucher's blog entry.

-
The answer to this question was actually mentioned in the link you provided, read it again. –  DumpsterDoofus Mar 2 at 4:10

As rasher and the documentation both say, Equal has a certain level of fuzziness. The same is true of SameQ, though it has a more stringent tolerance. The following computations are all done with machine precision numbers. Similar things should hold with arbitrary precision numbers but the analysis might be trickier.

(* 12 zeros, difference = 1.00142*10^(-13) *)
1.0000000000001 == 1.0000000000002
(* Out: False *)

(* 13 zeros, difference = 9.992*10^(-15) *)
1.00000000000001 == 1.00000000000002
(* Out: True *)

(* Same as last with SameQ *)
1.00000000000001 === 1.00000000000002
(*Out: False *)

(* 15 zeros, difference = 2.22045*10^(-16) *)
1.0000000000000001 === 1.0000000000000002
(* Out: True *)


It might also be worth mentioning that more traditional floating point comparisons can be easily emulated. For example, since the "fuzziness" is based on Precision, we can check if the difference is equal to zero.

x = 0.2 + (0.3 + 0.1);
y = (0.2 + 0.3) + 0.1;
x == y
x - y == 0.0

(* Out1: True *)
(* Out2: False *)


Certain compiler switches also make comparisons more C-like.

test1 = Compile[{}, 0.2 + (0.3 + 0.1) == (0.2 + 0.3) + 0.1];
test2 = Compile[{}, 0.2 + (0.3 + 0.1) == (0.2 + 0.3) + 0.1,
RuntimeOptions -> "Speed"];
test1[]
test2[]

(* Out1: True *)
(* Out2: False *)

-
See the documentation for Equal. There is a tolerance for inexact numbers. The order of operations combined with precision of targets can affect whether things fall "in" or "out" of tolerance. See specifically the "Possible Issues" section in the documents for Equal. As far as why results themselves differ in FP arithmetic, there is no better source than the paper referenced in the blog entry.