One additional problem is that IEEE floating point fails to require that addition and multiplication be commutative.<p>"WHAT?", you say? Surely it has to be commutative!<p>Well, it is, except in cases where both operands are "NaN" (Not a Number). You see, there's not just one NaN, but many, with different "payloads", intended to indicate the source of the error leading to a NaN. The payload gets propagated through arithmetic. But what happens when both operands are NaN, with different payloads? The standard says that the result is one or the other of these NaNs, but leaves unspecified which.<p>The old Intel FPU chose the NaN with the larger payload, which gives results independent of the operand order. But SSE uses the payload from the first operand. And so we get non-commutative addition and multiplication.<p>The compilers, of course, assume these operations are commutative, so the results are completely arbitrary.<p>One practical effect: In R, missing data - NA - is implemented as a NaN with a particular payload. So in R, if you write something like NA+sqrt(-1), you arbitrarily get either NA or NaN as the result, and you probably get the opposite for sqrt(-1)+NA. And both might vary depending on the context in which the computation occurs (eg, in vector arithmetic or not).