Hacker News Reader

Comment by wtallis | Hacker News Reader

"a+b+c" doesn't describe a unique evaluation order. You need some parentheses to disambiguate which changes are due to associativity vs commutativity. a+(b+c)=(c+b)+a should be true of floating point numbers, due to commutativity. a+(b+c)=(a+b)+c may fail due to the lack of associativity.

View on HN

It is not, due to precision. Consider a=1.00000, b=-0.99999, and c=0.00000582618.

You still need to specify an evaluation order …

Does (1.00000+-0.99999)+0.00000582618 != 0.00000582618+(-0.99999+1.00000) ? This would disprove commutativity. But I think they're equal.

No, the two evaluations will give you exactly the same result: https://play.rust-lang.org/?version=stable&mode=debug&editio...

IEEE 754 operations are nonassociative, but they are commutative (at least if you ignore the effect of NaN payloads).

Is there a case involving NaN where they are not commutative? Do you mean getting a different bit-level representation of NaN?

In practical use for simd, various min/max operations. On Intel at least, they propagate nan or not based on operand order

Also all comparisons.

IEEE 754 doesn't (usually) distinguish between different NaN encodings for the purposes of semantics--if the result is a NaN, it doesn't specify which NaN the result is. Most hardware vendors implement a form of NaN propagation: when both inputs are NaN, one of the operands is returned, for example, always the left NaN is returned if both are NaN.

As a side note: all compilers I'm aware of make almost no guarantees on preserving the value of NaN payloads, hence they consider floating-point operations to be fully commutative, and there's no general way to guarantee that they evaluate in exactly the order you specified.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

You're supposed to do (a+b) to demonstrate the effect, because floating point subtraction that results in a number near zero is sensitive to rounding (worst case, a non-zero number gets you a zero number), which can introduce a huge error when a and b are very similar numbers.

When you go from (a + b) + c to a + (b + c), you're invoking the associative property, not the commutative property.

The confusion between associativity and commutativity is the entire point of this thread!

Reply on news.ycombinator.com