大 O(n logn) 不如 O(n^2)答案

【问题标题】：Big O(n logn) is not preferable over the O(n^2)大 O(n logn) 不如 O(n^2)
【发布时间】：2016-02-05 15:44:31
【问题描述】：

任何算法示例何时我们更喜欢大 O(n^2) 时间复杂度而不是 O(n logn)？我在某处看到过这个问题，但没有找到答案。

【问题讨论】：

Are there any cases where you would prefer a higher big-O time complexity algorithm over the lower one?的可能重复
这是关于选择“较慢”算法的一般原因（在这种情况下：是的，重复），还是关于实际的真实示例？

【解决方案1】：

对于一个大问题，O(n log n) 总是会击败 O(n^2)。对于一个小问题，大 O 符号隐藏的常数因子可能会导致您更喜欢 O(n^2) 算法。例如，O(n log n) 快速排序比 O(n^2) 插入排序快，但是当分区变小（少于 10 个元素）时，一些快速排序实现会切换到插入排序。

【讨论】：

非常真实，人们往往会忘记所有 Big-O 声明的开头语句：“有一个 n0，因此对于所有 n > n0...”。此外，这个n0 可能非常大。
是的，最近有一个类似的问题； stackoverflow.com/questions/35218322/…
Quicksort 在最坏情况下为 O(n^2)（尽管避免最坏情况输入相当简单）；但换个例子来说，快速排序通常比堆排序和归并排序等 O(n lg n) 算法的性能更好。

【解决方案2】：

选择具有更高时间复杂度的算法有几个原因：

速度：渐近复杂度仅适用于大于某个 n_0 的 n 值。此外，它还假设某台机器下面仅部分匹配具有多级缓存和受限内存的真实机器。
空间：某些算法比其他算法需要更多空间，因此无法实现。此外，这可能只会影响真机上的速度。例如，引用的位置对缓存命中或未命中有影响，这就是 Quicksort 比 Mergesort 表现更好的原因。
实施复杂性：在某些情况下，性能损失可以忽略不计，但开发时间却不是。

【讨论】：

【解决方案3】：

许多天真的 O(n^2) 算法在小输入上比它们更复杂的 O(n log(n)) 兄弟更快。

例如，GNU MP Bignum library 具有高度优化的乘法实现。但是对于由几十个单词组成的数字，它只使用教科书乘法（最佳阈值depends heavily on the machine）。其实GMPtransitions through a whole sequence of fastest-around-size-X algorithms.

【讨论】：

【解决方案4】：

一种可能性 - O(n logn) 算法是递归的，但您可以迭代地编程 O(n^2)，并且您必须使用的编程语言不支持递归。

“首选”在这里是相对的 BTW。如果数据集足够大，您可以通过使用您自己的堆栈变量来模拟递归，您可以在迭代实现的“递归”算法版本中操作该变量（我们必须在盖伊斯蒂尔的 CMU 的比较编程课程中进行该练习回到过去）。

【讨论】：