CloudBalancing 中的其他 PlanningEntity - bounded-space 情况
Additional PlanningEntity in CloudBalancing - bounded-space situation
我成功地修改了漂亮的 CloudBalancing 示例，以包括这样一个事实，即在任何给定时间我可能只打开有限数量的计算机（感谢 optaplanner 团队 - 很容易做到）。我相信这被称为 bounded-space 问题。效果不错。
进程按组进行，比如每组按给定顺序有 20 个进程。我想修改示例，让 optaplanner 也更改这些组的顺序（而不是一组中的进程）。因此，我在域中添加了一个 class ProcessGroup 和一个成员 List<Process>，ProcessGroup 的实例存储在 List<ProcessGroup> 中。所需的优化将混洗此列表的成员，导致 ProcessGroup 的实例被放置在列表 List<ProcessGroup> 的不同索引处。 ProcessGroup 的索引应该是 ProcessGroup.index。
文档指出 "if in doubt, the planning entity is the many side of the many-to-one relationsship." 这意味着 ProcessGroup 是计划实体，成员 index 是计划变量，被分配给（希望如此）不同的整数。在每次新的索引分配之后，我将不得不按 ProcessGroup.index 的升序对列表 List<ProcessGroup 求助。这看起来非常奇怪和麻烦。有更好的想法吗？
提前致谢！
菲利普
当前的设计有一些缺点：
- 它需要 2 个（真正的）实体 类（每个都有 1 个规划变量）：可能会增加搜索量 space（= 解决时间更长，更难找到好的甚至可行的解决方案） + 它增加了配置的复杂性。能合理避免的情况下，不要使用多个正版实体类。
- GroupProcess 的 Integer 变量需要完全不同并且以某种方式顺序排列。这听起来像是一个链式规划变量（请参阅有关链式变量和车辆路径示例的文档），在这种情况下，整个问题可以表示为一个只有 1 个变量的简单 VRP，但这真的适用于这里吗？
思路：这个模型有问题：
- ProcessGroup 有 Integer 变量：那个 Integer 代表什么？那个 Integer 变量不应该在 Process 上吗？您订购的是流程还是流程组？如果它应该在 Process 上，那么 Process 的两个变量都可以替换为链式变量（如 VRP），这样效率会高得多。
- ProcessGroup 有一个进程列表，但这是一个问题属性：这意味着它在计划期间不会更改。我怀疑这对您的用例来说是正确的，但请务必断言。
如果 none 以上推理适用（这会让我感到惊讶），那么原始模型可能是有效的 none，否则 :)
我成功地修改了漂亮的 CloudBalancing 示例，以包括这样一个事实，即在任何给定时间我可能只打开有限数量的计算机（感谢 optaplanner 团队 - 很容易做到）。我相信这被称为 bounded-space 问题。效果不错。
进程按组进行，比如每组按给定顺序有 20 个进程。我想修改示例，让 optaplanner 也更改这些组的顺序（而不是一组中的进程）。因此，我在域中添加了一个 class ProcessGroup 和一个成员 List<Process>，ProcessGroup 的实例存储在 List<ProcessGroup> 中。所需的优化将混洗此列表的成员，导致 ProcessGroup 的实例被放置在列表 List<ProcessGroup> 的不同索引处。 ProcessGroup 的索引应该是 ProcessGroup.index。
文档指出 "if in doubt, the planning entity is the many side of the many-to-one relationsship." 这意味着 ProcessGroup 是计划实体，成员 index 是计划变量，被分配给（希望如此）不同的整数。在每次新的索引分配之后，我将不得不按 ProcessGroup.index 的升序对列表 List<ProcessGroup 求助。这看起来非常奇怪和麻烦。有更好的想法吗？
提前致谢！
菲利普
当前的设计有一些缺点：
- 它需要 2 个（真正的）实体 类（每个都有 1 个规划变量）：可能会增加搜索量 space（= 解决时间更长，更难找到好的甚至可行的解决方案） + 它增加了配置的复杂性。能合理避免的情况下，不要使用多个正版实体类。
- GroupProcess 的 Integer 变量需要完全不同并且以某种方式顺序排列。这听起来像是一个链式规划变量（请参阅有关链式变量和车辆路径示例的文档），在这种情况下，整个问题可以表示为一个只有 1 个变量的简单 VRP，但这真的适用于这里吗？
思路：这个模型有问题：
- ProcessGroup 有 Integer 变量：那个 Integer 代表什么？那个 Integer 变量不应该在 Process 上吗？您订购的是流程还是流程组？如果它应该在 Process 上，那么 Process 的两个变量都可以替换为链式变量（如 VRP），这样效率会高得多。
- ProcessGroup 有一个进程列表，但这是一个问题属性：这意味着它在计划期间不会更改。我怀疑这对您的用例来说是正确的，但请务必断言。
如果 none 以上推理适用（这会让我感到惊讶），那么原始模型可能是有效的 none，否则 :)