Optaplanner раннее завершение дельты между состоянием инкрементной оценки и решением

Question

Я использую класс калькулятора добавочных баллов из-за интенсивного использования карт и вычислений, которые плохо масштабируются в слюнях.

Кажется, это работает хорошо, но, поскольку мне пришлось отлаживать, я заметил различия между числом ходов, использованных в окончательном решении, и ходами, обработанными моими обработчиками before / afterVariableChanged. Это вызывает различие между тем, что фактически назначено в решении, и состоянием в моих объектах добавочной оценки. Судя по некоторым журналам, похоже, что инкремент не знает, когда решение перестало принимать ходы из-за досрочного завершения (я использую secondsSpentLimit).

Как я могу остановить получение добавочного балла от получения до / послеVariableChanged события, которые не будут учтены в решении из-за досрочного прекращения?

Answer 1

Можете ли вы включить 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()
}

Итак завершение - атомы c против оценки движения. Так что у вашей проблемы должна быть другая причина.

С moveThreadCount=4 et c эта история становится немного более сложной, но у каждого потока перемещения есть свой собственный ScoreDirector, поэтому они в значительной степени работают изолированно.

Как говорится, добавочный java подсчет очков и теневые переменные вместе могут сводить людей с ума ... Это в основном вызвано тем, что события before происходят в середине doMove (), прямо перед изменением переменной , В то время половина модели уже может находиться в промежуточном состоянии, которое невозможно понять из-за других переменных, которые уже менялись. FWIW, взгляните на VariableListener.requiresUniqueEntityEvents(), это может немного помочь ... Или попробуйте ConstraintStreams (реализация BAVET, если вы предпочитаете скорость перед функциональностью).