プルーフチェッカーのバグがメジャープルーフを無効にしたことはありますか?


29

ほとんどの(すべて?)証明アシスタントの健全性のバグはときどき修正されます。しかし、私が見た人たちからは、これらのバグは通常、意図せずに遭遇するのが難しく、バグが修正される前に結果が証明されたのは、一般に修正後です。

強さの順に3つの質問:

  1. そのような健全性のバグ修正により、プルーフを変更せずに、主要なプルーフが失敗することがありましたか?
  2. (1)が当てはまる場合、プルーフを修正するために大きな修正が必要でしたか?
  3. (2)が当てはまる場合、健全性のバグにより、間違った主要定理を証明した人はいますか?

「メジャー」の定義は他の人に任せます。


11
これはおそらく私の無知を示​​していますが、証明アシスタントで初めて主要な定理が確立されたことがありますか?もちろん、4色の定理とケプラー予想については知っていますが、そこでの最初の証明は証明アシスタントを使用したとは思いません。気になります。
サショニコロフ

1
CompCertまでは、コンパイラが正しいことを証明した人間はいなかったと思います。しかし、これは(3)を特に面白くない質問にすることになるということです。
ジェフリーアーヴィング

4
@SashoNikolov:実際には証明アシスタントによって行われる証明のほとんどは数学に関するものではないため、それはあまり意味がありません。それらは通常、ソフトウェアシステム、または正式なシステムの特性などに関するものです(この惑星で行われた証明の大部分が純粋な数学に関するものではないのは時間の問題です。ロボットがやってくるのです)。たとえば、重要なシステムが安全であることを証明アシスタントを使用して誰かが証明した場合、その後、不整合を誤って使用したことが判明しました。
アンドレイバウアー

1
@AndrejBauerに感謝します。それでは、ここでの「主要な証明」と「主要な定理」は、研究数学者にとっては重要ではなく、重要な重要なシステムの正確さの証明を意味するのでしょうか?
サショニコロフ

1
十分に多くの人々(数学者、セキュリティの専門家、ソフトウェアエンジニア)によって重要であると考えられる証拠はすべて考慮されると思います。誰かこの問題に出くわした場合、彼らが静かにそれを修正する可能性があるので、私たちは見つけようとしていないと思います。
アンドレイバウアー

回答:


11

私の知る限り、複雑な数学的展開のマシンチェックされた証拠は撤回されていません。

Andrejが指摘しているように、これらのシステムで健全性を損なうバグが発生することが時々あります(通常は静かにではありませんが、Andrejが示唆するように、でが)。関連する証明システムの標準ライブラリ。

Coqでのそのようなライブラリー破壊証明の例:

https://coq.inria.fr/bugs/show_bug.cgi?id=4294

https://sympa.inria.fr/sympa/arc/coq-club/2013-12/msg00119.html

確立された証明が依存していたかどうかを言うのは難しい修正後、証明チェッカーによる微調整を受け入れる必要があるためが不整合にしてたです。ただし、これは重要な更新のたびに発生します!

私の個人的な意見では、機械の形式化を試みる前に紙の証拠を十分に磨く必要があるため、このような間違いは起こりそうにありません。

証明フレームワークの不整合は、通常、難解な機能の奇妙な組み合わせを頻繁に使用する必要があるため、「偶発的に」発生することはほとんどありません。


3
ジェフレイが指摘したように、プルーフアシスタントのバグへの反応として、プルーフスクリプトの問題を黙って、または知らないうちに修正する人々について言及していました。もちろん、証明アシスタントの不整合は常に驚くべきレベルの興奮で受け取られます。数学者は数学の矛盾を抱えているべきであり、それは興味深い数ヶ月になります。
アンドレイバウアー

2
私にウィキペディアのリンクを投げている人とは何ですか?@RickyDemer、ご意見をお聞かせください。ラッセルのパラドックスのことを聞いたことがあります。それは100年以上前のことであり、優れた数学をもたらしました。私たちは別のものを熟させることを提案しています。
アンドレイバウアー

今のところこの答えを受け入れますが、もちろん誰かが反対方向に答えた場合は受け入れません!(完全な開示:これは私が望んでいた答えでした。)
ジェフリーアーヴィング

1
@GeoffreyIrving答えはやや不満です。なぜなら、私が撤回の欠如を証明するのは難しいからです!したがって、答えは私の知識の不足にある程度基づいていますが、非常に大規模な機械の形式化はほとんど行われていないので、少なくとも少し自信を持って回答できます。私はまた、いくつかの重要な形式化することを聞いたB方式は ...あなたは非自明なステートメントのために多くの公理を追加する必要があります(一貫性のない仮定を有することが示されている、と一緒になっ公理のコレクションは、その後であることが示された
コーディ

1
...不整合)。残念ながら、私はそのための参照を見つけることができないようですので、答えにそれを含めませんでした。また、形式化は大規模なプログラムに関するものであり、純粋な数学に関するものではありませんでした。
コーディ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.