I'm not sure what you mean by this. It is true that two compliant systems will produce the same output for the same sequence of inputs, but that isn't the entir

I'm not sure what you mean by this. It is true that two compliant systems will produce the same output for the same sequence of inputs, but that isn't the entire scope of when the concept of "equals" might matter. > Tiny discrepancies don't randomly appear during float operations They don't "randomly" appear, because as you say IEEE 754 is well-defined, but discrepancies _do_ appear, and if you care about the concept of equality, they certainly matter. Take a trivial example in C: #include <stdio.h> int main(void) { volatile double a, b, c, d, e; a = 5.0; b = a/3.0; c = b/3.0; d = c/3.0; e = d*27.0; if (a==e) printf("EQUAL\n"); else printf("NOT EQUAL\n"); return 0; } I think everyone would agree that 5 / 3 / 3 / 3 * 27 = 5, or in general that a / 3 / 3 / 3 * 27 = a. But this program, when executed on a system properly implementing IEEE 754, will report that a and e are not equal. Their bits are different. Hence why when you're talking about comparing equality of IEEE 754 values, you can't just do a comparison of the bits in storage. You're right that all (correctly implemented) systems will accumulate errors in the same way (assuming you've selected the same rounding mode, etc.), but I don't see how that negates the need to handle the fact that the representation in memory of e will not equal a even though they _should_ represent the same value. Given the sequence of operations performed, how much "slop" should you allow when comparing a to e? Certainly more than 0 which a bit-by-bit comparison implies.