Сценарий, в котором свойства зависят от значений фактов

Требуется пояснение относительно утверждения, что класс фактов проблемы используется ограничениями оценки, но НЕ изменяется во время планирования (пока проблема остается той же).

Может ли Optaplanner обрабатывать сценарии (и возвращать оптимизированное решение), в которых свойства проблемы зависят от значений фактов?

Например: в задаче «Маршрутизация транспортных средств» двигатель optaplanner может вернуть оптимизированное решение, основанное на том факте, что для перехода от Location_A к Location_B требуется больше времени (скажем, в 1,2 раза) для Vehicle_1, чем для Vehicle_0.

Точно так же в примере планирования заданий проекта Resource_X занимает 1,2 дня для выполнения задачи, а Resource_Y требуется 0,9 дня для выполнения той же задачи.


properties fact optaplanner
person Manish    schedule 23.02.2016    source источник
comment
Каждый из ваших предметных классов является либо проблемным фактом, либо планируемой сущностью. Разница в том, что последнее изменяется во время планирования, а первое изменяется только во время ProblemFactChange или перед вызовом метода resolve ().   -  person Geoffrey De Smet    schedule 24.02.2016

Ответы (1)


arrow_upward
0
arrow_downward

Да, может. Это действительно так. Есть несколько способов спроектировать / реализовать это. Вот тот, который я предпочитаю:

@PlanningEntity class TaskAssignment {
     Task task;
     @PlanningVariable Employee employee;

     public int getDuration() {
         // Warning: If affinity's or task types would change during planning (except during real-time planning ProblemFactChange of course),
         // we would need to do this through DRL or break incremental score calculation.
         return employee.getAffinityTo(task.getType()).getDuration();
     }

}


rule affinityBasedDuration
when
   TaskAssignment(employee != null, $d : duration)
then
   // addSoft(-$d)
end

Вы даже можете передать аргументы:

when
    $a : TaskAssignment($id : id)
    $b : TaskAssignment($id < id, $d: calculateOverlap($a))
then
   // addSoft(-$d)
end


@PlanningEntity class TaskAssignment {
     ...

     public int calculateOverlap(TaskAssignment other) {
         // calculate overlap with this.startTimestamp vs other.startTimestamp
         // and this.endTimestamp vs other.endTimestamp
     }

}
person Geoffrey De Smet    schedule 24.02.2016