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.
--
Han-Wen Nienhuys - [email protected] - http://www.xs4all.nl/~hanwen
_______________________________________________
lilypond-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-devel