我使用的是增量分数计算器类,因为大量使用地图和计算方法在流口水中无法很好地扩展。
似乎运行良好,但是由于必须调试,所以我注意到最终解决方案中使用的移动数量与我的before / afterVariableChanged处理程序处理的移动之间存在差异。这导致解决方案中实际分配的值与增量分数对象中的状态之间的差异。根据一些日志,增量文件似乎不知道解决方案何时由于提前终止而停止接受移动(我正在使用secondsSpentLimit)。
我如何阻止我的增量计分成绩要求收到由于提前终止而不会在解决方案中考虑的before / afterVariableChanged事件?
您是否可以打开TRACE
记录以确认此行为?
本质上,LocalSearch看起来像这样(moveThreadCount=NONE
(=默认值):]
for (each step && not terminated) {
stepStarted()
for (each move && not terminated) {
doMove(); // Triggers variable listeners
if (better move) updateBestSolution();
undoMove(); // Triggers variable listeners
}
stepEnded()
}
所以终止是原子对移动评估。因此,您的问题应该还有另一个原因。
[moveThreadCount=4
等使这个故事变得有点复杂,但是每个移动线程都有其自己的ScoreDirector,因此它们几乎都是独立工作的。
话说回来,增量Java分数计算和阴影变量一起可能使人发疯……这主要是由于before
事件发生在doMove()的中间,就在变量更改之前。那时,由于移动的其他变量已经在变化,模型的一半可能已经处于无法理解的中间状态。 FWIW,看看VariableListener.requiresUniqueEntityEvents()
,可能会有所帮助...或尝试使用ConstraintStreams(如果您希望速度胜于功能,请执行BAVET)。