【问题标题】:Time Complexity of Finding All Possible Sums查找所有可能和的时间复杂度
【发布时间】:2018-01-09 22:51:33
【问题描述】:

这是一个算法的解决方案,它希望我在给定一组硬币及其相应数量的情况下找到所有可能的总和。我很难得出这个算法的时间复杂度。任何帮助将不胜感激,谢谢!

const coins = [1, 2, 3];
const quantity = [1, 2, 2];

const possibleSums = (coins, quantity) => {
  const uniqueSums = new Set([0]);

  for (let i = 0; i < coins.length; i++) {
    const currentSums = new Set();
    for (let j = 1; j <= quantity[i]; j++) {
      for (let sum of uniqueSums) {
        currentSums.add((coins[i] * j) + sum);
      }
    }
    for (let sum of currentSums) {
      uniqueSums.add(sum);
    }
  }

  return uniqueSums.size - 1;
}

【问题讨论】:

  • 这是确定时间复杂度的“蛮力”方法。看起来每个'.add'都可以被认为是一个操作。因此,添加一个计数器变量,每次调用 '.add' 时将其递增,在函数末尾打印它,并尝试使用硬币和数量来确定模式。
  • 您希望复杂度达到多少?通常人们想要一个关于给定数组的 length 的 big-O 值,但是这个算法会根据其中一个数组中的实际 values 而有所不同。
  • 我相信它是 O(n^3) 其中 n 是硬币数组的长度。外循环和内循环是 O(n^2),然后在 for 循环的数量内还有一个循环,这使得它成为 O(n^3)。

标签: javascript algorithm time-complexity


【解决方案1】:

我相信平均复杂度是 O(n * m),其中 n 是可用硬币的总量(即所有 i 的硬币 [i] * 数量 [i] 的总和),m 是唯一总和的数量可能(即您要计算的内容)。

棘手的部分是 uniqueSums 的大小不会以可预测的方式增长,因为它取决于所使用的确切值,所以我看不到一个明显的论据来证明它实际上不是更小的东西(例如 O(n + m) 或类似的东西)

基本上,最好的情况是 O(n)(如果 uniqueSums 的大部分大小来自最后一次迭代,所以它永远不必迭代),最坏的情况是 O(n * m)(相反的情况,如果 uniqueSums 立即达到其最终大小),平均情况可能仍为 O(n * m) 但我不是 100% 确定。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2012-11-27
    • 1970-01-01
    • 1970-01-01
    • 2017-12-18
    • 2015-11-17
    • 2018-07-23
    • 2014-08-29
    • 2012-08-14
    相关资源
    最近更新 更多