4 ms·
> More subtly, but perhaps more damaging, they break properties like associative and commutative. No: commutativity of multiplication and addition still holds,
by wolfgke 12y ago
> More subtly, but perhaps more damaging, they break properties like associative and commutative.
No: commutativity of multiplication and addition still holds, but associativity indeed does not. That associativity does not hold is a much more unpleasant than if associativity would hold but commutativity wouldn't (the mathematics of common associative, but non-commutative structures is understood quite well, say (non-abelian) groups and monoids).
- ColinDabritz 12y agoAh yep. I was mixing things up a bit. The one that surprised me was that, in some cases: Large + small + small + small =! small + small + small + = Large Which is indeed associativity. Really underscores how complex things are.
- richardwhiuk 12y agoThe other typically expected property that fails is distributivity.
- ColinDabritz 12y agoSo for floats: a ( b + c ) != a * b + a * c (in some cases)
- zwegner 12y agoActually commutativity doesn't hold either, because of dealing with NaNs (at least on x86, on a quick search I can't find a reference for whether this behavior is part of IEEE 754 or just implementation defined). Operations with two NaNs will give the first operand. You can see this with a quick test program: #include <stdio.h> int main() { unsigned long long bits = 0x7FFC000000000000; double x = *(double *)&bits; bits += 1; double y = *(double *)&bits; double z = x + y, w = y + x; printf("%llx %llx\n", *(unsigned long long *)&z, *(unsigned long long *)&w); } Of course, this probably doesn't matter for most applications.
- stephencanon 12y agoIEEE-754 says that the result “should” be one of the two input NaNs. A platform could choose to e.g. take the NaN with the smaller payload to make * and + commutative, or it could simply define away NaN payloads entirely.