A difficultyComparator is only to guide some search algorithms
(to find better solutions faster),
it in no way impacts the definition of the constraints. Several
algorithms completely ignore it.
hth
With kind regards,
Geoffrey De Smet
--
You received this message because you are subscribed to the Google Groups "OptaPlanner development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to optaplanner-d...@googlegroups.com.
To post to this group, send email to optapla...@googlegroups.com.
Visit this group at https://groups.google.com/group/optaplanner-dev.
For more options, visit https://groups.google.com/d/optout.
Yes, it's a constraint, so it should be in the score drl (if you're using the drools score director which is recommended).
Do note that I 've seen this trick, for what it might be worth:
rule
Employee($c : violationCount() > 0)
then
addHard...(..., - $c);
end
@PlanningEntity // SHADOW entity
class Employee {
@InverseRelationShadowVariable
List<Shift> shiftList; // Shift is the genuine planning
entity
public int violationCount() {
int count = 0;
// Iterate through shifts and check if they're in the desired
order
return count;
}
It doesn't combine easily with CHAINED vars though.
With kind regards,
Geoffrey De Smet
rule "Previous VehicleDay Less Used Than Current VehicleDay"
when
$vehicleDay : VehicleDay(
nextCustomer != null,
$vehicle : vehicle
)
$customerCount : Long() from accumulate (
Customer(
vehicleDay == $vehicleDay,
$demand : demand),
count($demand)
)
$vehicleDayBefore : VehicleDay(
nextCustomer != null,
vehicle == $vehicle,
day.getDayIndex() < $vehicleDay.getDayIndex()
)
$customerCountBefore : Long(intValue < $customerCount) from accumulate (
Customer(
vehicleDay == $vehicleDayBefore,
$demand : demand),
count($demand)
)
then
scoreHolder.addHardConstraintMatch(kcontext, $customerCountBefore.intValue() - $customerCount.intValue());
end