Algorithm 摊销真的值得吗？

例如，假设我有一个O（n）算法和一个摊销O（n）算法。公平地说，严格来说，非摊销算法总是和摊销算法一样快或更快？或者有没有任何理由更喜欢分期付款的版本（忽略代码的简单性或易实现性）

还是有任何理由选择摊销版本

---

较小的常数。

大O表示法告诉您算法如何随着输入的增加而变化。 它不是分析代码的快捷方式

对于程序中的所有n，更好的算法可能是O（n^2），因为O（n）中有一个更大的常数

因此，您对算法的选择实际上取决于哪个算法对于您的输入大小更快。我想你的问题的答案是在你的程序中分析这两种算法，然后决定哪一种更快

大O符号只告诉您代码的伸缩程度，而不是有限N的伸缩速度

如果您关心最坏情况下的性能或延迟（如实时或交互式系统），摊销和非摊销之间的差异很重要。但是，如果您只关心平均吞吐量，那么它们在所有实际用途上都是相同的。即使在科学计算和大规模数据挖掘等性能非常关键的情况下，摊销分析也足够好

---

需要摊销算法的一个经典例子是std:：vector，插入为摊销O（1）

使用摊销算法的一些原因：

• 在一般情况下效率更高
• 更容易实现
• 不存在最坏情况保证算法

---

O（n）算法和摊销O（n）算法之间的主要区别在于，您对摊销O（n）算法的最坏情况一无所知。在实践中，这并不重要：如果你的算法运行了很多次，那么你可以依靠平均法则来平衡一些不好的情况，如果你的算法没有运行很多次，那么你根本不可能遇到最坏的情况

只有在某些情况下，“摊销”一词才有意义，因为你不能接受由于某种原因偶尔出现的不良表现。例如，在GUI应用程序中，您可以很高兴地放弃一些平均的案例性能，以换取一个保证，即当用户坐在那里感到无聊时，您永远不会陷入困境并停止响应。在这样的应用程序中，您希望确保即使是最坏情况下的行为也适用于任何可能导致GUI停止响应的代码

---

不过，大多数情况下，你不需要担心摊销O（n）与摊销O（n）的对比，你可以担心常数因子是什么（正如其他人已经说过的）。

严格地说，big-O的测量不够精确，因此可以说，有O（n）的算法比有摊销O（n）的算法更快。想想看。如果在复杂度分析中降低了保真度级别，常数因子可能会显著不同，并使摊销版本更快

此外，摊销的影响往往取决于用途。例如，如果您使用的是哈希表，摊销的影响在很大程度上取决于get to add操作的比率。因此，如果你添加1000个条目，然后进行10亿次查找，那么你必须重新刷新几次的事实并没有多大区别。但是，如果你不断地添加条目，重新灰化的成本可能会增加

---

这就是摊销不同于最坏情况的原因。Big-O反映了最坏的情况，而摊销让你说“每X中有一个将命中，X足够大，这并不重要。”此外，如果你考虑像插入到哈希表中的例子，X根据某些常量增长。因此，如果你有一个哈希表，它从100个桶开始，每一次再灰烬加倍，那么再灰烬会逐渐变得越来越远。此外，具有摊销复杂度的算法的绝对最坏情况复杂度取决于以前的调用，而在像平均情况这样的度量中，调用被认为是独立的。

我完全了解大o。我只是想知道，从理论的角度来看，是否有任何不同。那么，这是否意味着从严格的大o的角度来看，没有任何不同？是的，有不同。“从严格的大O”观点来看，在所有情况下都要考虑最坏情况的运行时间。从大O观点来看，n＝10000000×N。因此，是的，这没有什么区别。从行为的角度来看，他们是不同的。O（n）算法保证任何输入实例的O（n）。摊销不提供此类担保。O（n）保证通常是在一个输入序列/输入集（如std:：vector）上求平均值。我不同意你的数字1。大O只会告诉你最坏的情况是怎样的。你所描述的实际上是一个上下界，而不仅仅是一个上界。@sanjacinto，big-Oh符号仅仅表示它是一个渐近上界。大Oh可用于给出“最坏情况”和“平均情况”的上限（它甚至可用于“最佳情况”，尽管通常不太有用）@michael我对big O有着完美的理解。我不是不同意数学定义，而是不同意dsimcha的定义。根据定义，你知道摊销算法的最坏情况。你就是这样摊销的！是的，假设您是执行分析并计算摊余成本的人。但是，如果有人只是告诉您“此操作是摊销的（uu）”，而没有提供其他信息，那么您就不知道最坏情况下的成本是多少。@San Jacinto，这取决于您如何定义“最坏情况”。是吗