4 ms·

Commutativity has been abandoned? What?! Nothing could be farther from the truth! The requirement for order independence is literally everywhere … where would

Commutativity has been abandoned? What?! Nothing could be farther from the truth! The requirement for order independence is literally everywhere … where would we be without being able to add or do set unions or lattice joins without fear of getting the order wrong?! Imagine getting two different waveforms when adding one to the other, depending on the order!

lambdasquirrel 3y ago
Order independence is not a property of general-purpose programming. As much as we'd love for that to go away, it is very much a reality of day-to-day programmers.
- persnickety 3y ago
  There's plenty of commutative operations in everyday programming. a = f(c) b = g(d) can be rearranged if f and g take different input data, and calling independent functions is something seen literally everywhere in programming. Optimizing compilers often take advantage of that.
- sriram_malhar 3y ago
  Not sure what you mean by it not being a property of general-purpose programming. Do you mean it as, "I don't have to account for it in my day-to-day work"? If so, I agree with you, but not quite in the way you mean (I think). We don't account for it just as fish don't have to account for water. The fact that you can swap two rows in an excel file and have the results be unchanged is a property that we just take for granted. It needs to be pointed out how remarkable it is, because there are situations where this doesn't work. Debits and credits in finance are not commutative because of overdraft limits. I'm sure you know all this, so I'm curious what you really mean.
MereInterest 3y ago
I think the argument is more that commutivity of operations is context-dependent, even when the operation is written as multiplication. For example, knowing whether the terms of a multiplication can be commuted requires knowing whether the operands are scalars or matrices.
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 ago
  Sure, 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 ago
  Integer 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 ago
      You'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).

lambdasquirrel 3y ago

Order independence is not a property of general-purpose programming. As much as we'd love for that to go away, it is very much a reality of day-to-day programmers.

persnickety 3y ago
There's plenty of commutative operations in everyday programming. a = f(c) b = g(d) can be rearranged if f and g take different input data, and calling independent functions is something seen literally everywhere in programming. Optimizing compilers often take advantage of that.
sriram_malhar 3y ago
Not sure what you mean by it not being a property of general-purpose programming. Do you mean it as, "I don't have to account for it in my day-to-day work"? If so, I agree with you, but not quite in the way you mean (I think). We don't account for it just as fish don't have to account for water. The fact that you can swap two rows in an excel file and have the results be unchanged is a property that we just take for granted. It needs to be pointed out how remarkable it is, because there are situations where this doesn't work. Debits and credits in finance are not commutative because of overdraft limits. I'm sure you know all this, so I'm curious what you really mean.

MereInterest 3y ago

I think the argument is more that commutivity of operations is context-dependent, even when the operation is written as multiplication. For example, knowing whether the terms of a multiplication can be commuted requires knowing whether the operands are scalars or matrices.

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 ago
Sure, 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 ago
Integer 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 ago
    You'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).