π 計算專案介紹

new research work flow

CodingCoffee

2026年5月1日 上午 8:16

預設類別

π 計算專案介紹(https://gitlab.com/chiyanglin/pi_calculation_experiment)

概述

此專案透過一種新穎的雙 LLM 工作流程，探索以高精度計算數學常數 π（圓周率）。一個大型語言模型（LLM）擔任 開發代理人，負責實作與改進計算程式碼；另一個 LLM 擔任 審查代理人，提出演算法改進、驗證正確性，並認證效能提升。

動機

本計畫受到利用 AI 代理人協同改進科學軟體的想法啟發。透過將開發與審視流程視為兩個獨立的 LLM 代理人，我們希望能：

  • 透過快速的提案‑實作循環加速演算法創新。

  • 透過自動化驗證與基準測試維持嚴格的品質控管。

  • 發揮不同 LLM 的長處（例如一者在程式產生方面較強，另一者在分析推理方面較強）。

目前實作

  • 開發 LLM：ollama:gemma4 – 產生 Python 程式碼以計算 π。

  • 審評 LLM：ollama:nemotron-3-super:cloud – 分析提案、檢查正確性，並驗證效能改善。

  • 基準演算法：Machin 類公式（初始版本）。

  • 目前狀態：專案已經歷數次迭代：

    1. v01 – 切換至 Chudnovsky 級數，實現約 4.4 倍的加速。

    2. v02 – 引入 gmpy2 進行多精度整數運算，相較於 v01 再提升約 68%。

    3. v03 – 嘗試純 Python 多核心二分劃分（使用 multiprocessing），因額外開銷而變慢。

    4. v04 – 嘗試使用 Cython 加速；目前正在修正類型相關問題。

    5. 未來 – 探索帶有 gmpy2 的迭代二分劃分（提案 v04），以減少函式呼叫開銷。

所有版本在經評審代理人確認達到 ≥10% 效能提升且保持數值正確性後，會以十六進位版本號（v01、v02…）在 Git 中加 tag。

工作流程

  1. 提案階段 – 審查代理人撰寫提案檔案（proposal_vxx.md），描述新演算法或最佳化、預期加速度、參考文獻與所需環境變更。

  2. 開發階段 – 開發代理人依照提案實作程式，更新主要計算腳本，並透過與可信來源比較確認正確性。

  3. 基準測試 – 使用專門的基準腳本（通常在 5000+ 位數上）測量舊版與新版的平均執行時間。

  4. 驗證 – 若新版展現至少 10% 的改進並通過正確性檢查，則該變更會被提交、加 tag，並記錄於 version_history.md 與 README.md。

  5. 文件 – 維持 README、版本歷史與提案檔案的英文與繁體中文雙語版本。

存儲結構

  • main.py – 目前最佳實作（v02：Chudnovsky + gmpy2 + 二分劃分）。

  • proposal_vxx.md / proposal_vxx_zh.md – 各版本的提案。

  • version_history.md / version_history_zh.md – 變更的時間順序記錄。

  • README.md / README_zh.md – 專案概覽、使用方式與版本控制政策。

  • 基準腳本（benchmark_v02.py、benchmark_v03.py …） – 用於跨版本效能比較。

  • 輔助檔案（例如 background.md） – 說明數學背景。

如何貢獻

若您希望提出改進：

  1. Fork 此儲存庫。

  2. 依照最新 proposal_vxx.md 的範本草擬新提案。

  3. 提出 pull request；審查代理人（或人類維護者）會評估提案。

  4. 獲准後，實作變更、執行基準測試，並更新文件。

  5. 符合 ≥10% 準則時，該版本會被加 tag 並發布。

未來方向

  • GPU 加速：利用主機的 NVIDIA RTX 5060 筆電 GPU（CUDA 運算能力 12.0），透過 CuPy、Numba 或自訂 CUDA 核心來加速 Chudnovsky 級數中耗時的乘法運算。

  • 其他公式：探索 Bellard、Ramanujan‑Sato 或 BBP 風格的公式，以尋找更多平行化機會。

  • 更進階的 LLM 合作：實驗角色互換或更複雜的代理人間反饋迴路。

  • 自動化發布：使用 GitHub Actions 在每次推送時執行基準測試，並在符合條件時自動加 tag 發佈。

參考文獻

  1. Crandall, R., & Pomerance, C. (2005). Prime Numbers: A Computational Perspective, 2nd ed., §9.3 (Binary Splitting). Springer.

  2. Chudnovsky, D. V., & Chudnovsky, G. V. (1989). “The Computation of Classical Constants.” Proceedings of the National Academy of Sciences, 86(21), 8178‑8182.

  3. Y. Hida, X. S. Li, and D. H. Bailey, “Library for Double‑Double and Quad‑Double Arithmetic,” https://developers.sun.com/sunstudio/products/archive/libs/x9libqd.html.

  4. GMPY2 documentation: https://github.com/aleaxit/gmpy

  5. Ollama models: https://ollama.com/

Introduction to the Pi Calculation Project(https://gitlab.com/chiyanglin/pi_calculation_experiment)

Overview

This project(https://gitlab.com/chiyanglin/pi_calculation_experiment) explores the calculation of the mathematical constant π (pi) to high precision using a novel dual‑LLM workflow. One large language model (LLM) acts as the development agent, responsible for implementing and refining the calculation code. A second LLM serves as the review agent, proposing algorithmic improvements, verifying correctness, and certifying performance gains.

Motivation

The project is inspired by the idea of using AI agents to collaboratively improve scientific software. By treating the development and review processes as separate LLM agents, we aim to:

  • Accelerate algorithmic innovation through rapid proposal‑implementation cycles.

  • Maintain rigorous quality control via automated verification and benchmarking.

  • Leverage the strengths of different LLMs (e.g., one strong at code generation, another at analytical reasoning).

Current Implementation

  • Development LLM: ollama:gemma4 – generates Python code for π calculation.

  • Review LLM: ollama:nemotron-3-super:cloud – analyses proposals, checks correctness, and validates performance improvements.

  • Baseline algorithm: Machin‑like formula (initial version).

  • Current state: The project has progressed through several iterations:

    1. v01 – Switched to the Chudnovsky series, achieving ~4.4× speed‑up.

    2. v02 – Integrated gmpy2 for multiprecision integers, adding another ~68% speed‑up over v01.

    3. v03 – Experimented with pure‑Python parallel binary splitting (multiprocessing), which proved slower due to overhead.

    4. v04 – Attempted a Cython acceleration; currently fixing type‑related issues.

    5. Upcoming – Iterative binary splitting with gmpy2 (proposal v04) to reduce function‑call overhead.

All versions are tagged in Git using hexadecimal version numbers (v01, v02, …) once the review agent confirms a ≥10% performance gain while preserving numerical correctness.

Workflow

  1. Proposal Phase – The review agent drafts a proposal (proposal_vxx.md) describing a new algorithm or optimisation, expected speed‑up, references, and any required environment changes.

  2. Development Phase – The development agent implements the proposal, updates the main calculation script, and ensures correctness by comparing output with a trusted reference.

  3. Benchmarking – A dedicated benchmark script runs both the previous and new versions (typically at 5000+ digits) to measure average runtime.

  4. Verification – If the new version shows at least 10% improvement and passes correctness checks, the change is committed, tagged, and documented in version_history.md and README.md.

  5. Documentation – Both English and Traditional Chinese versions of the README, version history, and proposal files are maintained.

Repository Structure

  • main.py – Current best implementation (v02: Chudnovsky + gmpy2 + binary splitting).

  • proposal_vxx.md / proposal_vxx_zh.md – Proposals for each version.

  • version_history.md / version_history_zh.md – Chronological log of changes.

  • README.md / README_zh.md – Project overview, usage, and versioning policy.

  • Benchmark scripts (benchmark_v02.py, benchmark_v03.py, …) – Compare performance across versions.

  • Auxiliary files (e.g., background.md) – Explain the mathematical background.

How to Contribute

If you wish to propose an improvement:

  1. Fork the repository.

  2. Draft a new proposal following the template in the latest proposal_vxx.md.

  3. Open a pull request; the review agent (or human maintainer) will assess the proposal.

  4. Upon approval, implement the change, run the benchmark, and update documentation.

  5. The release will be tagged and versioned once the ≥10% criterion is met.

Future Directions

  • GPU Acceleration: Leverage the host’s NVIDIA RTX 5060 Laptop (CUDA compute capability 12.0) via CuPy, Numba, or custom CUDA kernels to speed up the expensive multiplications in the Chudnovsky series.

  • Alternative Formulas: Investigate the Bellard, Ramanujan‑Sato, or BBP‑style formulas for potential parallelism.

  • Further LLM Cooperation: Explore role‑swapping or more sophisticated feedback loops between the agents.

  • Automated Release: Use GitHub Actions to run benchmarks on push and automatically tag releases when criteria are satisfied.

References

  1. Crandall, R., & Pomerance, C. (2005). Prime Numbers: A Computational Perspective, 2nd ed., §9.3 (Binary Splitting). Springer.

  2. Chudnovsky, D. V., & Chudnovsky, G. V. (1989). “The Computation of Classical Constants.” Proceedings of the National Academy of Sciences, 86(21), 8178‑8182.

  3. Y. Hida, X. S. Li, and D. H. Bailey, “Library for Double‑Double and Quad‑Double Arithmetic,” https://developers.sun.com/sunstudio/products/archive/libs/x9libqd.html.

  4. GMPY2 documentation: https://github.com/aleaxit/gmpy

  5. Ollama models: https://ollama.com/