停止の問題を回避するプログラムのサブセットはありますか

私は停止する問題の別の説明を読んでいたところ、例として挙げられているすべての問題が無限のシーケンスに関係していると考えるようになりました。しかし、プログラムで無限シーケンスを使用することはありません。時間がかかりすぎます。すべての実世界のアプリケーションには下限と上限があります。実数でさえ真の実数ではありません-32/64ビットなどとして保存された近似値です。

問題は、プログラムが停止した場合に判断できるサブセットがあるかどうかです。ほとんどのプログラムで十分ですか？プログラムの「停止可能性」を判別できる言語構成体のセットを作成できますか。私はこれがどこかで以前に研究されたと確信しているので、どんなポインタでも評価されるでしょう。言語は完全なチューリングではありませんが、チューリングがほぼ完了しているようなものがありますか？

当然のことながら、このような構成体は再帰と無制限のwhileループを除外する必要がありますが、これらを使用しないプログラムは簡単に作成できます。

例として標準入力からの読み取りは制限されなければなりませんが、それは十分に簡単です-問題のドメインに応じて、入力を10,000,000文字などに制限します。

ティア

[更新]

コメントと回答を読んだ後、おそらく質問を書き直すべきです。

すべての入力が制限されている特定のプログラムについて、プログラムが停止するかどうかを判断できます。その場合、言語の制約は何であり、入力セットの制限は何ですか。これらの構成体の最大セットは、停止するかしないかを推測できる言語を決定します。これについて行われた研究はありますか？

[更新2]

これが答えです、はい、1967年にhttp://www.isp.uni-luebeck.de/kps07/files/papers/kirner.pdfから遡ります

有限状態システムの停止問題は少なくとも理論的に解決できることは、1967年にミンスキーによって既に議論されています[4]：「...有限状態のマシンは、完全に放置されると、最終的に完全に周期的になり繰り返しパターン。この繰り返しパターンの期間は、マシンの内部状態の数を超えることはできません...」

（したがって、有限チューリングマシンに固執する場合は、オラクルを構築できます）

この問題は入力ではなく（明らかに、無制限の入力では、入力を読み取るだけで無制限の実行時間を持つことができます）、内部状態の数にあります。

内部状態の数が制限されている場合、理論的にはすべての場合に停止の問題を解決できます（停止または状態の繰り返しに達するまでエミュレートします）。そうでない場合は、解決できない場合があります。しかし、内部状態の数が実際には制限されている場合でも、内部状態の数の制限に依存する方法は、最も些細なプログラム以外の終了を証明するのに役に立たないほど巨大です。

プログラムの終了を確認するより実用的な方法があります。たとえば、再帰もgotoも持たず、ループのエントリで指定する必要のある反復回数にループ構造がすべて制限されているプログラミング言語で表現します。（境界は実際の反復回数に実際に関連する必要はないことに注意してください。ループの終了を証明する標準的な方法は、反復ごとに厳密に減少していることを証明する関数を使用することです。確実に肯定的であれば、最初の評価をあなたの限界として置くことができます）。

まず、検出器が停止した場合に何が起こるかを考えます。対角線の議論から、停止しているディテクターが停止しないか、間違った応答をするプログラムが少なくとも1つ存在することがわかります。しかし、それは奇妙でありそうもないプログラムです。

ただし、停止検出器は不可能であるという別の議論があり、それは停止検出器が魔法であるというより直感的な議論です。フェルマーの最終定理が真であるか偽であるかを知りたいとします。真であれば停止し、偽であれば永久に実行するプログラムを作成し、その上で停止ディテクターを実行します。プログラムを実行するのではなく、プログラムで停止検出器を実行するだけです。検出器を停止すると、プログラムを書くだけで、数論の未解決の膨大な問題をすぐに解決できます。

それで、停止を常に決定できるプログラムを生成することが保証されているプログラミング言語を書くことができますか？はい。ループや条件を持たせたり、任意の量のストレージを使用したりすることはできません。ループなし、「if」ステートメントなし、または厳密に制限された量のストレージを使用する場合は、停止が常に決定可能な言語を作成できます。

ゲーデル、エッシャー、バッハを読むことをお勧めします。とりわけ、ゲーデルの不完全性定理と停止する問題に触れている非常に楽しくて啓発的な本です。

簡単に質問に答えるには、プログラムにwhileループ（またはその多くの可能な兆候）が含まれていない限り、停止の問題は決定可能です。

限られた量のメモリ（あらゆる種類のストレージを含む）で動作するプログラムごとに、停止の問題を解決できます。つまり、決定できないプログラムは実行時にますます多くのメモリを使用することになります。

しかし、たとえそうであっても、この洞察は、現実の問題に使用できることを意味するものではありません。数キロバイトのメモリで作業している停止プログラムは、宇宙の残りの寿命よりも簡単に長く停止する可能性があるからです。

（部分的に）「停止の問題を回避するプログラムのサブセットはありますか？」という質問に答えるために：はい、実際にあります。ただし、このサブセットは驚くほど役に立たない（私が話しているサブセットは停止するプログラムの厳密なサブセットであることに注意してください）。

「ほとんどの入力」の問題の複雑さの研究は、一般的なケースの複雑さと呼ばれます。可能な入力のサブセットを定義し、このサブセットが「ほとんどの入力」をカバーすることを証明し、このサブセットの問題を解決するアルゴリズムを提供します。

たとえば、停止問題は、ほとんどの入力の多項式時間で解決できます（実際、論文を正しく理解していれば、線形時間で）。

ただし、この結果は、3つの副次的な理由により、役に立たないものです。まず、実際のコンピューター上の実際のコンピュータープログラムではなく、1本のテープでチューリングマシンについて説明します。私の知る限り、実世界のコンピューターに同じことが当てはまるかどうかは誰も知りません（実世界のコンピューターはチューリングマシンと同じ機能を計算できるかもしれませんが、許可されるプログラムの数、その長さ、停止するかどうかは全然違う）。

第二に、「ほとんどの入力」が意味するものに注意する必要があります。これは、「長さ」nのランダムプログラムがこのアルゴリズムでチェックできる確率は、nが無限大になると1になる傾向があることを意味します。言い換えれば、nが十分に大きい場合、長さnのランダムプログラムはこのアルゴリズムによってほぼ確実にチェックできます。

論文に記載されているアプローチでチェックできるプログラムはどれですか？基本的に、状態を繰り返す前に停止するすべてのプログラム（「状態」はプログラム内のコード行にほぼ対応します）。

ほぼすべてのプログラムをこの方法でチェックできますが、この方法でチェックできるプログラムはどれも非常に興味深いものではなく、通常は人間が設計するものではないため、実用的な価値はまったくありません。

また、ほとんどすべての興味深いプログラムは（明らかに）チェックするのが難しいため、一般的なケースの複雑さはおそらく停止問題の解決に役立たないことを示しています。または、別の言い方をすれば、ほとんどすべてのプログラムは面白くないが、確認は簡単です。

実際には、他の問題のために停止する問題を常に解決するプログラムがあります。これらは、コンピューターを実行しているオペレーティングシステムの一部です。決定不能性は、他のすべてのプログラムで機能するようなプログラムは存在しないというだけの奇妙な主張です。

ある人は、停止している証明は、ミラーのように無限にトレースするため、解決できない唯一のプログラムであると正しく述べています。この同じ人は、停止するマシンがあれば、ソルバーのアルゴリズムが停止するかどうかを事前に伝えることで難しい数学の問題を教えてくれるので、魔法になると述べています。

これらの両方の場合の仮定は、トレースする証拠がないため、停止しているマシンがトレースしないことです。ただし、実際には、指定された入力で実行されるプログラムを実際にトレース/実行します。

少なくとも論理的な証明は簡単です。少なくとも最初のステップをトレースする必要がなければ、実行するプログラムと一緒に入力する必要はありません。情報を利用するには、少なくとも最初のステップをトレースしてから、そのパスの行き先を分析しなければなりません。

一番上の回答で言及された難しい数学の問題は、早急に答えを見つけられない問題です。つまり、停止している問題は、何らかのパターンが認識できるまでトレースを続けなければなりません。

したがって、停止する問題から取得する唯一の実用的な議論は、停止するマシンが最適化された問題ソルバーの結果を、問題ソルバーが終了するよりも早く決定できないということです。

この推論の正式な証明を与えることはより困難であり、学者だと説明しようとすると、彼らはかんしゃくのような猿を投げ、シャンデリアから揺れ動くことになります。それらの人々と議論しないことが最善です。

これが答えです、はい、1967年にhttp://www.isp.uni-luebeck.de/kps07/files/papers/kirner.pdfから遡ります

有限状態システムの停止問題は少なくとも理論的に解決できることは、1967年にミンスキーによって既に議論されています[4]：「...有限状態のマシンは、完全に放置されると、最終的に完全に周期的になり繰り返しパターン。この繰り返しパターンの期間は、マシンの内部状態の数を超えることはできません...」

（したがって、有限チューリングマシンに固執する場合は、オラクルを構築できます）

もちろん、これにかかる時間は別の質問です

停止した場合に判断できるプログラムのサブセットはありますか？

はい。

ほとんどのプログラムで十分ですか？

「ほとんど」を定義します。

プログラムの「停止可能性」を判別できる一連の言語構成体を作成できますか？

はい。

チューリングがほぼ完了しているなど、十分なものはありますか？

「ほぼ」を定義します。

多くの人は、whileステートメントや再帰を使用せずにPythonを書きます。

多くの人々は、終了することが簡単に証明できる単純なイテレーターまたはカウンターを含むforステートメントのみを使用してJavaを記述します。そして、彼らは再帰なしで書き込みます。

回避whileと再帰は非常に簡単です。

すべての入力が制限されている特定のプログラムについて、プログラムが停止するかどうかを判断できますか？

いや

その場合、言語の制約は何であり、入力セットの制限は何ですか。

あの 停止の問題は、プログラムがそれ自体ほど複雑なプログラムについて物事を判断できないことを意味します。多数の制約のいずれかを追加して、停止する問題を乗り越えることができます。

停止する問題への標準的なアプローチは、プログラミング言語で利用できるよりもわずかに「豊富な」数学的形式のセットを使用して証明を許可することです。

言語を制限するよりも証明システムを拡張する方が簡単です。制限があると、制限のために表現するのが困難な1つのアルゴリズムの引数になります。

これらの構成体の最大セットは、停止するかしないかを推測できる言語を決定します。これについて行われた研究はありますか？

はい。「グループ理論」と呼ばれます。一連の操作の下で閉じられる一連の値。かなりよく理解されているもの。