对数组求和的大 O 估计答案

【问题标题】：Big O estimate for summing up an array对数组求和的大 O 估计
【发布时间】：2024-11-21 15:45:02
【问题描述】：

如果我有一个包含 100 万个整数的数组。总结起来被认为是 O(n) 因为我必须执行 n-1 加操作。对吗？

【问题讨论】：

这类问题可能更适合cstheory.stackexchange.com
@joshi：我不知道。我认为这是一个完美的 SO 问题，并且 stackexchange 过于分散......

【解决方案1】：

如果您可以在 O(1) 中添加两个元素，那么将 n 个元素相加需要 O(n)，是的。如果他们可能需要更长的时间，那么不会。例如，如果所有元素都是无符号的 32 位整数，但您想要精确的总和（不是 sum mod 2³²），那么它可能与 n · (2³² - 1) 在这种情况下求和将花费 O(n log n)。

【讨论】：

【解决方案2】：

是的。完全正确。

当然，在特殊情况下可能会更少。并且某些方法可以使其更小，但这些方法的开销比加法更大。

例如，如果您知道值是从 1 到 n，那就是 O(1)，因为您可以计算 n*(n+1)/2。但一般情况是 O(n)。

【讨论】：

计算 n*(n-1)/2 需要 O(log n)，而不是 O(1)。
你怎么看？这是一些乘法除法和减法。无论 n 多少，如果没有溢出，都将花费相同的时间。
O(1)，如果 n 为 1，计算 n*(n+1)/2 所需的时间与 n 等于 100 万时相同。因此它不依赖于 N: O(1) time [constant]
不，这是完全错误的。如果他有一个包含 1000000 个条目的数组，那么加起来就是 O(1)。只有当他有一个包含 n 个条目的数组时，它的总和是 O(n)。（澄清 - 你对问题的回答，而不是关于 n*(n-1)/2 的辩论）
我的假设是 1000000 是一个例子，鉴于他声明了 n-1 个添加，他正在寻找 n 个元素的一般情况。

【解决方案3】：

是的，因为用于求和的时间直接取决于元素数量n。

【讨论】：