OptaPlanner：混合约束和基于 for-next 的分数计算

Question

I am implementing several restrictions within my CustomizedConstraintProvider class using the streaming API. Nevertheless there is one special case, where I currently do not see how to get this properly implemented within the streaming API.

If I got several methods...

private Constraint Restriction1(ConstraintFactory constraintFactory) {
   return constraintFactory
      .forEach(Class.class)
      ...
      .penalize("Restriction1", HardMediumSoftBigDecimalScore.ONE_HARD)
}

private Constraint Restriction2(ConstraintFactory constraintFactory) {
   return constraintFactory
      .forEach(Class.class)
      ...
      .penalize("Restriction2", HardMediumSoftBigDecimalScore.ONE_SOFT)
}

private Constraint Restriction3(ConstraintFactory constraintFactory) {
   return constraintFactory
      .forEach(Class.class)
      ...
      .penalizeBigDecimal("Restriction3", HardMediumSoftBigDecimalScore.ONE_MEDIUM,
       (a, b, c) -> BigDecimal.valueOf(Math.pow((b - c), a))
}

how can I implement one particular method (let's say "Restriction4" that runs with for-next loops, accessing the assignment lists and returning medium and soft scores at the end depending on the evaluation within the ConstraintFactroy approach? In the manual I only read this as an either or approach (TimeTableEasyScoreCalculator vs. TimeTableConstraintProvider in chapter 2 of the manual for the current OptaPlanner version 8.19.0). I am aware that the looping way scales way more poorly than the streaming alternative but this shall be a basis to get later into the more complex Constraint Stream Score Calculation having a working solution on hand for comparison.

Thanks in advance!

Answer 1

The easy and entirely unhelpful answer is that you can not use for-style loops in constraint streams.

The Constraint Streams API is designed to give you incremental performance, and therefore you need to think of your constraints in a certain way. This way is not always easy to learn, and it requires practice. That said, we have not yet seen a constraint which we could not implement incrementally.

For example, groupBy is a very powerful construct which allows you to transform your data in pretty much any way you want. If you implement a custom constraint collector, you can solve even very complex problems incrementally.

However, some users simply use groupBy() together with the toList() constraint collector, gather all their data in a single collection, and then penalize on that. I will not give an example of that, as it is an anti-pattern which leads to poor performance, and we generally discourage it.