On Feb 2, 2011, at 9:32 PM, Han-Wen Nienhuys wrote:
On Thu, Feb 3, 2011 at 12:26 AM, address@hidden
<address@hidden> wrote:The most recent patch set only has a single pass through beam quanting. Idon't believe it adds significant overhead to a score's compile time,although I'd need someone to do some benchmarking to verify that.http://codereview.appspot.com/4022045Han-Wen: could you summarize again your main objections to this approach? I
I think the collisions should be done as part of the scoring, not as a
separate function that happens afterwards. I also think that any
notion of 'pressure' should follow automatically from the scoring.
New patchset at http://codereview.appspot.com/4022045 that makes changes to fit with Han-Wen's new beam-quanting code .
It seems to me that the idea behind quanting is "given that we have the beam more or less in an appropriate region and at a good slope, find the best configuration for that beam in said region and around said slope."
In the attached example bad.png, I have a difficult time conceiving of how the quant scoring function could anticipate and account for the huge region size that would be necessary to find this collision. It goes against the "given" above that the beam lies in a reasonable region.
The example better.png shows a beam with collision avoiding applied before quanting but with quanting commented out of define-grobs.scm . Note that the beam is now in a region where quanting can be done.
The example best.png adds in the quanting function.
Given that pressure needs to be calculated only once for the entire beam, it seems that it should not be called in any of the score_X_quants functions. I cannot see a reason why this code would be in beam-quanting.cc and something like slope_damping would be in beam.cc . It seems that collision avoidance, like slope damping and shifting, is a precondition of best beam placement and thus belongs before quanting.
Cheers,
Mike
