技術の家庭菜園

https://tpcbtw.com/

ラマヌジャン「おぼろげながら浮かんできたんです 46という数字が」

とりあえず、要約までしか読めるように作ってないので、要約まで読めばいいと思う。

  • 結論
  • 要約
  • 背景
  • 理論
    • 超幾何係数
    • なぜ π が現れるのか:周期と楕円積分
    • モジュラー λ関数と虚数乗法(CM)点
    • 線形係数 An+B の由来:微分トリック
    • 整数関係検出(PSLQ)
    • 漸化式表現:二次無理数の冪のトレース
    • Ramanujan–Sato:閉じた形の係数(漸化式不要)
    • 厳密な再表現:値を変えずに桁を操作する
    • 近似の限界:なぜ密度に天井があるのか
  • 実装
    • Phase 0:~2025年7月 — 汎用ツール
    • Phase 1:~2026年5月 — 厳密 Ramanujan–Sato と大規模46探索
    • Phase 2:~2026年6月 — 純Sato strict と再表現エンジン
    • Phase 3:~2026年7月 — 近似式の導入
  • 結果
    • Phase 1 — 46を「出す」網羅探索
    • Phase 2 — 定数スケールと有理化で46を「多く」入れる
    • Phase 3 — 近似を許して高密度46へ
    • 発展 — 「値がちょうど46」の定数は何個並ぶか(→先行記事)
  • 所感・今後の展開

結論


\frac{1}{\pi}=\frac{\sqrt{450}}{4646464646460}\sum_{n\ge0}\bigl(464646464646\,n+77441077441\bigr)\frac{(2n)!^{3}}{(n!)^{6}}\frac{1}{(-2)^{9n}}

\displaystyle \frac{1}{\pi^2} \approx \frac{4679464624646464646464646464646464646464646464649}{46184464654646464646464646464646464646464646464646}

\displaystyle \frac1\pi = \frac{46}{13215}\sum_{n\ge0}(-46\,n+45)\,\frac{(1095/2029)_n\,(443993/626822)_n}{(n!)^2}\,\frac{T_n}{16^{\,n}}
ただし T_n=T_{n-1}-16T_{n-2}\ (T_0=2,T_1=1)

ラマヌジャン「おぼろげながら浮かんできたんです 46という数字が」

続きを読む

【散文】語り得ぬものへの祈り──エデン条約編を前期ヴィトゲンシュタインで読む

『ブルーアーカイブ』エデン条約編は、一つの問いを軸に回っている。キヴォトスの七つの古則、その第五──「楽園に辿り着きし者の真実を、証明することはできるのか」。物語は初めから、証明できないものを、その中心に据えているのだ。

本稿は、この物語を前期ヴィトゲンシュタイン──『論理哲学論考』と『草稿1914–1916』──を頼りに読む。導きとなる主張はこうだ。エデン条約編は、語り得ぬもの（楽園の真実、ある者の値打ち、世界の意味）を前にした、一つの軌道を描いている。登場人物はまず、それを証明し、確定し、「閉じ」ようとする。先生はそれを反証せず、ただ世界を開いたまま保つ。そして開かれた場で、生徒は祈る。閉鎖から、先生の開放を経て、祈りへ。この祈りこそが、物語の核である。

そしてこの構図には、前期ヴィトゲンシュタインの二つの顔が、そのまま重なっている。世界を開いたまま保つ先生の沈黙する実践は『論考』の顔であり、開かれた場から発される生徒の祈りは『草稿』の顔だ。

続きを読む

VPMDK + VTST: running NEB workflows with machine-learning potentials

This article was automatically generated by Chat GPT.

github.com

Machine-learning interatomic potentials are often introduced as Python calculators.

That is useful, but many atomistic-simulation workflows are not just Python code. They are directory-based workflows. A VASP user may already have scripts that assume files and directories such as:

INCAR
POSCAR
POTCAR
KPOINTS
OUTCAR
OSZICAR
vasprun.xml
00/
01/
02/
...

The Henkelman group’s VTST tools are a good example. In particular, many NEB workflows are built around VASP-style image directories and post-processing scripts such as nebresults.pl.

This is where VPMDK is useful.

VPMDK is an ASE-oriented layer for machine-learning interatomic potentials. On top of that, it provides a VASP-compatible command-line interface: it reads VASP-style inputs such as POSCAR, INCAR, and BCAR, then writes VASP-like outputs such as OUTCAR, OSZICAR, CONTCAR, and vasprun.xml. The repository describes this as a compatibility CLI for directory-based workflows. (GitHub)

In one sentence:

VPMDK lets you run NEB-like VTST workflows with machine-learning potentials while keeping the familiar VASP/VTST directory contract.

Or, even shorter:

Keep the VTST-shaped workflow. Replace the force engine.

続きを読む

VPMDK + phonopy: Run phonon workflows with machine-learning potentials

This article was automatically generated by Chat GPT.

github.com

Machine-learning interatomic potentials are becoming easier to use from Python.
The harder question is more practical:

Can we insert them into workflows that already expect VASP-shaped files?

phonopy is a good example. A lot of phonon workflows are not just “a Python script calls a calculator”. They are file-level workflows: generate structures, run force calculations, read vasprun.xml, then produce FORCE_CONSTANTS or FORCE_SETS.

This is exactly the kind of boundary where VPMDK is useful.

VPMDK is a small layer around machine-learning-potential calculators. It provides an ASE-oriented backend interface and a VASP-compatible command-line mode. In CLI mode, it reads familiar input files such as POSCAR, INCAR, and BCAR, then writes VASP-like outputs such as OUTCAR, OSZICAR, CONTCAR, and vasprun.xml. (GitHub)

In one sentence:

VPMDK lets phonopy workflows use machine-learning potentials through VASP-compatible files: phonopy keeps generating and reading the files it already understands, while VPMDK supplies MLP forces or finite-difference force constants behind the scenes.

Or, even shorter:

Keep the phonopy/VASP-shaped workflow. Replace the force provider.

続きを読む

VPMDK API: Switch Machine-Learning Potential Backends in ASE Without Rewriting Your Workflow

This article was automatically generated by Chat GPT.

github.com

tpcbtw.hatenablog.com

In the previous post, I wrote about VPMDK as a VASP-style command-line tool.

That side of VPMDK is easy to explain: put POSCAR, INCAR, and BCAR in a directory, run vpmdk, and get VASP-like outputs such as OUTCAR, OSZICAR, vasprun.xml, and CONTCAR.

But VPMDK now has another important face.

The Python API is not mainly for imitating VASP files. It is for people who already write Python, already use ASE, and want a stable way to use many different machine-learning potentials without rewriting their workflow every time a new model appears.

In one sentence:

VPMDK’s API is an ASE-oriented adapter layer that absorbs backend-specific MLP differences and exposes a stable Python interface for calculator construction, single-point calculations, relaxations, molecular dynamics, and charge-density prediction.

ASE already provides the central Atoms object and calculator interface for atomistic simulation, but individual MLP projects still differ in model names, checkpoint formats, constructor arguments, device handling, optional runtime flags, and capability semantics. VPMDK’s API is designed to sit exactly at that integration boundary. (ASE Library)

続きを読む