時間計算量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)よりもうまく解決できない問題はありますか?
例でコーディングしたものは、深さ優先探索と非常によく似ています。だから、それは一つの答えです。
特別な特性(最適化できる再収束パスなど)のない深さ優先探索アルゴリズムは、n ^ nである必要があります。
これは実際には不自然な例ではありません。チェスプログラムは同じアルゴリズムで動作します。それぞれの動きには考慮すべきn個の動き(つまりブランチ)があり、d個の動きを深く検索します。つまり、O(n ^ d)になります
出力サイズがO(n)である計算(たとえば、 tetration )がありますn)。 O(n)未満の時間計算量でそれらを計算するのはちょっと難しいですn)。
本質的にO(n!)である、つまりデータ圧縮における多くの最適化問題があります。このための一般的なアルゴリズムはすべて、何らかの方法でチートする必要があります(多くはヒューリスティックに依存しています)が、完璧な結果を見つけたかどうかを確認することはできませんこちらです。つまりPNG画像の圧縮中に最適な ラインフィルター を選択することは、比較的理解しやすい問題です。
もう1つの例は、暗号化を解除するアルゴリズムです。これは、O(n!)よりもさらに悪い可能性があります。
(終了する)チューリングマシンの説明を受け取り、終了するのにかかるステップ数を返すプログラム。これは比較的簡単に作成できるプログラムです。チューリングマシンをエミュレートし、歩数を数えるだけです。
このプログラムの複雑さには計算可能な上限がないため(特に、計算可能な関数よりも速く成長します)、確かにO(n ^ n)よりも速く成長します。
サイズnの入力での最悪の場合の実行時間はBB(n)であり、0、1、4、6、13で始まる ビジービーバー シーケンスはこの後は不明です(ただし、境界が存在します。たとえば、次の2つの値はそれぞれ少なくとも47176870と7.412×10 ^ 36534)であり、nが十分に大きい場合は計算できません。