On Jan 29, 2011, at 10:10 AM, Han-Wen Nienhuys wrote:
> On Fri, Jan 28, 2011 at 11:55 AM, [email protected]
> <[email protected]> wrote:
>>> Despite the joke, this is a semi-serious suggestion that I've been
>>> hoping that somebody might be interested in for years. There's a
>>> bunch of options that we can enable or disable to change the
>>> amount of processing power; it would be really nice if one (or
>>> more) people seriously looked into this, and provided an easy way
>>> to change between the "optimization" levels.
>>
>>
>> I completely agree. I think that the beam collision engraver > (if it makes
>> it into lilypond) is the prime example of
>> something that could be included or left out with
>> optimization flags. There can even be multiple collision
>> engravers that perform the same task but provide different
>> levels of optimization.
>
> In the case of the beam scoring specifically, I disagree: there are
> many ways to search more cleverly in the problem space.
>
> For beams specifically, how about this one:
>
> choose large region size
> calculate cheapest of the scoring functions for all configurations
> put configurations in a min-heap
>
> while (true) {
> take minimum score configuration from heap
> if conf has passed all scoring functions
> break // found optimum
> add another scoring function to configuration // *
> insert result in heap
> }
>
> for the common cases, this will skip computations for many of the more
> extreme cases. At //* , there is still some option of further
> optimization by doing an intelligent choice between what to run next.
>
> The same approach should work well for slurs as well.
>
> If I find time one of these days (may be next week), I'll try to implement
> this.
>
Hey Hanwen,
What you describe above is close-ish to what I wound up putting in my newest
patch, which only has one pass thru the quanting function. It does all the
quant scoring, then does one last pass to check for collisions. This is done
through allowing "negative" pressure, or an amount of leeway that a beam has to
move in a direction before it will collide with something.
http://codereview.appspot.com/4022045/
Cheers,
MS
_______________________________________________
lilypond-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
