Re: Issue 37 - new work

[Han-Wen Nienhuys]

On Fri, Jan 28, 2011 at 11:55 AM, address@hidden
<address@hidden> 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 - address@hidden - http://www.xs4all.nl/~hanwen