为什么 Big-O 表示法中的加法常数不重要？答案

【问题标题】：Why doesn't the additive constant in Big-O notation matter?为什么 Big-O 表示法中的加法常数不重要？
【发布时间】：2017-07-07 20:05:10
【问题描述】：

在 Big-O 符号的定义中，我们只关心 C 系数：

f(n) ≤ Cg(n) for all n ≥ k

为什么我们也不关心A：

f(n) ≤ Cg(n) + A for all n ≥ k

【问题讨论】：

加法常数与乘法常数相比往往会产生微小的差异。
+ 如果独立于 n @cᴏʟᴅsᴘᴇᴇᴅ
因为 Big-O 表示法的主要目的是对算法的扩展方式进行分类。示例：如果我要查找列表的长度，当列表有 10 个对象时，需要 11 次操作。当列表有 100 个对象时，需要 101 次操作。在这里，当我们试图询问“这个算法的扩展性如何？”时，恒定的操作数并不重要
@cᴏʟᴅsᴘᴇᴇᴅ 但是如果这个常数很大怎么办：10^9
@rset_d 如果常数很大，那对于“这个算法将如何扩展？”的问题仍然无关紧要

标签： algorithm math time-complexity big-o

【解决方案1】：

这里有两种情况需要考虑。对于初学者，假设您的函数 g(n) 具有对于所有“足够大”的 n 选择 g(n) ≥ 1 的属性。在那种情况下，如果你知道的话

f(n) ≥ cg(n) + A,

那你也知道了

f(n) ≥ cg(n) + Ag(n),

所以

f(n) ≥ (c + A)g(n)。

换句话说，如果你的函数 g 总是至少为 1，那么用 cg(n) + A 形式来限制 f(n) 相当于用 c'g(n) 形式来限制它对于一些新的常数 c'。从这个意义上说，在大 O 表示法的定义中增加一些额外的灵活性，至少在这种情况下，不会有什么不同。

在算法分析的上下文中，几乎每个你可能绑定的函数 g(n) 都至少是一个，因此我们可以通过选择 g 的更大倍数来“咀嚼”这个额外的加法项.

但是，在许多情况下，大 O 表示法也用于绑定随着 n 增加而减少的函数。例如，我们可以说某个算法给出正确答案的概率是 O(1 / n)，其中函数 1/n 作为 n 的函数下降到 0。在这种情况下，我们使用大 O 表示法来讨论函数下降的速度多快。例如，如果成功概率为 O(1 / n²)，那么假设 n 变得足够大，这比之前的 O(1 / n) 成功概率更能保证。在这种情况下，在大 O 符号的定义中允许添加项实际上会破坏事情。例如，直观地，函数 1 / n² 比函数 1 / n 更快地下降到 0，使用 big-O 表示法的正式定义你可以看到这是因为 1 / n² ≤ 1 / n 对于所有 n ≥ 1。但是，根据您对 big-O 表示法的修改定义，我们也可以说 1 / n = O(1 / n²) , 因为

1 / n ≤ 1 / n² + 1 对于所有 n ≥ 1，

这只是因为加法 1 项限制了 1/n 项，而不是我们最初可能感兴趣的 1/n²。

因此，您的问题的长答案是“如果我们仅将自己限制在 g(n) 不作为n，并且在 g(n) 确实将零作为 n 的函数的情况下，您的新定义并不是特别有用。”

【讨论】：

【解决方案2】：

Big-O 表示法是关于随着数据变大而发生的情况。换句话说，它是一个 n --> 无穷大的极限。

随着 n 变大，A 保持不变。所以相比之下它变得越来越小。另一方面，g(n)（大概）越来越大，所以它的贡献也越来越大。

【讨论】：

这是正确的，前提是 g(n) 作为 n 的函数增长而不是衰减，但如果 g(n) 衰减到 0，则此逻辑不一定正确。
@templatetypedef 。 . .有趣的。当我写这篇文章时，我在想“如果有人认为g(n) 没有增加怎么办”。实际上，对于顺序表示法，g(n) 确实增加。这将是一个非常不寻常的算法，随着数据变大而变得更快（在绝对意义上）。本说明适用于初学者。
在实践中，当 g(n) 是算法的运行时间时，g(n) 会增加。 Big-O 的使用比算法分析更广泛，并且 g(n) 可能不会增加。

【解决方案3】：

A 在这种情况下是常量，因此当问题的规模非常大时，它不会对复杂性产生太大影响。

当您的成本为 100 万时，您不在乎是否将常数因子 100 相加。你关心这 100 万个如何增长（来自Cg(n)）；例如，如果问题的规模扩大一点，它是否会变成 200 万。但是，您的常数仍将是 100，因此它不会真正影响整体复杂性。

【讨论】：