Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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).





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!


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

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.


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.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: