【问题标题】:0/1 knapsack with dependent item weight?0/1 背包,取决于物品重量?
【发布时间】:2016-12-16 12:44:13
【问题描述】:

标准的 0/1 背包要求每件物品的重量独立于其他物品。那么 DP 是一种有效的求解算法。但是现在我遇到了一个类似但扩展了这个问题,即

新项目的重量取决于之前已经存在的项目 背包。

例如,我们有5个项目abcde,重量为w_a、...、w_e。项目bc 具有权重依赖性。

b 已经在背包中时,物品c 的重量将小于w_c,因为它可以与b 共享一些空间,即weight(b&c) < w_b + w_c。对称地,当c已经在背包中时,b的权重会小于w_b

这种不确定性导致原始 DP 算法失败,因为它依赖于以前迭代的正确性,而现在可能不正确。我已经阅读了一些关于背包的论文,但它们要么具有受利润二次背包问题)的依赖性,要么具有遵循随机分布的可变权重(随机背包问题)。我也知道上一个问题1/0 Knapsack Variation with Weighted Edges,但是只有一个非常笼统的答案,没有关于这个背包的名字的答案。

一个现有的解决方案:

我还在a paper 中阅读了一个关于 DBMS 优化的近似解决方案,他们在其中group the related items as one combined item for knapsack。如果在我们的示例中使用这种技术,背包的项目将是abcde,因此这四个项目中的任何两个项目之间没有更多的依赖关系。然而,很容易构造一个没有得到最佳结果的例子,比如an item with "small weight and benefit" is grouped with another item with "large weight and benefit"。在这个例子中,“小”项不应该在解决方案中被选中,而是与“大”项一起被选中。

问题:

是否有任何一种有效的解决技术可以获得最佳结果,或者至少有一些错误保证?还是我在建模这个问题时采取了错误的方向?

【问题讨论】:

  • 您的问题似乎遭到了反对。我不太同意反对者的观点,但这可能是因为您询问是否对此问题进行了任何研究,这可能被解释为要求“场外资源”,而这与主题无关。
  • @samgak 感谢您的评论。我已经修改了我的问题,以便更加关注任何可能的解决方案。
  • 这个问题是being discussed on Meta
  • 您可以尝试背包的标准 B&B 方法,在计算上限和下限时,您只需根据背包上已经存在的物品更新物品的重量(不应该那么复杂)。
  • @PaddyXu 写下你自己的答案并解释上限/下限计算并将其标记为已接受,这将是一个更好的答案,我只是说“尝试定制的 B&B。” i> ;)

标签: algorithm knapsack-problem


【解决方案1】:

最后我设法用@Holt提出的B&B方法解决了这个问题。以下是关键设置:

(0) 在运行 B&B 算法之前,根据它们的依赖关系对所有项目进行分组。一个分区中的所有项目与同一组中的所有其他项目具有权重依赖性,但与其他组中的项目无关。

民宿设置:

(1) 上限:假设当前项具有最小权重,即假设所有依赖项都存在。

(2) 下界:假设当前项具有最大权重,即假设所有依赖项都不存在。

(3) 当前重量:计算实际当前重量。

上述所有计算都可以通过我们在步骤 0 中得到的组在线性时间内完成。具体来说,在获得这些权重时,仅扫描当前组中的项目(当前项目所在的组)是足够 - 其他组中的项与当前项没有依赖关系,因此不会改变当前项的实际权重。

【讨论】:

    【解决方案2】:

    这是一个非常有趣的问题,我已经研究了一段时间。首先要考虑的是,具有依赖项重量/值的二进制背包问题根本不是微不足道的。您可以考虑使用贝叶斯网络、马尔可夫模型和其他类似技术来解决这个问题。尽管如此,任何解决这个问题的实际方法都必须对优化模型或其输入做出一些假设。这是一个用价值依赖项来制定二元背包问题的例子。 https://arxiv.org/pdf/1702.06662.pdf

    在这项工作中,作者提出使用模糊图对输入(与值相关的依赖项)进行建模,然后使用提出的整数线性规划模型来解决优化问题。该作品的扩展版本已被接受出版,并将很快在网上提供。

    如果您需要更多信息,请随时与我联系。如果需要,我还可以为您提供模型的源代码。

    【讨论】:

      【解决方案3】:

      您不能拥有abcbcde 的项目吗?可能有一个约束,bbc 不能同时在背包中,cbc 也是如此?我的理解是,这将是一个正确的解决方案,因为任何具有bc 的解决方案都可以通过用bc 代替(根据定义)来改进。对成员资格的限制应考虑到任何其他情况。

      【讨论】:

      • 如果所有项目之间存在依赖关系,一旦项目数量开始增长,这将非常低效且难以处理。在具有 a、b、c、d、e 的示例中,您将必须创建 ab、ac、ad、ae、bc、bd、be、cd、ce、de,但还要创建 abc(因为,如果您将 a , b 和 c 在背包里?)以及所有三胞胎和四胞胎,以及...基本上,您将为所有解决方案创建一个项目。
      • @Holt 也许可以,但其中许多很容易被控制,因此您可以相对便宜地将它们从最初的考虑中删除。
      • 感谢您的回答。然而,当算法(任何算法,例如 DP)同时选择 bbc 时,这个想法可能无法正常工作。在这种情况下,因为选择bc等于选择b,并且b的权重会变为0,所以依赖关系仍然存在。
      猜你喜欢
      • 1970-01-01
      • 2011-06-23
      • 1970-01-01
      • 2018-02-10
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多