我注意到对于 Cloudbalancing 等问题，存在移动工厂来生成移动和交换。“移动移动”将云进程从一台计算机转移到另一台计算机。“交换移动”从它们各自的计算机交换任何两个进程。
我正在开发一个时间表应用程序。
- A
subjectTeacherHour（学科和教师的组合） 只有 s 的一个子集，Period可以分配给它们。如果 Jane 在一堂课上教了 6 个小时，则必须从该课程的可能 30 s 中为subjectTeacherHour每个课分配6 个 s ；不像 cloudbalance 示例，其中一个进程可以移动到任何计算机。PeriodPeriod - 只有一个
subjectTeacherHour可能被分配Period（自然）。
它试图放置subjectTeacherHour到符合条件的位置Periods，直到找到最佳组合。
优点
手册似乎推荐它。
...但是，正如巡回锦标赛的例子所证明的那样，如果您可以通过使用一组特定的大动作来消除硬约束，您就可以赢得性能和可扩展性...
... `[大动作的版本] 评估了很多不可行的解决方案，这使其能够超越和超越简单版本....
...通常使用多个选择器，混合细粒度移动和粗粒度移动是一个好主意：...
虽然只能subjectTeacher将一个分配给Period，但求解器必须暂时打破这种约束，以发现交换两个特定Period分配会导致更好的解决方案。这两个州之间的交换举动“消除了这堵砖墙”。
因此，交换行动可以帮助更快地产生更好的解决方案。
缺点
AsubjectTeacher只有s 的一个子集，Period它们可以被分配到。因此，在任何两个subjectTeachers之间找到相交（公共）小时有点困难（但可以以一种优雅的方式实现：从对象属性中找到重叠值的良好算法/技术？）。
它只会在时间和最优性方面给我带来很小的收益吗？
我还担心可能会导致两种动作的疯狂交互，导致陷入糟糕的解决方案。