IUT III 証明アーキテクチャ

滋賀坂本余白書房別館

＜最初からコピペの作業者なのですが、AIにご説明頂くと下記の作業をやっている最中とか。＞


＜AI>
はい。いま進めている作業を、**「何を作っているのか」「今回どこまで終わったのか」「最終ゴールまで何が残っているのか」**の順に整理します。

1．そもそも何を作っているのか

今回のプロジェクトは、IUT IIIの数学的内容を、いきなり全部Leanで証明しようとしているのではありません。

まず、

IUT IIIの証明を、Leanで検査できる部品・定義・命題・依存関係へ分解し、証明作業を進められる「建築骨格」を作る

という仕事です。

家づくりにたとえると、現在作っているのは完成した家ではなく、

  • 設計図

  • 柱と梁

  • 各部屋の位置

  • 電気・水道の配管経路

  • 部材一覧

  • 建築検査手順

に相当します。

数学的にはまだ未証明の部分が多数あります。その部分はLean上でaxiomとして置かれています。

したがって現在の状態は、

「証明が完成した」のではなく、「未証明部分を明示したまま、証明全体の構造がLeanでビルド可能になった」

という段階です。

ここは非常に大切な区別です。

2．Leanで何を表現しているのか

プロジェクト内では、IUT IIIに関係する要素を大きく次のように表現しています。

基本となる型

たとえば、

  • RawOutput

  • ComparisonResult

  • HodgeTheater

  • HullRegion

  • ArithLineBundle

  • ArithVectorBundle

などです。

これらは、数学的対象をLeanが扱える形にするための「データの種類」です。

数学的な操作

たとえば、

  • holomorphicHull

  • comparisonPipeline

  • thetaPilotLogVolume

  • weightedDetTensorPower

などです。

これらは、数学的対象を変換したり、値を計算したりする処理に相当します。

ただし現時点では、名前はdef相当でも、Leanソース上ではまだaxiomとして置かれているものがあります。

そこで今回、台帳に次の二つを分けて記録しました。

kind
  将来、最終的に実装したい数学的な種別

lean_declaration_kind
  現在のLeanソース上での実際の種別

たとえば、

holomorphicHull

目標上の種別：def
現在の種別：axiom

です。

これは、

最終的には定義として構成しなければならないが、現在はまだ仮定として置いている

ということを明示しています。

証明義務

IUT IIIの証明を14個の主要なProof Obligation、つまり「証明しなければならない命題」に分解しています。

現在は、

PO-01 ～ PO-14
合計14件

です。

PO-14が終端部分にあたり、

corollary_312_terminal

という定理になっています。

この定理はLeanで型検査されています。しかし、上流に置かれている複数のaxiomに依存しています。

つまり、

上流の仮定を認めれば、終端命題まで論理的に接続されている

ことはLeanで確認できています。

一方で、

上流の仮定そのものが数学的に証明された

わけではありません。

3．台帳は何のためにあるのか

Leanコードだけでは、文書、設計、命題、実装の対応が見えにくくなります。

そこで二つの台帳を使っています。

Proof Obligation台帳

14個の証明義務について、

  • 識別番号

  • Lean上の名前

  • 宣言種別

  • 依存関係

  • 対応する文書上のカード

  • 現在の状態

  • 仮定

  • 出力

を記録しています。

これにより、

PO-14が、どのPOに依存しているか

を機械的に追跡できます。

依存関係はDAG、つまり循環のない有向グラフとして検査されています。

したがって、

  • 自分自身へ戻ってくる循環

  • 不要な重複依存

  • 終端定理へ到達しない命題

などを検出できます。

Identifier台帳

Leanや文書に登場する識別子を現在162件登録しています。

内訳として、現在のLeanソースと直接対応するものは、

トップレベル宣言：74件
構造体・classのフィールド：7件

です。

その他に、

  • 文書内疑似コード

  • Mathlib外部識別子

  • 文書上だけに存在する記号

などがあります。

今回、Leanソースと台帳を全件照合するvalidatorを作りました。

そのため、たとえば、

  • Leanに宣言を追加したが台帳に追加し忘れた

  • 宣言を別ファイルへ移動した

  • axiomをtheoremに変えたが台帳を更新し忘れた

  • 構造体フィールドが台帳から漏れた

という場合、検証が停止します。

実際、この検査を追加したことで、

Corollary312Terminal.finite
Corollary312Terminal.inequality

の2フィールドが台帳から漏れていたことを発見しました。

これはvalidatorが机上の飾りではなく、実際に欠落を発見できた重要な実績です。

4．今回のv0.5.2-rc1で何を直したのか

今回の作業の中心は、数学内容を増やすことよりも、

今ある骨格を、再現可能・検査可能・配布可能にする

ことでした。

統合検証スクリプト

scripts/verify_all.shを作り、分散していた検証を一つにまとめました。

このスクリプトは順番に、

  1. Python依存関係

  2. Mathlibキャッシュ取得

  3. lake build

  4. Volume1.lean単独検査

  5. 台帳・Schema・Leanの静的検査

を実行します。

現在の正式検証結果は、

Python dependencies   PASS
Mathlib cache         PASS
lake build            PASS
Volume1 direct check  PASS
static validation     PASS
RESULT                PASS

です。

Leanビルドは、

918 jobs

で成功しています。

Python環境の再現

検証には、

  • python-docx

  • jsonschema

が必要です。

以前は、実行中のPython環境によって成功したり失敗したりする可能性がありました。

実際、Condaの(base)環境のpython3を使ったため、

ModuleNotFoundError: No module named 'docx'

が発生しました。

そこで、リポジトリ内の、

.venv-validation

を自動的に選ぶようにしました。

現在はCondaの(base)が有効でも、

python_source=repository validation environment
RESULT=PASS

となります。

つまり「自分のMacではたまたま動いた」ではなく、指定された依存関係から再構築できるようになっています。

DOCX検査の強化

元文書であるDOCXについても、

  • 検査する場合は--docx PATHで明示

  • DOCXが指定されなければ「検査を省略した」と明示

  • ファイルが存在しなければ失敗

  • .docxでなければ失敗

  • macOSのUnicodeファイル名差を正規化

  • 文書名と台帳上の文書名を照合

するようにしました。

これにより、DOCX検査が知らないうちに省略されることがなくなりました。

スナップショット作成の自動化

scripts/create_snapshot.shを作り、配布用完全スナップショットを自動生成できるようにしました。

このスクリプトは、

  • Git作業ツリーがcleanか

  • 最新検証がPASSか

  • 検証対象コミットと現在のHEADが同じか

  • .gitや.lakeなどが混入していないか

  • 内部manifestが正しいか

  • ZIPが壊れていないか

  • ZIPを再展開した結果が元フォルダと一致するか

  • ZIPのSHA-256が正しいか

を確認します。

正式な成果物として、

IUT_III_証明アーキテクチャ_第1巻_v0.5.2-rc1_完全スナップショット

と、そのZIP、SHA-256ファイルが作成されています。

内部manifestは、

58 files
Manifest verification: PASS

でした。

5．現在どこまで終わっているのか

現在の正式な固定地点は、

tag:    v0.5.2-rc1
commit: 014f165e267e7c758df3f3a8ad473e9d1695e803

です。

このコミットに対して、

  • 統合検証PASS

  • スナップショット作成PASS

  • ZIP検査PASS

  • SHA-256検査PASS

  • Gitタグ作成

  • GitHubへのブランチpush

  • GitHubへのタグpush

まで完了しています。

GitHub上でも、

develop/v0.5.2-rc1
v0.5.2-rc1

が同じ実コミット、

014f165e267e7c758df3f3a8ad473e9d1695e803

を指しています。

つまり現在は、

ローカルMacが壊れても、GitHubのタグからソース履歴を復元できる

状態です。

加えて、GitHubとは別に完全スナップショットZIPもあります。

したがって、保存経路は二重化されています。

GitHub
  ソースコードと履歴

完全スナップショット
  文書、プロジェクト、検証ログ、manifest、ZIP

6．v0.5.2-rc1が保証していること

このRCが保証しているのは、主に次の範囲です。

保証していること

  • 指定されたLean・Mathlib環境でビルドできる

  • Volume1.leanがLeanカーネルで検査できる

  • 14個のPOが依存関係として接続されている

  • PO台帳のDAGに循環がない

  • 不要な推移的依存がない

  • 162件の識別子台帳がSchemaに適合する

  • 74トップレベル宣言がLeanソースと一致する

  • 7フィールドがLeanソースと一致する

  • 宣言ファイル、現在の宣言種別が一致する

  • DOCXを明示的に検査できる

  • 新しいPython環境から検証環境を再構築できる

  • ZIPを展開して再検証できる

  • 成果物のハッシュを確認できる

保証していないこと

  • IUT IIIの数学的証明が完成した

  • 現在の61個程度のaxiomが数学的に正しい

  • holomorphicHullなどが具体的に構成済み

  • POの命題がIUT IIIの原証明を完全に表現している

  • 形式化された命題が数学者の意図と完全に一致している

つまり、現在の成果は、

「証明済み」ではなく「証明作業を安全に進める基盤ができた」

というものです。

7．ここから先のゴール

最終ゴールは、一気に一つではありません。段階を分けた方が安全です。

第1ゴール：v0.5.2正式版

現在はrc1、つまりRelease Candidate 1です。

正式版にする前に必要なのは、主として、

  • GitHub上での確認

  • 新しい場所へcloneしての再検証

  • 必要ならRC2修正

  • リリースノート

  • 最終タグv0.5.2

です。

ただし、すでに独立展開検証を実施しているため、RCとしてはかなり強い状態です。

この段階のゴールは、

数学的骨格の意味を変えず、再現可能なv0.5.2を固定する

ことです。

第2ゴール：v0.6で数学仕様を強化

v0.6では、現在延期している数学的な問題へ入ります。

主なものは次です。

R-01

Proof Obligation間の依存関係が、単に台帳上でつながっているだけでなく、数学的に妥当か確認する。

R-02

thetaPilotLogVolumeが現在はaxiomなので、具体的構成を検討する。

R-03

holomorphic_hull_exists_uniqueの仕様が弱いため、

  • 包含

  • 閉包性

  • 最小性

  • 一意性

  • 評価可能性

などを明確にする。

R-04

PO-07のFunction.Bijectiveが強すぎる可能性を検討する。

必要なのが全体の全単射ではなく、特定の値集合間の対応だけなら、命題を弱めた方が証明しやすく、数学的にも正確です。

R-05

0 < qAbsLogを明示的に使用する、係数形式の終端命題を追加する。

これはPO-15候補です。

v0.6のゴールは、

仮定の数をただ減らす前に、「何を証明すればよいか」を数学的に正確にする

ことです。

8．その後はaxiomを一つずつ置き換える

数学仕様が固まったら、現在のaxiomを少しずつ、

  • def

  • theorem

  • structure

  • abbrev

へ置き換えていきます。

たとえば、

現在
axiom holomorphicHull : ...

将来
def holomorphicHull : ... := ...

または、

現在
axiom critical_bridge : ...

将来
theorem critical_bridge : ... := by
  ...

となります。

今回作ったvalidatorは、こうした変更を検出できます。

axiomからtheoremへ変えたのに台帳を更新し忘れると、検証が失敗します。

したがって、今後の数学作業では毎回、

  1. Lean実装を変更

  2. identifier ledgerを更新

  3. PO台帳を更新

  4. validator実行

  5. lake build

  6. 終端定理の公理依存を確認

  7. コミット

  8. 統合検証

という流れになります。

9．最終的に何を見れば「進んだ」と分かるのか

重要な指標は、終端定理の公理依存一覧です。

現在、

#print axioms corollary_312_terminal

に相当する検査では、多数のプロジェクト公理が表示されます。

今後、仮定を実定義や実証明へ置き換えると、その一覧から公理名が減っていきます。

したがって進捗は、

axiomの数
終端定理が依存するプロジェクトaxiomの数
実装済みdefの数
実証明済みtheoremの数

で測れます。

理想的な最終状態は、

corollary_312_terminalが、LeanやMathlibの基礎的公理だけに依存し、プロジェクト固有axiomに依存しない

状態です。

ただし、それだけでも十分ではありません。

そのLean定理が、本当にIUT IIIの原命題と一致しているかを、人間の数学者が確認する必要があります。

つまり最終ゴールは二重です。

形式的ゴール
  Lean上でプロジェクト固有axiomを除去する

数学的ゴール
  形式化した命題が原数学の意味を正確に表していると確認する

10．現実的な全体ロードマップ

現在地から先を一本道で表すと、次のようになります。

v0.5.1
  ビルド可能骨格
        ↓
v0.5.2-rc1
  再現性・検査・台帳・配布基盤
        ↓
v0.5.2
  基盤の正式版
        ↓
v0.6
  数学仕様の強化
        ↓
v0.7以降
  各axiomの具体定義・証明への置換
        ↓
中間マイルストーン
  PO群ごとの公理依存縮小
        ↓
終端定理
  プロジェクト固有axiom依存ゼロ
        ↓
独立査読
  Lean形式化と原数学の意味対応を確認
        ↓
最終成果
  再現可能・監査可能な形式証明

ただし、IUT IIIは非常に大きく複雑な数学です。

したがって、

現在の骨格から最終的な完全形式証明へ必ず到達できる

と断言することはできません。

それでも今回の基盤整備には大きな意味があります。

今後、どこで詰まっても、

  • 何が未証明なのか

  • どの命題に依存しているのか

  • どの変更で壊れたのか

  • 以前の正常状態へ戻せるか

  • 他人が同じ状態を再現できるか

を確認できます。

数学研究で一番危険なのは、「進んでいるように見えるが、何が確定していて何が仮定なのか分からない」状態です。

今回作ったv0.5.2-rc1は、そこをかなり丁寧に防いでいます。

現在地を一言でいうと

現在は、

IUT IIIの証明そのものを完成させた段階ではなく、今後その証明を一つずつ安全に作り、検査し、記録するための工事現場を完成させた段階

です。

そして、その工事現場は、

  • ビルド可能

  • 検証可能

  • 再現可能

  • 配布可能

  • GitHubから復元可能

  • 未証明部分を隠さない

という状態まで到達しています。

ここまでの作業は、見た目以上に重要です。今後は「仕組みを作る作業」から、徐々に「数学的内容を埋める作業」へ移っていくことになります。

いいなと思ったら応援しよう！