Question

除了用于评估算法的渐近复杂度（Big-O表示法）之外，最常用的概念是什么？

示例：

假设我有以下算法调用函数func，复杂度为O（1）。然后该算法将具有复杂度O（N1×N2）。但如果我事先知道N1是有限的[1,5]那么最坏的情况就是O（5 x N2），根据定义，它也是O（N2）。

for i in range(N1):
    for j in range(N2):
        func(i,j)

如果我可以使用函数func2遇到此算法的不同实现，再次使用复杂度O（1），但现在使用不同的外部循环范围N3。预计该算法为O（N3×N2）。但是，如果我知道N3的范围是[10,50]，那么最坏情况的复杂性将是O（50 x N2），它再次是O（N2）。

for i in range(N3):
    for j in range(N2):
        func2(i,j)

问题：

因此，这是一个简单的证明渐近符号是有用的，但对于某些更具体的情况可能不是最合适的比较方法。如何比较这两种算法？最常用的方法是什么？仅使用算法所需的迭代次数是技术上严格的度量标准吗？

任何推荐参考？

Answer 1

你的问题很大。阅读有关算法复杂性和指标的信息。

你的问题是，即使你不使用Big-O（还有许多其他的小o-Big-omega，小欧米茄，theta等），你将无法轻易地比较算法的方式看来你想要的！主要原因是您必须首先明确定义要测量的内容，这并不容易。一般来说，您不需要详细信息。为什么？因为我们知道我们总能线性地加速任何算法（粗略地说，特殊情况在这里不相关）。所以乘法常数是不相关的。

现在，您想要的是（最坏情况，最佳情况或平均情况）更多的运行时间预测函数，它与精确复杂度有某种关联。但即使在那里，也存在许多陷阱和陷阱。您可能认为两个具有精确复杂度的算法（例如3n + 45）将在同一平台上运行速度快，但这可能是错误的！如果你没有准确定义你的数量，那么这可能是错误的。可以使用3n次乘法和其他3n次加法（或者更精细的混合），并且乘法和加法的运行时间通常不相同。最糟糕的是，由于架构可能使用管道，预测和其他运行时优化，这可能会大大改变运行时间。即使是环境平台也可能引入严重的偏见，考虑虚拟内存，缓存，各种编译器优化等等。

所以，答案是：这取决于你想要预测的内容......这就是为什么会有这么多复杂性措施。

除了渐近（Big-O - 表示法）之外的算法的复杂性

1 个答案: