最坏情况时间复杂度O(n)的算法总是比最坏情况时间复杂度为O(n ^ 2)的算法快吗?

时间:2016-06-15 22:19:53

标签: algorithm performance time-complexity

这个问题出现在我的算法类中。这是我的想法:

我认为答案是 no ,O(n)的最坏情况时间复杂度的算法总是总是比具有最坏情况时间复杂度的算法更快O(n ^ 2)。

例如,假设我们有总时间函数S(n)= 99999999n和T(n)= n ^ 2。然后,显然S(n)= O(n)和T(n)= O(n ^ 2),但是对于所有n <1,T(n)比S(n)快。 99999999

这种推理有效吗?我有点怀疑,虽然这是一个反例,但它可能是错误想法的反例。

非常感谢!

4 个答案:

答案 0 :(得分:4)

Big-O表示法没有说明任何给定输入的算法速度;它描述了时间如何随着元素的数量而增加。如果你的算法在恒定的时间内执行,但那个时间是1000亿年,那么对于大范围的输入,它肯定比许多线性,二次甚至指数算法慢。

但这可能并不是问题所在。问题是询问具有最坏情况复杂度O(N)的算法A1是否总是比具有最坏情况复杂度O(N ^ 2)的算法A2 更快;并且通过更快它可能指的是复杂性本身。在这种情况下,您只需要一个反例,例如:

  • A1具有正常复杂度O(log n),但最坏情况复杂度为O(n ^ 2)。
  • A2具有正常复杂度O(n)和最坏情况复杂度O(n)。

在这个例子中,A1通常比A2更快(即比例更好),即使它具有更大的最坏情况复杂性。

答案 1 :(得分:2)

你在谈论最坏情况的复杂性,对于某些算法,最坏的情况在实际应用中永远不会发生。

假设算法运行速度快于另一个算法意味着对于所有输入大小的所有输入数据运行速度更快。因此,您的问题的答案显然是 no ,因为最坏情况下的时间复杂度并不是运行时间的准确度量,它衡量的是最坏情况下运算次数的增长顺序。 / p>

实际上,运行时间取决于实现,而不仅仅是这个操作数量。例如,人们必须关心分配的内存,缓存效率,空间/时间局部性。显然,最重要的一点是输入数据。

如果您想要一个算法比另一个算法运行得更快而具有更高的最坏情况复杂度的示例,请根据输入查看所有排序算法及其运行时间。

答案 2 :(得分:2)

由于问题是Always,这意味着只需要找到一个反例就可以证明答案是否定的。

O(n ^ 2)和O(n logn)的例子,但对于O(n ^ 2)和O(n)

也是如此

一个简单的示例可以是冒泡排序,您可以继续比较对,直到对数组进行排序。冒泡排序为O(n ^ 2)。 如果在排序的数组上使用冒泡排序,它将比使用时间复杂度O(nlogn)的其他算法更快。

答案 3 :(得分:2)

从各方面来看,你都是正确的,你在声明中提供了一个反例。如果是考试,那么期间,它应该给你满分。

然而,为了更好地理解大O符号和复杂性,我将在下面分享我自己的推理。我还建议你在困惑时总是考虑以下图表,尤其是O(n)和O(n ^ 2)行:

enter image description here

Big-O表示法

当我第一次学习计算复杂性时,

我自己的推理是,

  

Big-O符号表示足够大的输入,“足够”取决于确切的公式(使用图表,当比较O(n)&amp; O(n ^ 2)线时n = 20),更高订单1总是慢于低订单1

这意味着,对于小输入无保证更高阶复杂度算法的运行速度低于低阶序列。

但是 Big-O表示法告诉你一个信息:当输入大小保持增加时,继续增加....直到“足够”大小,在此之后,更高阶的复杂度算法总是更慢。这样“足够”的大小保证存在*。

最糟糕的时间复杂性

虽然Big-O表示法提供算法运行时间的上限,但取决于输入的结构算法的实现,它可能通常具有最佳复杂性,平均复杂性和最差复杂性。

着名的例子是排序算法:QuickSort vs MergeSort!

QuickSort,最坏情况为O(n ^ 2)

MergeSort,最坏情况为O(n lg n)

然而,Quick Sort is basically always faster than Merge Sort

所以,如果你的问题是关于最坏情况复杂性,快速排序&amp;合并排序可能是我能想到的最好的反例(因为它们都是常见的和着名的)

因此,结合两个部分,无论从输入大小,输入结构,算法实现的角度来看,你的问题的答案都是 NO