Re: Introduce Beam_scoring_problem::quant_range, for quickly filtering out invalid positions. (issue4129050)

[mtsolo]

LGTM, but I can't do a regtest today :(


http://codereview.appspot.com/4129050/diff/1/lily/beam-quanting.cc
File lily/beam-quanting.cc (right):

http://codereview.appspot.com/4129050/diff/1/lily/beam-quanting.cc#newcode215
lily/beam-quanting.cc:215: }
Very cool stuff!
I won't have time to do a regtest today, but I see what you're doing and
it makes a lot of sense.
One suggestion: perhaps we should create an enum:
enum Stem_dir_scenarios { ALL_UP, ALL_DOWN, DOWN_TO_UP, UP_TO_DOWN,
WACKY } that provides a tag for the beam which is then used in this
function.  My rationale is as follows:


There are several functions that cycle through all the stems of a beam
before we get to this one (the slope calculating function, for example).
 If this distinction can be added to a beam before you get here, it can
save you a bit of code-duping and it can also constrain the problem even
further.  If I'm reading this correctly, you're accounting for the first
four scenarios in the enum proposed above but not the 5th, where there
are stems do not go uniformly from one direction to another (something
like c,,16 [c''''' c,, c''''' c,, c,, c'''' ] may do the trick).  In
this case, you could squish the range even more on the ed side - it
would look a lot like your code for the -ed side.

http://codereview.appspot.com/4129050/