为什么我们总是考虑最坏的时间复杂性？

Question

为什么我们只关注最坏情况时间复杂度（Big O），给定数据集和2个代码片段/算法，我们能否始终确保算法将采用最坏的情况复杂度？

Answer 1

简短的回答：你不应该只关心最坏情况的复杂性。

如果你有一个实际有界的情况，那么常数因子可能比渐近复杂性更重要。示例：假设您有10个项目的集合。您可以在字典/映射/散列表中进行O（1）查找，或者在排序列表中进行O（log N）查找，或者在未排序列表中进行O（N）查找。

对于10个项目，渐近复杂性很少。实际上，由于更大的常数因子，O（1）字典查找可能比O（log N）排序列表查找慢。

所以你应该只关注渐近的复杂性，当你有很多东西的时候。

Answer 2

我们不仅关注最坏情况的时间复杂性（或者如果你是，你不应该） - 另见Meaning of average complexity when using Big-O notation。平均时间可能同样有效，但在许多情况下，您希望确保算法不会花费很长时间。作为一个例子，为什么你会更关心'最坏情况'：假设你可能不介意算法需要1或2秒*，但你想确保至少它不需要一个小时一些案例。

*是的，显然这在很多情况下非常重要，但假设这是一个需要运行一次的脚本。

问题的第二部分：不，我们不能总是确定“更复杂”的算法花费的时间最长（我假设通过“采取复杂性”，就像你说的那样，你的意思是'它在特定情况下实际需要多长时间'）。 一个微不足道的反例是某种低效的“查找（第一次......）”算法恰好可以非常快速地获得指定的项目，而另一种好的算法只需要更长的时间，因为它会迭代文件/数组不同的顺序或方向。这显然将取决于很多数据，例如假设你感兴趣的值更有可能发生在文件/数组的末尾。

Answer 3

我认为这三种复杂性都很重要。 这取决于您，您想要什么。

例如，有一个尺寸为x的管，您开始向其中填充水。 要知道何时水会开始溢出，您会发现上限（大小或容量），即最坏的情况下，该管可以容纳多少升水。

如果您想了解算法在最坏情况下的行为，即我的算法在最坏情况下将占用多少时间和空间，那么您需要考虑BIG（o），即上限。

类似地，您也可以追求最佳和平均水平。