[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lilypond performance
From: |
David Kastrup |
Subject: |
Re: Lilypond performance |
Date: |
Tue, 10 Aug 2010 11:32:06 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
Urs Liska <address@hidden> writes:
> Well, this seems a misunderstanding, mainly due to my English and the
> fact, that I only have very intermediate programming experience with
> very little theoretical background.
> I think basically we want to say the same thing :-)
I consider this extremely unlikely.
> I don't find it natural to "walk through" the music from beginning to
> end.
I should think that this is the only reasonable direction. And indeed,
this is what Lilypond essentially does (or did at one time), keeping and
maintaining a pruned tree of possibilities as an internal data
structure. Keeping the width of the maintained parts of the tree pruned
to a maximum width is the art of linear programming.
> What I wanted to say is: Only if this would be possible one could
> expect a linear increase in processing time with longer scores. As it
> is not possible I find it "natural" that processing time increases
> exponentially.
I suggest you make yourself acquainted with "linear programming". It is
not likely that we get to understanding each other when working from
incompatible theoretic assumptions.
> Maybe there are possible algorithms to substantially simplify or
> streamline the tasks lilypond has to do - I don't have the theoretical
> background to tell.
> But if it's not possible (which I assume), all I wanted to say is that
> you can only work around the problem with better hardware.
Again: you can't work around exponential complexity for problems of
variable size with "better hardware". If you think otherwise, you are
likely employing "exponential complexity" as a buzzword rather than in
its actual meaning.
--
David Kastrup
- Re: Lilypond performance, (continued)