[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rational

From: David Kastrup
Subject: Re: Rational
Date: Wed, 23 May 2018 09:14:57 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

metachromatic <address@hidden> writes:

>   To get back to practicalities, here is an absolutely minimal example
> of the alleged problems with using rationals as internal
> representations of durations/positions in Lilypond.

It is a known problem with know workarounds (basically you need to apply
scaling factors bringing back the actual durations to a reasonably
fine-grained raster) and Midi cannot represent arbitrary rationals

>    "So what's wrong?" you say. "What's the problem?"
>    Here's the problem: uncomment the third to last tuplet and rerun Lilypond.
>    Then uncomment the second to last tuplet and rerun Lilypond.
>    Now rerun the last tuplet and rerun Lilypond.
>    Attached as a PNG, the output for
>    A) last 3 tuplets commented out.
>    B) last 2 tuplets commented out.
>    C) no tuplets commented out.
>    Let's assume that I'm a moron with a room-temperature IQ and, as
> our friend Kieran McMullen has remarked, "You have no idea what you're
> talking about." Fine, assume I'm not only dumb as a box of rocks, but
> also hopelessly ignorant.

You don't understand the problem you are failing to deal with.  It is
not a technical problem but a social one.  You are trying to get people
to work for you by cussing at them.  That may work on people getting
your pay checks from you, at least until they leave for employers with a
better appreciation of their work, leaving you with less capable

It doesn't when you are talking to volunteers.

>    So since we can't take my word for it, how do we actually _know_
> that the internal representation of integers is making Lilypond blow
> up when it tries to generate a score for more than the first 7 tuplets
> in the above example?

It's reasonably easy to create an engraver giving out the current time.

>    Now, why did Lilypond's internal position jump to such large
> numbers merely by uncommenting one measly little tuplet?
>    Because all the tuplets are prime. Evidently, no programmer ever
> imagined any composer would want to use a bunch of tuplets that were
> prime numbers.

Well, evidently no composer with the brains to apply rational
adjustments to his note lengths to coax LilyPond into cooperation or a
rational style of discussion with people supposed to help him for free.

€6000 and the temporary fix is yours.  Temporary because we are talking
about systematic input like this not failing after 3 measures but after
20 while LilyPond is pretty much crawling to halt.

For proper typesetting of things, LilyPond needs to know whether two
notes happen simultaneously or not.  Even timing differences that are
not distinguishable acoustically need to be distingushed visually (one
stem or two?).  So it uses exact arithmetic.  It's only you who can
decide which notes in an arbitrarily fine raster coincide and round them
to identical point on a fine raster, giving them a common stem.

Really, you have to understand that this is a well-known issue
extraordinarily hard to even mitigate (due to even Guile/GMP integers
being ultimately limited in size and you deliberately growing them in
size) and you are trying to fix it with name-calling and a show of

>   Now, call me overly picky, but it seems to me that in the 21st
> century, with multicore CPUs and 16 gigs of RAM and a modern language
> like Scheme and expert programmers, we really seriously ought to be
> able to do better with a program like Lilypond than....

[Rest of condescending rant clueless about the actual problems involved
here deleted]

Go ahead.  It should be simple for such a smart guy as yourself to fix
it.  Not talk about how others are supposed to fix it, but rather fix it
yourself.  Obviously your level of intelligence is so far above that of
LilyPond's programmers that you should be done in a week.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]