[Dennis Sweeney <sweeney.dennis650@gmail.com>]
The non-associativity isn't just signed zeros: regular floating point addition and multiplication of positive numbers is not associative
Yes, but that's shallow, having to do with rounding errors. In the example I gave, the "inexact" flag never gets set. As far as 754 is concerned, every infinitely precise result was exactly representable.Replace, e.g., "pz = 0.0" with "pz = 12345.0" in my examp\le, and associativity is not violated. Indeed, it's routine (in some circles) to use the `decimal` module for exact bigint arithmetic, setting the Inexact trap to verify that you've specified enough precision for that "to work" So long as Inexact doesn't trigger, you can be confident that your final results are exactly right. This isn't "abuse". It's one of the _intended_ uises for the inexact flag/trap; Except in the presence of signed zeroes, where, if Z is a zero, Z + (-Z) -> +0;0 is a made-up (arbitrary, unprincipled) rule (except under floor rounding, where it's replaced by an equally arbitrary rule). That's the source for why using the usual Cartesian rules for computing the product of complex numbers with signed zero components yields incoherent results. The failure h\as nothing to do with losing information, apart from some fuzzy conception of that "well, +0..0 means it underflowed from the positive direction, and despite that we haven't the slightest idea of what the true value is apart from the sign, we're going to pretend it's an exact input - and that its true value is larger than the absolute value of the equally unknown true value -0.0 represents - except under floor rounding, where we'll pretend the opposite". IOW, garbage in, garbage out ;-)