Well said, naive summation of numbers with errors built into the geometry / representation of real numbers are def non associative when restricted to bounded / fixed size finite reps! (I like to point out to folks that if you take the log_2 transformation of each half of the real line and then do a uniform grid, then truncate that grid to a finite width interval on each half real line , that roughly gives you the floating point numbers ).
There’s a few different algorithms you can do for extended / high precision summation, though I don’t think they have the nice associative incremental algorithm we associate (hah!) with the summation and product monoids. But I would love to be wrong. Can we use some clever trick to have a higher precision constant space summation alg? Perhaps using eds compensated lib or something else under the covers ?
Imprecise calculation shouldn't be considered as a bug. Topologically speaking, floating point types are regarded as if they had countably infinite precision. So the elements in domain are positive reals, negative reals, the zeros, the infinities, and the NaN.
Hint: the problem has nothing to do with zeros.
λ> 0.1 + (0.2 + 0.3) == (0.1 + 0.2) + 0.3
False
Omg, addition is not even associative? The zeros truly ruined everything.
How is that worse than the fact that addition is already not associative for floating point types? At least +0 is really the identity up to (==).
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries