短いプログラムでは解決できない問題は何ですか?


7

バックグラウンド:

最近、入力として数値の配列を取得するという特定の難しい問題を解決しようとしました。以下のため、私は見つけることができる唯一の解決策は、それぞれに異なる治療持つことだった 3つの数字の順序。つまり、場合には1つのソリューションがあり、の場合には別のソリューションがあります(場合は、これら2つのソリューションのいずれかで解決できます)。nn=3n!=6A>B>CA>C>BA>C=B

ケースについて考えると、唯一の方法は、やはり、すべての異なる順序を考慮して、ケースごとに異なるソリューションを開発することです。それぞれの場合の解決策は高速ですが、プログラム自体は非常に大きくなります。したがって、問題の実行時の複雑さは小さいですが、「開発時間」の複雑さまたは「プログラムサイズ」の複雑さは非常に大きくなります。n=4n!=24

これは私が私の問題が短いプログラムでは解決できないことを試み、証明するように促しました。そこで、同様の証明の参考文献を探しました。

私が見つけた最初の概念はコルモゴロフの複雑さです。ただし、このトピックについて私が見つけた情報は非常に一般的であり、主に存在の結果が含まれています。

質問:

サイズ入力配列でを解くプログラムは少なくともサイズでなければならないなど、特定の実際の問題について説明できますか。ここで、は増加する関数ですの?PPnΩ(f(n))f(n)n

答えは明らかにプログラミング言語の選択に依存するので、JavaまたはTuringマシンでプログラミングすると仮定します。

すべての決定不可能な問題は、まったく解決策がないため、この要件を簡単に満たします。だから私は決定的な言語を探しています。


"特定のアルゴリズム" "特定のアルゴリズムのシーケンス"?

決定不能な問題がある些細な答えに関する最後の文について、より明確にすることができますか。私にはそれについて1つの解釈がありますが、説得力があるとは思いません。
バブー2014年

ゼロから推論して、nの各値のソリューションをもう一度探し始める必要がありますか?または、nがわかっているときに正しいプログラムに到達する方法はありますか?開発時間の複雑さの意味がわかりません...それはあなたの創意にかかっていますか?
バブー2014年

@babou:問題の場合は決定不能で、そこではありません何の解決プログラム。したがって、「解くすべてのプログラム」についてあなたが言うことはすべて、それと矛盾するものは何もないので真実です。空のセットの要素についてあなたが言うことはすべて、真実です。PPP
Erel Segal-Halevi 2014年

@babou:つまり、値ごとに、ソリューションをゼロから考える必要があります。n
Erel Segal-Halevi 2014年

回答:


2

実際に必要なのは、対応するプログラムのサイズが増加するシーケンスを形成するような問題の列挙であると思います。以下はそのような列挙の例です。しかし、私はサイズが限界を超えて増加することを証明しているだけなので、それはにはありません。私はもっ​​と良い方法を試すことができますが、この回答の何があなたの質問の見方では受け入れられないのか疑問に思っています。O(1)

私が正しく理解していれば、あなたが列挙したいアルゴリズムを持つすべての決定可能な問題の 1があった場合、それは時にショートプログラムになるので、これらの問題の労働組合のための均一な決定手続き等がないことを大きくなる、つまります。PnAnnO(1(n))

これは、列挙が計算できないことを意味します。計算可能であれば、の知識からアルゴリズムを計算できるため、列挙型のすべての問題の和集合に対して統一された手順が得られます。AnAnn

したがって、が解くようなアルゴリズムの計算可能な列挙がないような例のみを探すことができます。AnAnPn

その前に、サイズを定義する必要があります

してみましょうゲーデル数によって列挙することチューリング機械の。このようなゲーデル列挙は計算可能です。次に、次の問題としますがすべての入力で停止した場合、はによって認識された再帰セットを認識し、そうでない場合はは空のセット認識します。TnnPnTnPnTnPn

を解くアルゴリズムサイズの下限を探しているので 、TMのサイズを定義する必要があります。TMの場合、そのゲーデル数はマシンのサイズ、つまり対応するアルゴリズムと見なすことができます。実際、ピジョンホールの原理のためだけである場合でも、状態と遷移の数はとともに必然的に増加しますが、必ずしも均一ではありません(とにかくサイズの任意の定義に依存します)。AnPnn

次に、常に停止するTMについて、TMの最小Gôdel数が であることに注意して、常に停止し、と同じ再帰セットをます。したがって、は、実際にを解くアルゴリズムである最小のTMです。つまり、です。 が停止しない場合、場合、TM対応するアルゴリズムを常に使用するだけで、セット認識し、常に同じものを認識します。Tnμ(n)Tμ(n)TnTμ(n)PnAnTnAnT

各問題は決定可能であり、は決定手順です。ただし、列挙は計算できませんが、不可避であることを示しました。PnAnAn

定数与えられた場合、サイズようなが存在することを示すのは簡単ですよりも大きい。その理由は、より小さいマシンの数が有限であるのに対して、TMによって認識される再帰セットの数は無限であるためです。Cn|An|AnCC

したがって、これは短いプログラムで解決できない問題(より正確には問題の列挙)の例です。つまり、各の解の長さに一定の制限がないということです。Pn

問題の制約を満たすために、最初にサイズ配列を読み取るためのソリューションが必要であることを、各問題いつでも追加できます。しかし、それにはほとんど意味がありません。Pnn


ありがとう。これは確かに質問に答えます。私が本当に探しているもの(しかし、正しく尋ねる方法がわからない)は自然な問題であり、実際の問題であり、プログラムのサイズが入力のサイズとともに増加します。
Erel Segal-Halevi 2014年

@ErelSegalHale私はこの現実の側面を認識していましたが、ソリューションの計算不可能な列挙可能性などの問題の特異な特性を考えると、TMの回答と何が区別されるのかはわかりません。問題の列挙が自然なものである場合、実際にそうであるように構築されていない限り、それらがすべて決定可能であることをどのように証明できるのか実際に疑問に思っていました。決定不能性は通常(最終的に)矛盾によって証明されますが、決定可能性は通常建設的に証明されます。これは、すべてに対して決定手順を与えることに相当します。これは、計算可能に列挙できないため、実行できません。
バブー2014年

「ソリューションの計算不可能な列挙可能性を考えると、それがTMの回答と何が区別されるのかわかりません」-これは良い点です。ありがとう。
Erel Segal-Halevi 2014年

7

特定の問題について、その問題の解決策をエンコードするプログラムが単一の文字であるプログラミング言語を作成できます。(HQ9 +を参照)。コルモゴロフの複雑さは言語に依存します。どの問題が爆発を引き起こすかについてのあなたの質問への答えは、あなたが選択する「標準の正式な言語」に大きく依存します。

ただし、興味深い結果がいくつかあります。ランダムに生成された文字列のエンコードには、文字列のサイズに比例したコストが常に必要です。ピジョンホールの原則は、すべてのケースの完全な列挙よりも小さい空間では表現できない関数が、固定言語Lで常に存在することを示しています。また、Blumのサイズ定理は、完全な言語では、チューリング完全言語で同じ関数をエンコードする場合と比較して、任意に選択したブローアップ係数よりも大きくエンコードできる関数が常に存在することを示しています。


「すべてのケースの完全な列挙よりも小さいスペースで表現できない任意の固定言語Lの∃関数。」すべてのケースは何ですか?Webにリファレンスがありますか?
バブー2014年

(ドメイン、範囲)ペアの完全な列挙を意味します。ランダムな文字列の固定セットから別の固定されたランダムな文字列セットへのマッピングなど、このような関数を構築できます。申し訳ありませんが、参照するためのリファレンスがありません。
dmbarbour 2014年

私はあなたがそのような問題の列挙を意味するので、各はn(ドメイン、範囲)ペアの列挙と同じ大きさでなければなりません(それは正しいですか?)。残念ながら、これに関する詳細情報を見つける手掛かりはありません。PnPn
babou 2014年

6

関数のシーケンスが存在することがシャノンの状態の結果それほど問題点である計算するためは少なくともブール演算が必要です(つまり、を計算する回路の複雑さは少なくとも)。fn:{0,1}n{0,1}P(n)fn(x)x{0,1}nΘ(2nn)fn(x)Θ(2nn)

この定理は、ブール関数があるため、取得するのはそれほど難しくありませんが、指定されたサイズの回路の数は厳密に少なくなります。2(2n) n


わかりました、これは大きなプログラムを必要とする問題の存在を示していますが、特定の(既知の)問題が大きなプログラムを必要とするという具体的な証拠を探しています。
Erel Segal-Halevi

1
これは本当に満足できる答えではないことを知っていました。投稿のように、回路のサイズは入力のサイズによって異なるため、回路の複雑さは「プログラムの長さ」に最も近いものだと思います。この領域の下限はいくつかの特定の問題で知られているはずですが、私は専門家ではありません。
zarathustra 2014年

1
回路のサイズは、プログラムコードのサイズというよりは、プログラム実行の複雑さに似ていると思います。私の考えは、各ゲートは一度だけ使用されるということです。一種の線形論理です。ソフトウェアで同じことを行う場合、サブプログラムを何度も呼び出すことで因数分解できますが、プログラムのサイズは同じですか?CC @ErelSegalHalevi
2014年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.