【问题标题】:Knapsack algorithm, large capacity背包算法,大容量
【发布时间】:2014-04-16 16:00:58
【问题描述】:

我目前正在开发播放列表播放器,但遇到了问题。我的播放列表中有可变长度的空白,我想用特殊的音频文件填充。这些文件也有可变长度,通常比我在播放列表中的间隔短。

这听起来像是一个经典的背包问题,所以我尝试实现这个算法。这适用于较小的间隙,但是每当我有 30 分钟的间隙时,该算法都会使用大量内存。这是意料之中的,因为我使用dynamic programming 来解决问题。

背包的容量为{gap in milliseconds},背包物品的重量以毫秒为单位。

这是非常低效的。所以我想知道是否可以使用不同的算法,或者将重量和容量更改为更小的变量。到目前为止,我正在考虑将所有内容除以任意数字,但如果我这样做会失去精度。

有人有什么想法吗?

编辑:

我有大约 500 个填充物来填补空白。并且改变音高是不可能的。 这组填充物应该有一个完美的解决方案。 我真的想要毫秒精度,但我可以忍受不到 100 毫秒的时间。

【问题讨论】:

  • 您需要毫秒精度吗?如果是这样,为什么?你控制间隙的长度吗?一点点上下文有很长的路要走。
  • 差距是否必须得到最佳填补?也许你应该在新的差距低于某个阈值时停止。
  • 这听起来很奇怪。 30 分钟的间隔从何而来?为什么一定要完美贴合?音频文件可以轻松地拉伸几个百分点而没有任何明显差异,也许这有帮助?
  • 我已经用更多的上下文编辑了起源问题
  • 是可能的预计算值还是动态的?

标签: java algorithm out-of-memory knapsack-problem


【解决方案1】:

你说的是播放列表,所以我假设你有歌曲,一首典型的歌曲大约是 3 分钟,所以你的解决方案是大约 10 首歌曲。因此,您可以将所有时间除以 50,然后一首歌曲的典型误差为正负 25 毫秒,因此对于 10 首随机歌曲,误差通常约为 (25 毫秒 * sqrt(10))

【讨论】:

  • 这就是我现在使用的,似乎我无法进一步改进算法。我会尝试一些不同的数字,看看哪种效果最好!
【解决方案2】:

您可以使用迭代加深近似法,用所有适合的最长填充物来填补空白。然后你删除它们(从短到长),在每个之后用动态算法解决剩余空间。由于每次移除都会增加剩余间隙的长度,因此每个问题都会变得更难。一旦时间或内存用完就停止,并使用最后生成的解决方案。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-12-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-06-22
    相关资源
    最近更新 更多