4 ms·
None of the common numeric systems in use on computers are commutative. IEEE-754 floating point is not. Integer types have over- and under-flow.
by wffurr 3y ago
None of the common numeric systems in use on computers are commutative. IEEE-754 floating point is not. Integer types have over- and under-flow.
- sriram_malhar 3y agoSure, but the GP alluded to "general purpose programming" in a separate comment, by which I take it they meant something like conventional python/Java code where one uses signed integers and doesn't worry about under/overflow.
- maemre 3y agoInteger overflows/underflows don't affect commutativity, unless you refer to undefined behavior, which is...undefined and found only in C and C++ among common languages. 2's complement integer arithmetic is commutative for both addition and multiplication. Thanks to BeetleB for pointing out that addition in IEEE floats is indeed commutative (I originally claimed "+0 + -0 = +0 vs. -0 + +0 = -0" which is incorrect). As for IEEE-754 floats, addition is commutative as long as you don't care about exact bit patterns: NaN + NaN may return different bit patterns. The result is still NaN, so the only way you can tell this apart is by bit-casting floats to ints or byte arrays. Multiplication over floats is also commutative modulo the caveat above.
- BeetleB 3y ago> +0 + -0 = +0 vs. -0 + +0 = -0 These are not exceptions. First, I will note that your result above depends on the rounding mode. Second, IEEE 754 mandates that +0 and -0 are equal (i.e. any equality operator should return True when comparing these two). Therefore both expressions are equal. NaN has several representations in bits, but they are all "equal" to one another.[1] If an operation gives you NaN, then so will doing it commutatively. It doesn't matter that the underlying bits are the same. [1] Except for the signaling aspect. But I believe that is preserved in commutative operations.
- maemre 3y agoYou're right, producing +/- 0 depends on the rounding mode and it is commutative, I forgot about that completely. I edited my comment to fix that claim. Also, yes, +0 == -0, but they can produce different results when used in the same expression, so the distinction does matter (although this doesn't affect commutativity, which is the larger point). For example, let f(x) = 1 / x. Then f(+0) = +inf, f(-0) = -inf. I also agree with you about NaN, that's why I mentioned having to go outside floating point numbers (bit-casting).
- a1369209993 3y ago> (I originally claimed "+0 + -0 = +0 vs. -0 + +0 = -0" which is incorrect) Specifically, (-0.0) + (+0.0) = (+0.0) + (-0.0) = +0.0 (assuming round-to-nearest-or-even). OTOH, (-0.0) + (-0.0) = -0.0. This has nothing to do with +0.0 == -0.0 for comparison, addition just is commutative outright[0]. 0: Pedantically, I'm not sure IEEE-754 requires the specific choice of which NaN you get when you do `some_nan + a_different_nan` versus `a_different_nan + some_nan` to be commutative, but it should.
- BeetleB 3y agoActually, they all are. They are not associative. If a + b results in an overflow, so will b + a.
- wffurr 3y agoThanks - I got that mixed up.