Re: Solution to 7 over sqr(71) time against integer polyrhythms

[David Kastrup]

Urs Liska <address@hidden> writes:

> And it's totally clear that you're messing with things you're not up
> to.

That's what every LilyPond user is going to start with, and given the
scope of the project, I doubt that there is anybody who could claim
himself to be free of that even when experienced.

This is not the problem.  The problem is the manner in which you choose
to deal with it.

> Nobody is "attacking" you inappropriately, and you can't claim to
> "point out bugs". So far we have seen only one case where LilyPond
> actually shows a limitation in its ability to deal with huge rationals
> in tuplets or time signatures.

LilyPond has limits in the size of the rationals it is dealing with.
Those limits are based on 64bit integers and it appears like some
operations are implemented in a manner where intermediate results may
exhaust those 64bit even when operands and results are barely in excess
of 32bit.

Fixing that part of the range restriction is comparatively simple.
I think I have some branch in my repository where I tackled what
I considered the most likely piece of code responsible for it.

However, even a 32bit range is exceeded only for intentionally large
denominators, like arithmetic progressions or primes in the denominator
or high-precision rational approximations.  So finding and routing out
the causes of the 32/64 bit discrepancy will only cause a very temporary
breath of relief as the same reasons that will exhaust 32bit numbers as
fraction constituents will quickly scale up to take down 64bit numbers:
the minimal example for that will, when written explicitly, likely be
only about twice as long as the one downing the 32bit range.

The "arbitrary precision" rationals of Guile would help a lot more here
even though they still will eventually slow down the system to a crawl,
eat wagonloads of memory, and finally be exhausted in size too (but a
few millions of digits tend to go a long way anyway).  However, they
require working with garbage collection.  And musical moments are used
in data structures in the Midi backend that are entirely out of Guile
data structures (and consequently its garbage collection) right now.

"we have seen only one case where LilyPond actually shows a limitation"
is disingenuous: this is a clear and well-known architectural limit of
the current code base's operation and it is by far not trivial to
overcome.

I have a few branches in my private repository where I have been working
on some parts.  It's not been an urgent issue, and this does not
particularly change because one might hope it would make someone behave
less obnoxiously on the mailing list: it would seem optimistic to think
that addressing a single issue would magically cause a complete
conversion of character.

Of course, anything of the "if you want to do $x, there really is no
choice but to use LilyPond" variety is nice to have.

But the long and the short of it is that LilyPond does have limitations
in that area.  That they are irrelevant to the vast majority of use
cases people have for typesetting music does not mean that there is a
point in discussing them away: mclaren is not wrong about them being
there, and on that point he will "win" any "discussion".

His manner of winning isn't getting any of us including him anywhere,
however, so there is no point in engaging in those skirmishes.

-- 
David Kastrup