Maybe this question is stupid, but why does simply changing the order of the elements affects the result?

It will change the points at which the values are rounded, based on their magnitude. As an example of the *kind* of thing that we’re seeing, let’s pretend that instead of binary floating point, we were using a decimal floating point type with 4 significant digits, where each addition is performed at “infinite” precision and then rounded to the nearest representable number. Here are two sums:

```
1/3 + 2/3 + 2/3 = (0.3333 + 0.6667) + 0.6667
= 1.000 + 0.6667 (no rounding needed!)
= 1.667 (where 1.6667 is rounded to 1.667)
2/3 + 2/3 + 1/3 = (0.6667 + 0.6667) + 0.3333
= 1.333 + 0.3333 (where 1.3334 is rounded to 1.333)
= 1.666 (where 1.6663 is rounded to 1.666)
```

We don’t even need non-integers for this to be a problem:

```
10000 + 1 - 10000 = (10000 + 1) - 10000
= 10000 - 10000 (where 10001 is rounded to 10000)
= 0
10000 - 10000 + 1 = (10000 - 10000) + 1
= 0 + 1
= 1
```

This demonstrates possibly more clearly that the important part is that we have a limited number of *significant digits* – not a limited number of *decimal places*. If we could always keep the same number of decimal places, then with addition and subtraction at least, we’d be fine (so long as the values didn’t overflow). The problem is that when you get to bigger numbers, smaller information is lost – the 10001 being rounded to 10000 in this case. (This is an example of the problem that Eric Lippert noted in his answer.)

It’s important to note that the values on the first line of the right hand side are the same in all cases – so although it’s important to understand that your decimal numbers (23.53, 5.88, 17.64) won’t be represented exactly as `double`

values, that’s only a problem because of the problems shown above.