问题描述
我正在为解决方案领域优化构建启发式
@ValueRangeProvider(id = "timeRange")
public CountableValueRange<LocalDateTime> timeRange() {
final LocalDateTime start = LocalDateTime.Now().plusHours(1).truncatedTo(ChronoUnit.HOURS);
final LocalDateTime end = LocalDateTime.Now().plusYears(1).truncatedTo(ChronoUnit.HOURS);
return Stream.iterate(start,d -> d.plusHours(1))
.takeWhile(localDateTime -> localDateTime.isBefore(end))
.collect(Collectors.toList());
}
此@ValueRangeProvider为LocalDateTime模型中使用的开始和结束之间的每个小时提供Time Grain个实例。 timeRange值范围是@PlannningVariable类中唯一的@PlanningEntity。
我还有以下solverConfig.xml：
<?xml version="1.0" encoding="UTF-8"?>
<solver xmlns="https://www.optaplanner.org/xsd/solver" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://www.optaplanner.org/xsd/solver/solver.xsd">
<scanAnnotatedClasses/>
<scoreDirectorFactory>
<constraintProviderClass>org.acme.optaplanner.solver.MyConstraintProvider</constraintProviderClass>
<initializingscoreTrend>ONLY_DOWN</initializingscoreTrend>
</scoreDirectorFactory>
<termination>
<bestscoreFeasible>true</bestscoreFeasible>
</termination>
<constructionHeuristic>
<constructionHeuristicType>FirsT_FIT</constructionHeuristicType>
<changeMoveSelector>
<selectionorder>ORIGINAL</selectionorder>
</changeMoveSelector>
<constructionHeuristic>
</solver>
在构造试探法期间，对象初始化比解决方案的质量更为重要。只要有足够的时隙，就不会发生硬约束。
我意识到先前的步骤使用的@ValueRangeProvider(id = "timeRange")值将在构造启发式方法的后续步骤中重复使用。
1772 [main] DEBUG o.o.c.i.c.DefaultConstructionHeuristicPhase - CH step (0),time spent (157),score (-999init/0hard/-1soft),selected move count (1),picked move (Lesson{id=1,subject='Math I',pinned=false,startTime=null,durationInGrains=3} {null -> 2020-09-27T09:00}).
.
.
.
02:01:26.494 [main ] DEBUG CH step (497),time spent (14513),score (-502init/0hard/-5542soft),selected move count (664),picked move (Lesson{id=498,durationInGrains=3} {null -> 2020-11-10T12:00}).
02:01:26.565 [main ] DEBUG CH step (498),time spent (14584),score (-501init/0hard/-5548soft),selected move count (666),picked move (Lesson{id=499,durationInGrains=1} {null -> 2020-11-10T14:00}).
.
.
.
17456 [main] TRACE o.o.c.i.c.d.ConstructionHeuristicDecider - Move index (0),score (-500init/-2hard/-5571soft),move (Lesson{id=500,durationInGrains=2} {null -> 2020-09-27T09:00}).
.
.
.
02:01:26.637 [main ] DEBUG CH step (499),time spent (14656),score (-500init/0hard/-5557soft),selected move count (667),picked move (Lesson{id=500,durationInGrains=2} {null -> 2020-11-10T15:00}).
02:01:26.711 [main ] DEBUG CH step (500),time spent (14730),score (-499init/0hard/-5568soft),selected move count (668),picked move (Lesson{id=501,durationInGrains=3} {null -> 2020-11-10T16:00}).
02:01:26.787 [main ] DEBUG CH step (501),time spent (14806),score (-498init/0hard/-5581soft),selected move count (670),picked move (Lesson{id=502,durationInGrains=1} {null -> 2020-11-10T18:00}).
.
.
.
02:17:46.156 [main ] INFO Construction Heuristic phase (0) ended: time spent (98518),best score (0hard/-11165soft),score calculation speed (6783/sec),step total (1000).
02:17:46.165 [main ] INFO Solving ended: time spent (98527),score calculation speed (6776/sec),phase total (2),environment mode (NON_REPRODUCIBLE).
在{strong> CH步骤（0）和 CH步骤（499）中使用了LocalDateTime的{{1}}。
由于我有一个严格的约束条件，即两个2020-10-01T09:00不能使用相同的@PlanningEntity值，所以我想知道是否可以删除使用的timeRange值以供将来使用？
作为示例；
我更改了timeRange的配置
constructionHeuristic这会导致构建试探法具有更快的性能，因为该步骤是随机选择
<constructionHeuristic>
<constructionHeuristicType>FirsT_FIT</constructionHeuristicType>
<changeMoveSelector>
<selectionorder>RANDOM</selectionorder>
</changeMoveSelector>
<forager>
<pickEarlyType>FirsT_FEASIBLE_score_OR_NON_DETERIOrating_HARD</pickEarlyType>
</forager>
</constructionHeuristic>
的{{1}}。
@Planningvariables是否有足够的方法来限制使用预先使用的值范围的步骤？有回扣吗？
解决方法
暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！
如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。
小编邮箱:dio#foxmail.com (将#修改为@）