Oh yes absolutely, the growth is normally much slower than worse case unless the addends come from really weird-ass distributions, no doubt. Round to even helps a lot with that
And indeed our numbers not coming from measurements will in practice only have low significant bits in a handful of specific patterns (and all divides by power of two have a lot lot of low significant zeroes, which further helps) (Do you guys have a sense in practice how rare "odd" divisor groupings are? It seems like anything that's not a triplet or maybe a quintuplet would be real rare, no?) L On Sun, 5 Jun 2022, 16:42 David Kastrup, <d...@gnu.org> wrote: > Luca Fascione <l.fasci...@gmail.com> writes: > > > On Sun, Jun 5, 2022 at 2:12 PM Jean Abou Samra <j...@abou-samra.fr> > wrote: > > > >> As David already said, the part of LilyPond we're discussing is using > >> rationals. Furthermore, (a + b) + c being close but not equal to > >> a + (b + c) for floats is not really an issue for most parts of > LilyPond. > >> > > > > Yes, agreed on all points. I'd be surprised this would make a big > practical > > difference. > > The difference is there, but at worst it's one least significant bit per > > operation when floats are involved. > > It's tiny in practice. > > There tends to be "weak associativity" in that (((a+b)-b)+b)-b tends to > be the same as ((a+b)-b)+(b-b) in IEEE FP arithmetic using > "round-to-even" which helps a bit constraining progressive error > accumulation. > > But algebraically that isn't a lot of help, of course. > > -- > David Kastrup >
