How to do Math in programming

**デフォルトの名無しさん** · 2024/03/21(木) 09:41:43.97

What is "mathematics in programming?"

Some well-known facts in mathematics are difficult to prove using a computer.
For example, the Leibniz series

1 - 1/3 + 1/5 - 1/7 + ...

is exactly equal to π/4, but calculating this series directly is impossible because it requires infinite computation.
However, from the theorems of analysis, this equality can be shown. Thus, if all these theorems are formulated in terms of logic symbols, the proof is reduced to a finite algorithm.

Some might say that a "proof assistant" or "theorem prover" would make this possible.
However, the language of proof assistants is too complicated to describe proofs of non-fundamental theorems, so proof assistants are used only to check proofs that have already been solved.
This is far from doing mathematics.

My question is where do mathematical ideas come from and whether programming can help yield them?

**デフォルトの名無しさん** · 2024/03/21(木) 10:47:44.36

fuck your asshole

**デフォルトの名無しさん** · 2024/03/21(木) 11:56:07.97

Theorem Proving in Lean 4　日本語訳
https://aconite-ac.github.io/theorem_proving_in_lean4_ja/title_page.html

定理証明なら、今はCoqよりこっちなんかな

**デフォルトの名無しさん** · 2024/03/21(木) 12:07:26.54

依存型を使った定理証明入門

https://zenn.dev/blackenedgold/books/introduction-to-idris/viewer/theorem-prooving

定理証明の流れは

命題を型に変換する
型がnon-emptyであることを示す

なので、実行時に型チェックすれば動的型付け言語でも証明はできるわけか
ただ、全称型とか存在型とかをどうやって表すのかがわからない

**デフォルトの名無しさん** · 2024/03/21(木) 23:49:19.66

より直感的なシンタックスと、命題のインタフェースを簡単に変換できる機能がほしいな

**デフォルトの名無しさん** · 2024/03/23(土) 09:58:52.52

命題 → 型

偽 → ∅
not A → Hom(A, ∅)
真→ not ∅

AかつB → 直積A×B
AまたはB → 直和A⊕B

AならばB
= not A または B
= (not A)⊕B
= Hom(A, ∅)⊕B
～ Hom(A, B)　※ 真偽が一致する

**デフォルトの名無しさん** · 2024/03/24(日) 22:31:53.90

プログラムはバイト列にコンパイルされるから、すべてのプログラムは高々可算個になるのだが、なぜ非可算集合をふくむ論理を扱えるんだ？

**デフォルトの名無しさん** · 2024/03/24(日) 23:10:41.69

量化してるからだよ

**デフォルトの名無しさん** · 2024/03/25(月) 00:03:34.00

数学者だって、自分の専門分野の数学をすべて論理学と集合論の公理から演繹したわけじゃないだろう
すでに理解したことやよく知られた事実は認めて問題を解いているはずだ

そういう柔軟性がほしい
つまり、認めてもいい仮説はその場その場で手軽に導入できるような言語設計がいい
その上で、そこから機械的に導けることの証明や、定義から直接わかる具体例の計算などを半自動でしてほしい

もちろん、コンピュータにやらせる以上、曖昧さのない構文は必要だろうが

def continuous_at(f: Real -> Real, a: Dom(f)) = forall({e: Real | e > 0},
exists({d: Real | d > 0},
forall({x: Dom(f)},
implies(abs(x - a) < d, abs(f(x) - f(a)) < e)
)
)
)

これよりもさらに手短に、見た目ももっと見易く

**デフォルトの名無しさん** · 2024/03/25(月) 01:17:03.24

たとえば>>9のcomtinuous_atなんかも、一度書いたはいいけど実際に使うとなると、使うたびに、fの定義域が実数全体じゃない場合みたいな微妙な調整が必要になるんだよね

人間が考えたら時間がかかるような部分をコンピュータに助けてほしいのに、どうしても「知りたいのはそこじゃない」って部分に時間をかけなきゃいけない

**デフォルトの名無しさん** · 2024/03/25(月) 08:46:28.85

かと言って最初から一般的に対応しようとすると、典型的なケースで必要以上に多くの記述をしなきゃならんだろうね

**デフォルトの名無しさん** · 2024/03/25(月) 08:59:06.31

継承とかいう欠陥だらけのサブタイピングのしくみは、証明に置き換わってもいい

つまり、厳密にis aであることを証明しなければ継承できない
　＆ポリモーフィックな関数は型の共通部分で動作が一致することを証明しなければ定義できない

そうすれば誰も使わなくなるか、使える能力のある奴だけが使うようになる

**デフォルトの名無しさん** · 2024/03/25(月) 11:24:25.60

>>9
量化した変数や条件式の評価は遅延させなきゃいかんから、コールバック地獄みたいになるのね

**デフォルトの名無しさん** · 2024/03/25(月) 18:53:28.86

証明を書き下すのが手間なのもあるが、数学のオブジェクトをプログラムで扱えるよう定義するのも相当手間だろうね

行列式→行列式を計算するのは簡単だが、置換を使って定義するのはめんどくさそう。置換群を先に定義しなければならない

リーマン積分→区間幅の最大値が0に収束するようなリーマン和の列すべてを考えなければいけない。

商空間で辺に沿って同一視した曲面とかもめんどくさそう。