从运行时分析推导出时间复杂度答案

【问题标题】：Deriving time complexity from runtime analysis从运行时分析推导出时间复杂度
【发布时间】：2020-05-29 09:53:09
【问题描述】：

作为一名非计算机科学家，我发现理解时间复杂度及其计算方式有点困难，所以我的问题是，某个算法/程序的时间复杂度是否可以通过越来越多地运行而得出大输入数据，然后看看运行时相对于输入大小的增加如何变化n。

我问这个是因为我用 C++ 编写了一个算法，它基本上使用单个 cpu 内核和单个线程（3GHZ 处理器）对 2D 图像进行像素着色。我测量了从2^4 到2^30 的输入大小的运行时间，这是一个大小为32,768 ** 2 的矩阵。现在我有了这个关于我的运行时如何作为输入大小的函数n 的图表：

所以对于n = 2^4 to 2^30 的输入大小，确切的运行时间是（按行）：

 [1]  0.000  0.000  0.000  0.000  0.000  0.000  0.000
 [8]  0.000  0.000  0.000  0.000  0.001  0.000  0.000
[15]  0.002  0.004  0.013  0.018  0.053  0.079  0.231
[22]  0.358  0.963  1.772  4.626  9.713 25.582

现在这有点奇怪，因为当 2 的幂从奇数变为偶数时，运行时间仅增加了 1.5，但当它从偶数变为奇数时，运行时间增加了三倍。因此，当我将输入加倍时，我的运行时间平均增加了(3 + 1.5) / 2 = 2.25 的倍数。事实上，似乎当 n 变得任意大时，来自Odd to even 和even to Odd 的幂参数的变化都会导致运行时间乘以常数 2.25，换句话说：随着 n 变大，运行时间乘数收敛到 2.25。

如果我的算法相当复杂，有没有办法从这个分析中说明它的时间复杂度？

【问题讨论】：

时间复杂度是一个数学指标，通常独立于实现来考虑，所以我想说你不能用实验结果来得出关于算法的时间复杂度的结论。不过，您可以使用这些结果得出关于某些用例中当前实现的可扩展性和通常行为的结论。它仍然是一个非常重要的度量，例如在矩阵乘法方面，我们不使用最快的算法，而是使用最有效的实现。
我认为这只是将曲线拟合到某些数据点的问题。奇怪的时间可能是由于缓存效应。

标签： algorithm time-complexity runtime big-o

【解决方案1】：

有C(4 * n) = (1.5 * 3) * C(n) 表明你在O(n^1.08) 中有复杂性-- 1.08 ~ log(4.5)/log(4).

当然这只是一个提示，我们不能渐近地证明什么。

【讨论】：

【解决方案2】：

我认为很多算法找出一条与数据拟合得很好的曲线，然后使用该曲线的表达式作为工作复杂度是完全合理的。为了使其正常工作，您可能希望为您的算法丢弃“小”输入大小并专注于较大的输入，以最大限度地减少非渐近开销的影响。

例如，我们可以说它很可能比二次函数增长得更快，因为求解 f(30) 的常数，然后计算我们对 f(20) 的期望得到一个太大的数字，这意味着我们的函数渐近地增长比二次地快得多。如果我们假设一个指数函数并求解 f(30) 处的常数，我们会得到 f(20) 的预期值，该值更接近实际数字（虽然有点低，所以我们的函数可能增长得更慢一些比 A*2^n ... 但我们可能会引入一个新的因子 B 来找到 A*2^(Bn) 并更接近）。

这不是计算您正在查看的图表的函数的理论渐近时间复杂度的有效或可接受的方法，但我认为可以根据此图表说您的渐近复杂度可能是指数级的，基数约为 2 .

实际上，您的函数看起来像是将值加倍并交替加倍。如果情况确实如此，那么您会期望 n 每增加两次就会产生六倍的增加； 6 的平方根大约是 2.45，所以你的函数实际上可能是像 A*2.45^n 这样的指数函数，或者至少这可能比使用基数 2 更适合。

【讨论】：

但是如果我的输入增长 x2，而我的时间平均增长 x2.25，为什么它是指数级的？
我之所以问，是因为您评论中的 f(30) 比 f(20) 大 2^10 或 1024 倍，而运行时间增加不到 x150
@dvd280 啊，你是对的，我忘记了时间是 2^n 而不是 n。那么，基数很重要，因为这将决定增长率。因此，如果曲线的底部（像我一样使用 n 而不是 2^n）是 2，那么你就有了线性增长。如果底数为 4，则您有二次增长（因为 4^n = (2^n)^2）。很好的收获。