在我所见的任何地方（在 SO 和其他来源上），摊销分析通常仅适用于数据结构。例如dynamic array 或splay tree。但是，我还没有看到对纯算法应用摊销分析。谈论算法的摊销分析是否有意义？摊销分析假设一系列操作适用于数据结构，但不适用于算法。
【问题讨论】：
标签： algorithm data-structures amortized-analysis
只有当存在一些可变状态允许在一个操作中完成的计算影响另一个操作中的计算性能时，摊销一系列操作的成本才有意义。如果一系列操作的性能可以独立地分析为单个操作的性能总和，其中每个操作不依赖于执行的其他操作，则不进行摊销。
所以从这个意义上说，摊销分析仅适用于数据结构，而不适用于纯算法。但是，这假设了“数据结构”的非常广泛的定义，它实际上包含了任何可变状态。例如，coroutine 的局部变量在协程执行暂停时仍然存在，是否应该被视为数据结构是有争议的。
同样，我们通常不会将带有LRU cache 修饰的函数视为“成为”数据结构，而是说它“使用”数据结构进行缓存，并在分析系列的性能时调用（其中一些命中缓存，另一些未命中），我们不会说我们正在分析缓存使用的数据结构，我们会说我们正在分析memoised 算法。
【讨论】：
在许多字符串算法中，您使用摊销来分析运行时间。例如，在线性时间内构建边界数组或后缀树，或从后缀数组遍历模拟的后缀树。
当然，后缀树和后缀数组是数据结构，但您不要使用通常意义上的摊销，即累加一系列修改的成本；您在构造它们或遍历它们的算法时使用它。您将有一些昂贵和一些便宜的步骤，并且摊销可以更容易地计算总运行时间。
通常，您将它用于难以限制每个步骤中使用的时间的算法中，因为它可能取决于数据，但您可以通过各种摊销参数限制总数。你在字符串算法中做了很多，我最熟悉的，但它无处不在。
当然，只有当您必须从某个明确定义的起点执行一系列操作时才有意义（这样您就不会从昂贵的操作开始然后停止）。但除了修改数据结构之外，还有更多的应用。
【讨论】：