【问题标题】:amortized analysis and one basic question (is there any simple example)?摊销分析和一个基本问题(有没有简单的例子)?
【发布时间】:2021-01-06 16:04:45
【问题描述】:
我看到两句话:
一系列操作的总摊销成本必须是上限
受限于序列的总实际成本
将摊销成本分配给数据结构上的操作时,您
需要确保,对于执行的任何操作序列,
摊余成本的总和总是至少与
这些操作的实际成本。
我的挑战是两件事:
A) 两者的含义:amortized cost >= Real Cost of operation? 我认为摊销是(n* 实际成本)。
B)有什么例子可以让我更清楚地理解吗?一个真实而简短的例子?
【问题讨论】:
标签:
python
algorithm
math
data-structures
time-complexity
【解决方案1】:
摊销解决的问题是常见操作可能会触发偶尔的慢操作。因此,如果我们将最坏的情况加起来,我们实际上是在查看如果垃圾收集始终在运行并且每次都必须在内存中移动每个数据结构时程序将如何执行。但是,如果我们忽略最坏的情况,我们实际上就是忽略了垃圾收集有时确实会运行,而大型列表有时确实会用完分配的空间,因此必须将其移动到更大的存储桶中。
我们通过逐渐注销偶尔的大型操作来解决这个问题。一旦我们意识到有一天可能需要它,我们就会将其注销。这意味着摊销成本通常大于实际成本,因为它包括未来的工作,但有时实际成本远大于摊销成本。而且,平均而言,它们的结果大致相同。
人们开始使用的标准示例是一个列表实现,其中我们分配 2 倍我们当前需要的空间,然后在空间用完时重新分配和移动它。当我在这个实现中运行foo.append(...) 时,通常我只是插入。但有时我不得不复制整个大列表。但是,如果我刚刚复制并且列表中有 n 项目,那么在我 append n 次之后,我需要将 2n 项目复制到更大的空间。因此,我对append 成本的摊销分析包括插入和移动 2 件物品的成本。在接下来的n 次我调用append 时,我的估计超过了实际成本n-1 次,并且低于nth 次,但平均结果完全正确。
(Python 的真正列表实现是这样工作的,只是新列表的大小大约是旧列表的 9/8。)