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

[David Kastrup]

mclaren <address@hidden> writes:

> It's pretty clear from the nature of the bugs that there was some internal
> rational integer calculation limit in lilypond. What's baffling is the way
> it's dealt with internally in lilypond. The procedure seems to be to do
> everything in 32 bit integers and then throw an error if that limit gets
> exceeded.  Moving to 64 bit integers would extend the range of possible
> musical inputs, but David Kastrup is right -- not by much. 2 x 10^19 as
> opposed to 4 billion for 32 bit ints.
>
> This is the way video games tend to deal with this stuff.

Music is not a video game.  LilyPond needs to know whether two events
line up in time (only then are they aligned or have a common stem, and
only the first such event gets an accidental and so on).  Once
arithmetic does no longer guarantee

    1/3 + 1/3 + 1/3 = 1

it becomes impossible to reliably synchronize matters.

> They use 32 bits integers or 64 bit integers and that's typically good
> enough for the game spaces they're dealing with.

They have a bounded universe there.  You can't tell a musician "10000
beats, and you are out since then our fixed point numbers overflow".  Or
"10000 beats and you can't use triplets any more since then our floating
point numbers get too grainy."

For better or worse, written music requires exactness to work reliably.

> A long time ago I had to work on an 8 bit microcontroller and write my
> own floating point routines.  With the small amount of RAM and the
> slow CPU speed (4 MHz back then), you quickly started to throw
> errors. The better solution seems like figuring out what a practical
> integer limit is and then dump the intermediate result into floating
> point, then recast as an integer on the final output. The range of
> floating point values is large, somwhere in the ballpark of 1 x 10^300
> if memory serves. You typically don't run into those limits unless you
> encounter really exotic situations.

I wrote video games in my youth on 8 bit computers and timed them
(including every single toggle of the 1bit speaker output) by manually
counting all the execution cycles of every machine instruction (and the
assembly was hand-written).  I've worked with fixed-point, floating
point, residual polynomial fields and a number of other stuff.  I know
my shit, and Han-Wen and Jan, responsible for much of the design
decisions underlying LilyPond, did too.

What you don't seem to understand is that you are not dealing with
idiots who were just waiting for you to pour out your wisdom so that
they then are able to solve all of your problems.

There are deliberate reasons and tradeoffs involved in LilyPond's
design.  There may be some programming mistakes, and some of the reasons
and tradeoffs might be based on history that is no longer immanent.  But
all in all, there is a reason for everything that cannot even remotely
be characterized as "people just weren't as smart as mclaren or they'd
have done it better".

If you want something done, do it.  You are of the opinion that you can
do better than those who worked so far on LilyPond, do it.  Don't beat
your chest, do it.  Stuff in LilyPond gets done by people doing what
they can much more by people telling other people what they should.

And if you believe everybody else to be too stupid to do stuff like you
know it should be done, there really is no other option than doing it
yourself.

-- 
David Kastrup