在 OptaPlanner 中处理未初始化的解决方案
Dealing with uninitialized solutions in OptaPlanner
我正在为一所学校创建一个时间表生成器，我面临两个挑战：
1：施工阶段的用户反馈
在构造启发式阶段，我没有收到任何传递给 SolverManager.solveAndListen 的 bestSolutionConsumer 的回调，这意味着在此期间我无法向用户提供任何反馈阶段。 （今天只有10秒左右，但还是很烦人。）
我怀疑这是设计使然（从判断），但如果我错了请纠正我。
（我怀疑这个想法是构建启发式阶段无论如何都应该很快，并且 99% 的长 运行 解决将花费在本地搜索阶段，因此这是唯一的阶段这实际上很重要。对吗？）
2：手动放置讲座
这个调度程序将只是半自动的。我希望用户能够固定讲座、手动移动讲座，甚至通过将它们堆放在一边以供以后放置（以后的放置可能由 OptaPlanner 完成），从而从日程表中删除讲座。
重新考虑初始化的定义？
这让我重新思考我认为的初始化解决方案。如果我...
- 即使在最初安排讲座期间也希望获得进度反馈，并且
- 希望允许用户与仅安排了一半讲座的日程表进行交互
...那么也许我应该让时间段可以为空，或者为未安排的讲座设置一个标记时间段值，并简单地惩罚此类解决方案。
在这种情况下，我想象一个解决方案被立即简单地初始化（所有讲座最初都处于未安排状态，但正式来说解决方案仍然被初始化）并且构建阶段基本上被跳过。
问题
这是愚蠢的原因吗？！感觉我丢掉了 OptaPlanner 的很大一部分功能。
我是否忽略了这种方法的任何缺点？
这样做甚至可以跳过构建阶段吗？
另外，反复规划对我来说很重要，docs say:
Repeated planning (especially real-time planning) does not mix well with a nullable planning variable.
这是否也适用于使用 unscheduled 标记值的方法？
1/ 不，这不傻。事实上，它是 over-constrained planning.
的一个例子
2/ 那么，现在变量可以为空，您需要编写约束以接受空值。你可能 运行 遇到求解器会发现将某些变量保留为空更容易的情况，除非对此有相当大的惩罚。您可能必须设计特殊的约束来解决这个问题，或者在最坏的情况下甚至需要自定义移动。
3/ 构造启发法不是强制性的，但它们仍然有用。即使他们将一些变量留空，他们仍然可以为您提供一个不错的初始解决方案。您可能还想尝试 custom phase.
4/ 如果您担心上面的一些事情，确实引入一个虚拟值而不是使变量可为 null 可以解决其中的一些问题。 （并介绍其他人，因为现在每个约束都必须处理这个虚拟值。）
我的建议是快速验证概念。查看每种方法的行为方式。选择一个你喜欢处理的。没有银弹。
我正在为一所学校创建一个时间表生成器，我面临两个挑战：
1：施工阶段的用户反馈
在构造启发式阶段，我没有收到任何传递给 SolverManager.solveAndListen 的 bestSolutionConsumer 的回调，这意味着在此期间我无法向用户提供任何反馈阶段。 （今天只有10秒左右，但还是很烦人。）
我怀疑这是设计使然（从
（我怀疑这个想法是构建启发式阶段无论如何都应该很快，并且 99% 的长 运行 解决将花费在本地搜索阶段，因此这是唯一的阶段这实际上很重要。对吗？）
2：手动放置讲座
这个调度程序将只是半自动的。我希望用户能够固定讲座、手动移动讲座，甚至通过将它们堆放在一边以供以后放置（以后的放置可能由 OptaPlanner 完成），从而从日程表中删除讲座。
重新考虑初始化的定义？
这让我重新思考我认为的初始化解决方案。如果我...
- 即使在最初安排讲座期间也希望获得进度反馈，并且
- 希望允许用户与仅安排了一半讲座的日程表进行交互
...那么也许我应该让时间段可以为空，或者为未安排的讲座设置一个标记时间段值，并简单地惩罚此类解决方案。
在这种情况下，我想象一个解决方案被立即简单地初始化（所有讲座最初都处于未安排状态，但正式来说解决方案仍然被初始化）并且构建阶段基本上被跳过。
问题
这是愚蠢的原因吗？！感觉我丢掉了 OptaPlanner 的很大一部分功能。
我是否忽略了这种方法的任何缺点？
这样做甚至可以跳过构建阶段吗？
另外，反复规划对我来说很重要，docs say:
Repeated planning (especially real-time planning) does not mix well with a nullable planning variable.
这是否也适用于使用
unscheduled标记值的方法？
1/ 不，这不傻。事实上，它是 over-constrained planning.
的一个例子2/ 那么，现在变量可以为空，您需要编写约束以接受空值。你可能 运行 遇到求解器会发现将某些变量保留为空更容易的情况，除非对此有相当大的惩罚。您可能必须设计特殊的约束来解决这个问题，或者在最坏的情况下甚至需要自定义移动。
3/ 构造启发法不是强制性的，但它们仍然有用。即使他们将一些变量留空，他们仍然可以为您提供一个不错的初始解决方案。您可能还想尝试 custom phase.
4/ 如果您担心上面的一些事情，确实引入一个虚拟值而不是使变量可为 null 可以解决其中的一些问题。 （并介绍其他人，因为现在每个约束都必须处理这个虚拟值。）
我的建议是快速验证概念。查看每种方法的行为方式。选择一个你喜欢处理的。没有银弹。