Question

是否存在时间复杂度为O（n ^ n）的真实算法，这不仅仅是一种噱头？

我可以创建这样一个算法，比如在O（n ^ n）/Θ（n ^ n）中计算n ^ n：

long n_to_the_power_of_m(int n, int m) {
    if(m == 0) return 1;
    long sum = 0;
    for(int i = 0; i < n; ++i)
        sum += n_to_the_power_of_m(n, m-1);
    return sum;
}

（计算10 ^ 10需要超过4分钟）

或者其他方式：是否存在任何问题，哪些问题无法比O（n ^ n）更好地解决？

Answer 1

您在示例中编码的内容与深度优先搜索非常相似。所以，这是一个答案。

没有任何特殊特征的深度优先搜索算法（如可以优化的重新聚合路径）应该是n ^ n。

这实际上不是一个人为的例子。国际象棋程序在相同的算法上运行。每次移动都有n个动作要考虑（即分支），你搜索d移动深。所以这就变成了O（n ^ d）

Answer 2

有计算（例如，tetration），其中输出大小为O（n ⁿ）。在时间复杂度小于O（n ⁿ）的情况下计算它们很难。

Answer 3

根据Wikipedia，存在一些双指数时间问题O（2 ^{2 ^poly（n）}），它比O更复杂（n n ），例如“Presburger arithmetic的决策程序”（O（2 ^{2 ^cn}））和“计算Gröbner basis”（最坏情况下为O（2 <2） SUP> 2 ^{N / 10} ）

Answer 4

有许多优化问题基本上是O（n！），即数据压缩。这一切的常见算法都需要作弊这种或那种方式（很多都依赖于启发式方法）但不能确保它们以这种方式找到了完美的结果。即在压缩PNG图像期间选择最佳line filters是一个相对容易理解的问题。

另一个例子是打破加密的算法，可能比O（n！）更差。

Answer 5

描述（终止）图灵机的程序，并返回终止所需的步骤数。这是一个相对简单的编写程序 - 它可以简单地模拟图灵机，并计算步骤。

这个程序的复杂性没有可计算的上限（特别是比任何可计算函数增长得快），所以肯定比O（n ^ n）增长得快。

大小为n的输入上的最坏情况运行时间是BB（n），Busy Beaver序列开始0,1,4,6,13，此后未知（尽管下限为存在 - 例如，接下来的两个值分别至少为47176870和7.412×10 ^ 36534）并且对于n足够大是不可计算的。

有没有真正的O（n ^ n）算法？

5 个答案: