替代構建啓發式和本地搜索階段

我有一個基於MeetingScheduling示例的案例。結果很好。調度從施工啓發式階段開始。然後有一個本地搜索階段。 CH階段減少了硬性和中等約束懲罰，而LS似乎減少了軟約束懲罰。替代構建啓發式和本地搜索階段

我發現當我重新運行調度時，CH階段再次減少了硬性和中等約束懲罰。那麼，我們可以配置解算器多次交替CH et LS階段嗎？

當前的求解器的配置：

<?xml version="1.0" encoding="UTF-8"?> 
<solver> 
    <solutionClass>org.optaplanner.examples.meetings.domain.MeetingSchedule</solutionClass> 
    <entityClass>org.optaplanner.examples.meetings.domain.Meeting</entityClass> 

    <scoreDirectorFactory> 
    <scoreDrl>org/optaplanner/examples/meetings/solver/meetingsScoreRules.drl</scoreDrl> 
    </scoreDirectorFactory> 

    <termination> 
    <minutesSpentLimit>20</minutesSpentLimit> 
    </termination> 
</solver>

來源

2017-05-29 supertanuki

是否存在「重複計劃」（請參閱文檔，兩次運行之間的問題更改）或「重新加熱」用例（延遲接受和模擬退火中的缺失功能）？奇怪的是，第二個CH運行沒有問題，事實上的變化會產生不同的結果，除非你使用nullable = true，在這種情況下它是可能的。 –

這應該工作：

<solver> 
    ... 
    <constructionHeuristic/> 
    <localSearch> 
    <termination>...stepCountLimit or calculateCountLimit?...</termination> 
    </localSearch> 
    <constructionHeuristic/> 
    <localSearch> 
    <termination>...stepCountLimit or calculateCountLimit?...</termination> 
    </localSearch> 
    <constructionHeuristic/> 
    <localSearch> 
    <termination>...stepCountLimit or calculateCountLimit?...</termination> 
    </localSearch> 
</solver>

而且隨着程序化的API可以使其動態爲n。

這就是說，這可能是次優解決方案。正確的解決方案是重新加熱（尚未支持）。

來源

2017-05-29 14:58:25

謝謝，它的作品！ – supertanuki

替代構建啓發式和本地搜索階段

回答

相關問題