我有以下情况（对长度的初步道歉，但我希望尽可能具有描述性）：
我收到了一份“食谱”（Ri）列表，必须按照提供的顺序完成，以完成给定的任务。每个配方都包含完成它所需的部件列表（Pj）。配方通常需要最多3或4个零件，但可能需要多达16个。示例配方列表可能如下所示：
最长的列表可能包含几百个食谱，但通常包含一些食谱的重复次数，因此删除相同的食谱通常会将列表减少到少于50个独特的食谱。
我有一组机器（Mk），每个机器都已预先编程（这在列表处理开始之前发生一次），以生成一些（或所有）可用类型的部件。
履行过程的迭代发生如下：
机器可以即时，并行运行，并且具有无限的原材料，因此没有资源或时间/调度限制。机器组的尺寸k必须至少等于最长配方中的元件数量，因此具有与上述配方长度大致相同的范围（通常为3-4，可能高达16）。因此，在上面的例子中，k = 3（由R3和R5的大小决定）似乎是一个合理的选择。
手头的问题是如何对机器进行预编程，以便银行能够完成给定列表中的所有配方。机器库共享一个公共内存池，因此我正在寻找一种算法，该算法产生的编程配置可以消除（完全或尽可能多）机器之间的冗余，从而最大限度地减少总内存负载量。机器组大小k是灵活的，即，如果增加超出给定列表中最长配方长度的机器数量，则为列表产生更优化的解决方案（但保持16的硬限制），这很好。
目前，我认为这是一个非常明显的问题，即每个程序需要相同数量的内存，尽管我希望将来可以灵活地添加每个程序的权重。在上面的例子中，考虑到所有配方，P1最多出现一次，P2出现最多两次（在R5中），P3出现最多两次（在R7中），而P4最多出现一次，所以我理想地希望实现一个与此匹配的配置 - 只有一台机器配置为生成P1，两台机器配置为生成P2，两台机器配置为生成P3，一台机器配置为生成P4。使用机器组大小k = 3，上述示例的一个可能的最小配置是：
由于这里没有作业商店类型的限制，我的直觉告诉我，这应该减少到集合覆盖问题 - 就像在设计数字系统时发现的最小的unate set-cover问题。但我似乎无法使我对这些算法的知识（通常是有限的）适应这种情况。有人可以确认或否认这种方法的可行性，在任何一种情况下，都指向一些有用的算法？我正在寻找可以集成到现有代码块中的东西，而不是像Berkeley的Espresso那样预先包装的东西。
谢谢！
答案 0 :(得分：2)
这让我想起了编译器中register allocation使用的图着色问题。
步骤1：如果在配方中重复相同的部分，则重命名;例如，R5 = {P1，P2，P2'}
步骤2：将所有零件插入图表中，并在同一配方中的零件之间插入边缘
步骤3：为图形着色，使得没有两个连接的节点（部分）具有相同的颜色
颜色是制作零件的机器标识。
这是次优的，因为重命名的部分会在其他配方中创建错误约束。您可以通过“合并”来解决这个问题。请参阅Briggs。