Algorithm n或nlog（n）比常数时间或对数时间好吗？

在关于Coursera的普林斯顿教程中，讲师解释了遇到的常见增长函数顺序。他说，线性和线性计算的运行时间是“我们努力争取的”，他的推理是，随着输入大小的增加，运行时间也会增加。我认为这就是他犯错误的地方，因为我以前听他说线性增长顺序对于一个有效的算法来说是不令人满意的

---

在他讲话时，他还展示了一张绘制不同运行时间的图表——常数和对数运行时间看起来更有效。那么这是一个错误还是真的？

在上下文中，O（n）和O（n logn）函数比O（1）和O（logn）函数具有更好的复杂性，这是一个错误。当以大O表示法查看复杂度的典型案例时：

O（1） 请注意，这并不一定意味着它们总是具有更好的性能—我们可以有一个O（1）函数，它需要很长时间才能执行，即使它的复杂性不受元素计数的影响。这样的函数在大O表示法中看起来比O（logn）函数更好，但实际上在实践中性能更差

---

一般来说：当n足够高时，复杂度较低的函数（用大O表示法）将优于复杂度较高的函数（用大O表示法）。

您错过了这些语句必须在其中进行的更广泛的上下文。不同类型的问题有不同的要求，甚至往往有理论上的下限，即解决这些问题绝对需要做多少工作，无论采取何种手段

对于排序或扫描简单集合的每个元素之类的操作，可以为这些操作设置集合中元素数的硬下限，因为输出取决于输入的每个元素。[1] 因此，O（n）或O（n*log（n））是最好的选择

对于其他类型的操作，如访问哈希表或链表的单个元素，或在排序集中搜索，该算法不需要检查所有输入。在这些设置中，O（n）操作将非常慢

---

[1] 其他人会注意到，根据信息论参数，按比较排序也有一个n*log（n）下限。对于某些类型的输入，有一些基于非比较的排序算法可以克服这一点。

他说，这些算法是我们努力追求的，这通常是正确的。许多算法不可能比对数时间或线性时间更好地改进，而在完美的世界中，常数时间会更好，但通常无法实现。

常数时间总是更好，因为时间（或空间）复杂性不取决于问题的大小。。。这不是一个很棒的功能吗？：-）

然后我们有O（N）和Nlog（N）

你知道吗？存在具有恒定时间复杂性的问题

e、 g

---

设A[N]为N个整数值的数组，N>3。查找并使用算法判断前三个元素的和是正还是负

一般来说，我们所追求的是我们能做到的最好的。但根据我们所做的，可能是O（1），O（logn），O（logn），O（N），O（nlogn），O（N2），O（N3），或者（或者某些算法）可能是O（N！），甚至是O（2N）

举个例子，当您处理排序集合中的搜索时，二进制搜索几乎是琐碎的，并且给出了O（logn）复杂性。如果集合中项目的分布是合理可预测的，我们通常可以做得更好——大约是O（logn）。知道了这一点，一个O（N）或O（N2）（对于几个明显的例子）的算法可能会非常令人失望

另一方面，排序的复杂度通常要高得多——好的算法管理O（N logn），差的算法通常在O（N2）左右。因此，对于排序来说，O（N）算法实际上是非常好的（事实上，仅适用于相当受约束的输入类型），我们可以非常依赖这样一个事实：像O（logn）这样的东西根本不可能

---

更进一步，我们很乐意只在O（N2）而不是通常的O（N3）中管理矩阵乘法。考虑到旅行商问题或子集和问题的最优解通常需要O（N！），我们会欣喜若狂地只在O（N3）中得到最优的、可重复的答案。

具有次线性行为（如O（1）或O（Log（N））的算法的特殊之处在于它们不需要查看所有元素。在某种程度上，这是一个谬误，因为如果真的有N个元素，那么仅仅读取或计算它们就需要O（N）

在执行一些预处理之后，通常可以使用次线性算法。考虑排序表中的二进制搜索，取O（Log（N））。如果最初未对数据进行排序，则首先对其进行排序需要花费O（N Log（N））。如果在同一数据集上执行多个搜索（例如K），则排序的成本可以平衡。事实上，如果没有排序，搜索的成本将是O（kn），而使用预排序O（nlog（N）+klog（N））。如果K>>记录（N），则获胜

---

这就是说，当不允许预处理时，O（N）行为是理想的，O（N Log（N））也是相当舒适的（对于一百万个元素，Lg（N）仅为20）。你开始尖叫O（N²）甚至更糟。

我们追求的是效率，即设计时间（或空间）复杂度不超过理论下限的算法

例如，使用基于比较的算法，在排序数组中找不到比Omega（Log（N））更快的值，在最坏的情况下，也不能对数组进行比Omega（N Log（N））更快的排序

因此，二进制搜索O（Log（N））和Heapsort O（N Log（N））是有效的算法，而线性搜索O（N）和Bubblesort O（N²）则不是

下界取决于问题t