根据不同选择的结果约束 optaplanner 的选择 - Constraint Propagation / Local Consistency

Question

我有一个正在处理的优化问题，其中优化器对一个变量的决定需要限制另一个变量的可用选择，我想知道实现这一点的不同方法的适用性。 为了演示目的，我将尝试减少它（在 kotlin 中）。

@PlanningEntity
class AuctionBid {
  @PlanningId
  lateinit var entity: String
  
  @PlanningVariable(valueRangeProviderRefs = ["availOptions"])
  var bidNow: Boolean? = null
  @PlanningVariable(valueRangeProviderRefs = ["availOptions"])
  var bidFinal: Boolean? = null
  var forceBid: Boolean? = null

  @ValueRangeProvider(id = "availOptions")
  private fun availOptions(): List<Boolean> {
    return if(this.forceBid != null) {
      listOf(this.forceBid!!)
    } else {
      listOf(true,false)
    }
  }
}

在这种情况下，考虑到硬预算和各种成本/收益权衡，我们试图确定是否应该在组合拍卖中对给定实体进行竞标（每轮中有多个实体被竞标）。 bidNow选择由本轮拍卖中的价格决定， bidFinal选择由拍卖中预期/预测的最终价格决定。 为了避免不断改变关于现在出价什么的决定（在拍卖规则中改变出价会受到惩罚），我们希望根据我们对bidFinal的决定来限制我们对bidNow的选择，这样如果我们想要出价它以我们预期的未来价格，我们将始终选择现在出价。 如下所示的状态表：

现在出价	最终投标	可能的
是	是	是
是	ñ	是
ñ	ñ	是
ñ	是	ñ

正如所见，我们已经有一种方法可以在我们知道我们根本不想要该产品或我们知道我们不惜任何代价想要它的情况下限制选择。 这是使用availOptions ValueRangeProvider，如果我们知道这是我们唯一的选择，它只会让优化器选择一个预定的选项。

但是，此约束更具动态性，因为它来自单独的选择。 如果我们想以预期的最终价格竞标，我们目前唯一的选择就是在本轮继续竞标。

我已经想到了几种方法，因为这是一个经典的局部一致性约束传播示例，但是由于对 optaplanner 的内部结构了解不多，我真的不知道最好的方法。 一些选项：

1. 对 bidNow 使用单独的bidNow而不是bidFinal ，如果bidNow为True ，则将bidFinal的值范围限制为 True。 但是，我不知道 optaplanner 是否甚至可以处理由另一个计划变量的值确定的动态值范围，也不知道这是否是一种有效的方法。
2. 如果bidFinal为True ，则在bidNow上放置一个硬约束（使用 ConstraintStreams，这是非常酷的 BTW）始终为True 。 我知道这是可行的（这是我目前的解决方案），但它似乎真的很慢。
3. 也许尝试使用我以前从未使用过的 Shadow 变量，尽管我不确定这是否合适，因为bidFinal==True暗示bidNow==True ，但bidFinal=False不一定暗示任何有关bidNow的内容。

我知道我总是可以尝试所有不同的选项然后看看，但是这个问题已经很大而且很笨拙（演示代码被大大简化了），我真的很想了解 Optaplanner 如何在幕后工作，因为我真的很喜欢使用它，但总是遇到这些这样或那样的场景，很难全部尝试。 对这个约束传播问题的建模有什么见解吗？ 或者这样的问题？

Answer 1

1和2都应该可以； 2是直截了当的方式。

如果bidNow为false （以及相反的极端情况），另一种选择是使用过滤的移动选择来跳过将bidFinal设置为Y的移动。 这样做的缺点是过滤器需要应用于您使用的每一个动作，这使得求解器配置变得冗长。 而且这些招式仍然会在被丢弃之前生成，因此您会损失一些性能。

但是，为什么不使用以下三个选项对枚举进行bid ： NOTHING 、 NOW_ONLY 、 BOTH 。 这样一来，您就可以获得只有一个计划变量并完全消除原始问题的好处。 当然，这仅适用于选项数量很少的情况，在您的实际用例中可能不是这样。

最后一个选项是以一种避免极端情况的方式设计数据模型的示例。 如果它们是不可能的，因为模型排除了它们，您不必担心以后要解决它们。 这始终是您最好的选择。