停止の問題を回避するプログラムのサブセットはありますか
停止の問題についての別の説明を読んでいただけで、例として挙げられているすべての問題に無限シーケンスが含まれていると考えました。しかし、プログラムで無限シーケンスを使用することはありません。時間がかかるためです。すべての実際のアプリケーションには、上限と下限があります。実数でさえ実際には実数ではありません-それらは32/64ビットなどとして保存された近似です。
問題は、プログラムが停止したかどうかを判断できるプログラムのサブセットがあるかどうかです。ほとんどのプログラムで十分ですか。プログラムの「停止性」を決定できる一連の言語構造を構築できますか？これは以前にどこかで研究されたと思いますので、どんなポインタでもいただければ幸いです。言語は完全にチューリングしているわけではありませんが、ほぼ完全にチューリングしているようなもので十分ですか？
当然のことながら、このような構造は再帰と無制限のwhileループを除外する必要がありますが、十分に簡単にそれらなしでプログラムを書くことができます。
例として標準入力から読み取るには制限が必要ですが、それは十分簡単です。問題のドメインに応じて、入力を10,000,000文字などに制限します。
ティア
[更新]
コメントと回答を読んだ後、多分私は私の質問を言い直すべきでしょう。
すべての入力が制限されている特定のプログラムについて、プログラムが停止するかどうかを判断できます。もしそうなら、言語の制約は何であり、入力セットの制限は何ですか。これらの構成要素の最大のセットは、停止するかどうかを推定できる言語を決定します。これについて行われたいくつかの研究はありますか？
[更新2]
これが答えです、はい、はい、1967年に遡ります http://www.isp.uni-luebeck.de/kps07/files/papers/kirner.pdf
停止状態の問題が少なくとも理論的には有限状態システムで解決できるということは、1967年にミンスキーによってすでに論じられています[4]。反復的なパターン。この繰り返しパターンの継続時間は、マシンの内部状態の数を超えることはできません...」
（したがって、有限チューリングマシンに固執する場合は、Oracleを構築できます）
問題は入力にありません（もちろん、無制限の入力では、入力を読み取るだけで実行時間を無制限にすることができます）。内部状態の数にあります。
内部状態の数が制限されている場合、理論的にはすべての場合で停止の問題を解決できます（停止または状態の繰り返しに達するまでエミュレートするだけです）、そうでない場合は、解決できない場合があります。しかし、内部状態の数が実際に制限されている場合でも、非常に巨大であるため、内部状態の数の制限に依存する方法は、最も些細なプログラム以外の終了を証明するのに役に立ちません。
プログラムの終了を確認するより実用的な方法があります。たとえば、再帰もgotoも行わず、ループ構造のすべてに、ループの開始時に指定する必要のある反復回数に制限があるプログラミング言語でそれらを表現します。 （限界は実際の有効な反復回数に関連している必要はないことに注意してください。ループの終了を証明する標準的な方法は、ある反復から別の反復へと厳密に減少していることを証明する関数を持っていることと、入力条件です。が肯定的であることを確認します。最初の評価を自分の限界として設定できます）。
まず、停止検出器があるとどうなるか考えてみましょう。対角線の議論から、停止している検出器が決して停止しないか、間違った答えを出すプログラムが少なくとも1つ存在することがわかります。しかし、それは奇妙でありそうもないプログラムです。
停止検出器は不可能であるという別の議論がありますが、それは停止検出器が魔法であるというより直感的な議論です。フェルマーの最終定理が真か偽かを知りたいとします。真の場合は停止し、偽の場合は永久に実行するプログラムを作成し、その上で停止検出器を実行するだけです。 プログラムを実行するではなく、停止検出器プログラム上を実行するだけです。停止検出器を使用すると、プログラムを作成するだけで、数論における膨大な数の未解決の問題をすぐに解決できます。
それで、いつでも停止を決定できるプログラムを生成することが保証されているプログラミング言語を書くことができますか？承知しました。ループ、条件、および任意の多くのストレージを使用することはできません。ループなし、「if」ステートメントなし、または厳密に制限された量のストレージを使用する場合は、確実に、停止を常に決定できる言語を記述できます。
Gödel、Escher、Bach を読むことをお勧めします。それは、とりわけゲーデルの不完全性定理と停止問題に触れている非常に楽しくて啓蒙的な本です。
簡単に言えば、質問に答えるには、プログラムにwhileループ（または考えられる多くの兆候のいずれか）が含まれていない限り、停止の問題を特定できます。
限られた量のメモリ（あらゆる種類のストレージを含む）で動作するすべてのプログラムで、停止の問題を解決できます。つまり、決定不能なプログラムは、実行時にますます多くのメモリを使用するようにバインドされています。
しかし、それでも、この洞察はそれが実際の問題に使用できることを意味するものではありません。数キロバイトのメモリで動作する停止プログラムは、宇宙の残りの寿命よりも簡単に停止する可能性があるためです。
実際には、他の問題の停止問題を常に解決するプログラムがあります。これらは、コンピューターを実行しているオペレーティングシステムの一部です。決定不可能性は、他のすべてのプログラムで機能するそのようなプログラムは存在しないとだけ言っている奇妙な主張です。
ミラーリングのように自分自身を無限にたどるので、停止証明はそれを解決できない唯一のプログラムのように思われるとある人が正しく述べました。この同じ人物はまた、停止するマシンがあった場合、ソルバーアルゴリズムが停止するかどうかを事前に通知することで難しい数学の問題を通知するため、魔法になると述べました。
これらのどちらの場合も、トレースする証拠がないため、停止しているマシンはトレースしないと想定されます。ただし、実際には、指定された入力で実行されるプログラムを実際にトレース/実行します。
少なくとも論理的な証明は簡単です。少なくとも最初のステップをトレースする必要がなければ、実行するプログラムと一緒に入力する必要はありません。情報を利用するためには、そのパスの行き先を分析する前に、少なくとも最初のステップをトレースする必要があります。
上の答えで述べられている難しい数学の問題は、答えを理解するために早送りできない問題です。つまり、停止の問題は、何らかのパターンが認識されるまでトレースを続ける必要があります。
したがって、停止問題から得る唯一の実用的な議論は、停止マシンは、最適化された問題ソルバーの結果を、問題ソルバーが完了するよりも早く決定できないということです。
この推論に対する正式な証明を与えることは困難であり、私は可能だと私は信じますが、それを学界の誰にでも説明しようとすると、彼らはかんしゃくのような類人猿を投げ、シャンデリアからスイングします。それらの人々と議論しないことが最善です。
あなたの質問に（部分的に）答えるためには、「停止の問題を回避するプログラムのサブセットはありますか？」：はい、実際にあります。ただし、このサブセットは驚くほど役に立ちません（私が話しているサブセットは、停止するプログラムの厳密なサブセットであることに注意してください）。
「ほとんどの入力」の問題の複雑さの研究は generic-case complex と呼ばれます。可能な入力のサブセットを定義し、このサブセットが「ほとんどの入力」をカバーしていることを証明し、このサブセットの問題を解決するアルゴリズムを提供します。
たとえば、停止の問題は、ほとんどの入力の多項式時間で解決できます（実際、 論文 を正しく理解していれば、線形時間で解決できます）。
ただし、3つの補足事項があるため、この結果はあまり役に立ちません。最初に、現実世界のコンピューター上の現実世界のコンピュータープログラムではなく、単一のテープでチューリングマシンについて説明します。私の知る限り、実際のコンピューターでも同じことが当てはまるかどうかはわかりません（実際のコンピューターはチューリングマシンと同じ機能を計算できる場合がありますが、許可されるプログラムの数、長さ、および停止するかどうかは全然違う）。
次に、「ほとんどの入力」の意味に注意する必要があります。これは、「長さ」nのランダムプログラムがこのアルゴリズムでチェックできる確率は、nが無限大になる傾向があるため、1になる傾向があることを意味します。言い換えれば、nが十分に大きければ、このアルゴリズムによってほぼ確実に長さnのランダムプログラムをチェックできます。
論文に記載されているアプローチで確認できるプログラムはどれですか。基本的に、状態を繰り返す前に停止するすべてのプログラム（「状態」はプログラムのコード行にほぼ対応します）。
ほとんどすべてのプログラムはこの方法でチェックできますが、この方法でチェックできるプログラムはどれも非常に興味深いものではなく、通常は人間が設計することはないため、これは実際には価値がありません。
また、ほとんどすべての興味深いプログラムを（明らかに）チェックするのが難しいため、ジェネリックケースの複雑さは停止の問題を解決できない可能性があることも示しています。または、別の言い方をすれば、ほとんどすべてのプログラムは興味をそそられませんが、簡単に確認できます。
これが答えです、はい、はい、1967年に遡ります http://www.isp.uni-luebeck.de/kps07/files/papers/kirner.pdf
停止状態の問題が少なくとも理論的には有限状態システムで解決できるということは、1967年にミンスキーによってすでに論じられています[4]。反復的なパターン。この繰り返しパターンの継続時間は、マシンの内部状態の数を超えることはできません...」
（したがって、有限チューリングマシンに固執する場合は、Oracleを構築できます）
もちろん、これにかかる時間は別の問題です
プログラムが停止した場合に判断できるプログラムのサブセットはありますか？
はい。
ほとんどのプログラムで十分ですか？
「最も」を定義します。
プログラムの「停止性」を決定できる一連の言語構造を構築できますか？
はい。
ほぼ完全なチューリングのようなもので十分ですか？
「ほぼ」を定義します。
多くの人がwhileステートメントや再帰を使わずにPythonと書いています。
多くの人々はJava forステートメントのみを使用してsimpleイテレータまたはカウンタが終了することを証明できるカウンタ）を使用し、再帰なしで書き込みます。
whileと再帰を回避するのは非常に簡単です。
すべての入力が制限されている特定のプログラムについて、プログラムが停止するかどうかを判断できますか？
番号。
もしそうなら、言語の制約は何であり、入力セットの制限は何ですか。
ええと。停止問題は、プログラムがプログラム自体について複雑なことを判断できないことを意味します。多数の制約のいずれかを追加して、停止の問題を回避できます。
停止問題への標準的なアプローチは、プログラミング言語で利用可能なものよりわずかに「豊富な」数学的形式のセットを使用した証明を許可することです。
言語を制限するよりも証明システムを拡張する方が簡単です。制限があると、その制限のために表現するのが難しい1つのアルゴリズムの引数になります。
これらの構成要素の最大のセットは、停止するかどうかを推定できる言語を決定します。これについて行われたいくつかの研究はありますか？
はい。それは「グループ理論」と呼ばれています。一連の操作の下で閉じられた一連の値。かなりよく理解されたもの。