CLRS书如何得出结论BUILD_MAX_HEAP与O（n log n）不是渐近紧密的？

Question

CLRS书页第157号第3版。我的问题不在于为什么BUILD_MAX_HEAP的复杂性是O（n）也不是证明。然而，对于系统方法，他们曾经得出结论，它在O（n log n）处并非渐近紧。逻辑上说O（n log n）是正确的。

我被困住的一点是他们是如何得到直觉的，那就是更好的上限。如果不是CLRS的解释。我们会知道吗？

我关于直觉的问题的核心是我们必须自我意识到存在更好的紧缩。

我们是否想要为我们找到的每个算法寻找更紧密的约束？我的意思是外行人的逻辑结论是O（n log n）。他怎么能从这里走得更远。我错过了一些基础知识吗？

Answer 1

  

他们是如何得到这样的直觉的，即上限更紧密。

我不知道他们是如何明确地获得直觉的，但这是一种看待它的方式（可能有后见之明）。

Build-Heap的复杂性，至少在直觉上，似乎与

类似

T（n）= T（n / 2）+Θ（n）

其解决方案是 T（n）=Θ（n）。

（请注意，以下内容不是证明，而只是直觉！）

假设您有一个带有 n / 2 元素的二进制堆，并且其最后一行已满，并且您将元素数量加倍。这基本上会添加另一行。

如何将元素数量加倍（至少在这种情况下），更改Build-Heap的时间？

• 由于倒数第二行，有{em>Θ（n）对Heapify的更多调用，但每个调用显然 O（1）工作。

• 对于倒数第二行以上的行，Θ（n）对Heapify的调用基本上与以前一样，但每个都有另一个 O（1） 最后工作（路径长1）。

  

我们是否想要为我们找到的每种算法寻找更紧密的约束？

在某种程度上，是的。找到更紧密的算法边界总会产生兴趣。请注意，对于Heapsort，我们甚至对proving感兴趣，即一个变体使用 2 n log（n）（1 - o（1））操作，而另一个变体使用了 n log（n）（1 + o（1））操作，即使两者都是Θ（n log（n））。

  

我的意思是外行人的逻辑结论是O（n log n）。

Laymen可能主要使用专家对其进行广泛研究的算法。

  

他怎么能从这里走得更远。

可能没有找到算法边界的算法。一种可能的方法是绘制运行时间以增加 n 的值，并查看运行时间的外观。如果它看起来是线性的，那么它不是一个证明，但它表明要寻找什么。