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. > "a + (b + c) is close but not equal to "(a + b) + c" is different > from "a + (b + c)" works whereas "(a + b) + c" errors out (in Scheme) > or doesn't compile (in C++)". > Agreed. Although in this case you'd have a being a Moment and b and c being spans, so either association would be correct (and identical in value given they're rationals). But yes, yes of course, in general. > From what I've heard, GOOPS used to be inefficient at dispatching > virtual calls. This problem is apparently gone now. > Right. > Boxing and unboxing has a certain cost, but LilyPond is not optimized > to the point that thinking about it causes significant savings. The > order of the most worthy optimizations is more high-level. > Yes, that'd be my expectation too. I think we all agree that these are good things in > any software projects. The question is whether a > given change will contribute enough to these goals > to be worth it compared to its costs and downsides. > Absolutely. L -- Luca Fascione
