タイトルにある Feynman point ちうのは、円周率の一部に 9 が連続する箇所があり、それが何故か Feynman point と呼ばれているとの話であります。
ref. ファインマン・ポイント - Wikipedia
https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%B3%E3%83%9E%E3%83%B3%E3%83%BB%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88
円周率の小数点以下 762桁から "999999" が現れるとの事。
そういや、CASIO の Topics ページに、以下の記事がありました。
ref. 小学3年生の小原さん 関数電卓でPythonを動かす「シン・電卓アート」を制作 - CASIO Topics
https://www.casio.co.jp/topics/article/2024/K-055/
python で script を組んで、円周率 1000桁を憶えようとしている小学3年生の記事であります。
時代はここまで進んでおりました。マイッタ。
過去に、100円ショップの電卓をいじって興じている幼児をみて「電卓で遊ぶ幼児は理学者の夢を見るか」というネタを書いた憶えがあるのですが、現実はもっと進んでいたという次第。
25歳の頃「円周率を憶えるゾ !」と頑張ってはみたものの、16桁程度で満足してしまったバカチンの当方としては、オツムの体操と称して、円周率を求める script を使って遊んでみたのですが、その辺りの話を書いておきますヨ。
円周率を計算する upython script は以下の様であります。(実は再掲)
def machin(n):これを使うと、(原理的には)所望の桁数分、円周率を計算をしてくれるのですが、実際には丸め誤差があるので、余裕をみて計算桁を指定するのがよいです。
sm=0
term_1=10**n//5
term_2=10**n//239
flg=0
for j in range(n):
dv=1+2*j
if flg==0:
sm+=term_1//dv*4
sm-=term_2//dv
term_1=term_1//5//5
term_2=term_2//239//239
else:
sm-=term_1//dv*4
sm+=term_2//dv
term_1=term_1//5//5
term_2=term_2//239//239
flg=1-flg
return (sm*4)
例えば 500桁を計算するならば、510桁とか。
で、fx-CG50 の upython でコレを実行すると、およそ 508までは計算できました ... Feynman point の 762桁には届かない。ウーム。
800桁程度まで計算できるならば、Feynman Point の部分を取り出すため、つぎの追加をする所なのですが、
print(str(machin(800))[760:769])CASIO python では無理ゲーでした、残念。
しかし、諦めが悪いので Python Extra などで試してみましたら、ナント ! 計算できてしまいますネ ! コリャーエエ。
調子に乗って、XCAS でも試してみましたら、これでも計算できます。いや、不可解。
メモリ管理などの方法が違う、という感じなのかも知れません。
この 「Feynman point を表示する」という設問については、C.BASIC で実現できそうな気がするのですが、そのために、C.BASIC のマニュアルを眺めていたら、その機能の多さに圧倒されてしまい、勉強が進んでおりません。
折を見て、書けたらと思います。
ス・キ・魔 :
fx-9750GIII の CASIO python では、machin(254) まで計算してくれましたが、メモリの少ない 9750GIII では致し方のない所であります。
と・こ・ろ・が ! XCAS では実行できますネ。ただ、Clock UP の仕掛けがないので、40秒くらいの時間が掛かります。
str(machin(800))[760:769]
"349999998"
20 件のコメント:
akatuki様
fx-CG100ですと n=688 までは計算でて、出力が 872146844 となりました。
689以上になると Memory Error となります。
整数要素のリストは1000要素は問題ないことは確認済み。
するとスタック不足が疑われるので、計算方法を工夫すればなんとかなりそうですね。
akatuki様
こんなん出来ました。
fx-CG100で、990桁から1000桁までを出力できました。
>>> from PiCalc10 inport *
From digit#990 to 1000: 09216420198
このページを見ると、一致するので正しそう:
https://ryo.blue/archive/%e5%86%86%e5%91%a8%e7%8e%87-1000%e6%a1%81/
スクリプトは以下:
def n_th_digit_of_pi(n):
def s(j, n):
s = 0.0
for k in range(n + 1):
r = 8 * k + j
s = (s + pow(16, n - k, r) / r) % 1.0
for k in range(n + 1, n + 10):
s = (s + 16**(n - k) / (8 * k + j)) % 1.0
return s
# Get digit #n using BBP equasion
x = (4 * s(1, n) - 2 * s(4, n) - s(5, n) - s(6, n)) % 1.0
return int(x * 10) # Return an approximation as a dev\cimal value
def print_pi_range_optimized(start, end):
print("From digit#"+str(start)+" to "+str(end)+": ", end="")
# streaming-ish calculation by saving memory
q, r, t, k, m, x = 1, 0, 1, 1, 3, 3
count = 0
while count <= end:
if 4 * q + r - t < m * t:
count += 1
if start <= count <= end:
print(m, end="")
q, r, t, k, m, x = (10 * q, 10 * (r - m * t), t, k,
(10 * (3 * q + r)) // t - 10 * m, x
)
else:
q, r, t, k, m, x = (
q * k, (2 * q + r) * x, t * x, k + 1,
(q * (7 * k + 2) + r * x) // (t * x), x + 2
)
print()
# Calculate
print_pi_range_optimized(990, 1000)
=====
def s(j, n)では、
sum_{k=0}^{n} (16^(n-k) mod (8k+j)) / (8k+j) により
巨大な16^nを直接扱わず、pow(16, n-k, mod) でメモリを節約
def n_th_digit_of_pi(n)では、
BBP公式によるn桁目の16進数算出を行って、
10進数への変換精度を確保するため少し前から計算します。
で、10進数としての近似値を返すようにします。
def print_pi_range_optimized(start, end)では、
実際には、10進数で特定の桁を直接出すのは数学的に複雑なため、
1000桁程度の「整数演算」をメモリ最小限で行う手法を適用します。
数値が得られたらストリーミング的にメモリを使わずに計算する感じです。
一番最後の行で、表示開始の桁数と終了の桁数を即値で指定すると、色々計算できます。
akatuki様
fx-CG100を使って、PiCalc10.py で、最後の行を以下のようにして、実行してみました。
print_pi_range_optimized(762, 772)
すると、 Shell画面で以下のようになりました:
>>> from PiCalc10 import*
From digit#762 to 772: 49999998372
763桁目から9が6連続になるようです。
akatuki様
インデックス (count) は0から始まるから、最後の関数の start と end は、実際の桁数より1少ない値にしないと、ですね。
akatuki様
このスクリプトを応用すると、円周率の多桁出力ができてしまいそうです。Shell画面への出力のスタックは300行までOKなので、1行10桁とすると3000桁まで、1行20桁だと6000桁まで出力できる計算です。
面白そうです。
akatuki様、
3つ目以降の私のコメントを削除しただけませんか。連投でご迷惑をおかけして、すみません。
やす (Krtyski) 様、早々のお越し、多謝であります !
> fx-CG100ですと n=688 までは計算でて、出力が 872146844 となりました。
> 689以上になると Memory Error となります。
fx-CG50 より計算桁数が多いでありますネ。
python で扱う work memory (RAM) が多いのかも ?
> 整数要素のリストは1000要素は問題ないことは確認済み。
> するとスタック不足が疑われるので、計算方法を工夫すればなんとかなりそうですね。
仰るように、多桁整数を複数保持しているので、memory がアップアップしているのだと、ですネ。
> こんなん出来ました。
泉アツノさんじゃないですか !?
それは冗談でありますが、圧巻であります !
BBP計算って、知りませんでした。最新の成果でありますネ。不勉強の誹りを ...
> 763桁目から9が6連続になるようです。
> インデックス (count) は0から始まるから、最後の関数の start と end は、実際の桁数より1少ない値にしないと、ですね。
最初の「3」(index : 0) は小数点数ではなく、indexが小数点以下の桁と一致する筈ですから、763目桁が「小数点以下 762桁目」となる様であります。
> このスクリプトを応用すると、円周率の多桁出力ができてしまいそうです。Shell画面への出力のスタックは300行までOKなので、1行10桁とすると3000桁まで、1行20桁だと6000桁まで出力できる計算です。
素晴らしいであります !
多桁出力もそうでありますが、BBP計算、親分の blog に掲載して公開するのが断然よい成果であります !
( 既に作業中であるとは思いますが )
akatuki様、
泉アツノをご存知とは...
只者では、ござらんな
ところで、fx-CG100のshell画面出力のスタックは200行で、CG50と同じでした。上で300行と書いたのは誤りでした。訂正致します。
akatuki様、
ご指摘のように、円周率の最初の3を桁数に入れてしまっていたので、小数点以下の桁数で処理をするように修正しました。
これまで count としていた桁数変数を decimal_count に変更し、これは小数点以下の桁数にしました。そして decimal_count = 0 の時は最初の '3' が現れる時なので、表示もカウントアップもしない (つまり、何もしないでループを次に回す) といった手抜き改造をしたら、うまくゆきました。
BBP公式を使った計算があることを知って、始めてトライしました。以前、ここで円周率の多桁表示で盛り上がった時は、まさかカシオ電卓で Python が走るなんて思いもしなかったので、今回は Casio Python のスクリプトを追加できたので、楽しかったです!
ありがとうございます(^^)/
スクリプトファイルを以下からダウンロードできるようにしました:
https://egadget2.web.fc2.com/python/PiCalc10/PiCalc10.html
電卓では日本ご表示ができないので、キャプションを無理矢理英語にしているので、分かりにくいです(ゴメンナサイ)。
akatuki様、
BBP計算で円周率の小数点以下で特定範囲の値を示すスクリプトに着目して、BBPアルゴリズムで小数点以下 760から770桁までの値を示すスクリプトを Gemini に作らせたところ、昔のTV番組みたいに「こんなん出来ました」と出てきました。
Casio Pythonにはないモジュール(decimal モジュール)を使わないこと、スタックメモリを極力使わないこと、関数名と動作を具体的に指示しました。その一部が解説に書いた内容です。
ところが、よく見てみるとBBP計算の関数は作っているのに、それを使わず、連分数を省メモリで計算する方法で結果表示していました。
いやはや、ヤラレました。お恥ずかしい話です。
使いもしない BBP計算の関数 n_th_digit_of_pi() を消したものを再度アップロードしておきました。
小数点以下の桁数への修正は、ちょいちょいとやったのですが、キメラに気づかなかったという...
AIは何をやるのか、ホント分からないです。
って、ことで連分数を用いたスクリプトに再着目して、Feynman Point探索と単純なた桁円周率計算の両方ができるものに、仕上げています。
なんだか、みっともないことになってしまいましたが、まぁそれも私なので、ご容赦ください(^^;
やす (Krtyski) 様、ご来訪多謝であります !
親分、遅れておりまして申し訳ない !
> 泉アツノをご存知とは...
> 只者では、ござらんな
その手の話題、結構好きなんですヨ、ハイ。
> BBP公式を使った計算があることを知って、始めてトライしました。以前、ここで円周率の多桁表示で盛り上がった時は、まさかカシオ電卓で Python が走るなんて思いもしなかったので、今回は Casio Python のスクリプトを追加できたので、楽しかったです!
BBP公式、結構スゴイ話でした !
こちらこそ、面白い話をお知らせ戴き、多謝であります !
> スクリプトファイルを以下からダウンロードできるようにしました:
> https://egadget2.web.fc2.com/python/PiCalc10/PiCalc10.html
お疲れ様であります !
> BBP計算で円周率の小数点以下で特定範囲の値を示すスクリプトに着目して、BBPアルゴリズムで小数点以下 760から770桁までの値を示すスクリプトを Gemini に作らせたところ、昔のTV番組みたいに「こんなん出来ました」と出てきました。
... (引用割愛) ...
> AIは何をやるのか、ホント分からないです。
まあ、AIちうのも、(要求をうまく伝えるなどの)「使い方」の部分が、面倒と言いますか、思っている事と、受け止める側の communication gap の様である様で(人はソレを heterogeneous と言うとか)、もどかしさは、時間を掛けて"和解"していくのでしょうか。
折角、これだけの労作があるのですから、AI 活用の話と織り交ぜて、blog ネタにしたら、結構ウケるのではないか、などと思うのです。
勿体ないと思うので、是非ともご検討の程を !
akatuki様
AIを使ったコーディングの体験談として、いずれ私のブログで紹介使用と思っています。
それよりもAIが作ったコードの背景にある数学を理解しながら、その美しさに感動しているところです。そして、なぜPythonでそのアルゴリズムなのか?について私なりの言葉で説明することで、感動を伝えてみたいという衝動に駆られています。
円周率を無限に続く連分数で表現し、それを一旦漸化式を用いた級数(n=0から∞にしたときに総和で表現)に変換できるので、任意のm桁目からn桁目までの範囲をしたいしたら、それだけで円周率が計算できるところが、第1の感動ポイント。
その漸化式の k項目目からk+1項目目を得る関数表現から、同じ結果が2x2行列の積計算に対応させることができるところが、第2の感動ポイント。
円周率のn桁目を求めるには、元の初期行列に所定の行列をn回右からかけることで、初期の2x2行列が、n回変換された結果、つまり4個の変数の変化だけをメモリに置いておけばよく、全桁をメモリに保存する必要が無いところが、第3の感動ポイント。
MicroPython、特にカシオモデルのPythonは15桁精度を保証し、計算結果の正しさは無限桁で正しいとされていることが、今回の電卓プログラムで役立つわけで、Pytnonを使うことの正当性が、そこにあります。
小数点以下何桁まで計算できるかを何度もスクリプトを走らせて調べたところ、FXモデルでは980桁、CGモデルでは 3220桁まで得られることが分かりました。
CGモデルではshell出力のスタックが200行分であり、スクリプトの出力方法として1行20桁、5行(100桁)ごとに区切り行を追加する様式で、200行まるまる表示できました。
一方、FXモデルではshell出力のスタックは100行分あるのですが、今回のスクリプトではなぜか65行分が限界で、これを超えるとメモリーエラーになります。何度も更新される2x2行行列に伴う変数の更新では、数値そのものの桁数が非常に大きくなることが、出力スタックに加えてメモリを圧迫しているのだろうという予想です。
私が作ったユーザーモジュール (u.py)にある isCG() [FX/CGモデル判定関数] を使うことで、1つのスクリプトでFXとCG両モデルに対応するようにしました。
そもそもは、akatuki様ご提案の Feynman Point 検索&表示プログラムですので、小数点以下のstart桁からend桁までを指定して、その範囲の値を表示する機能 (Mode 1) を実装しましたが、円周率の全桁をメモリが許す限り表示する機能 (Mode 0) も追加しました。ソースを変更せずに、Mode 0 か 1 を選んで、範囲も自由に入力できるように仕上げました。
以下から、ダウンロードできますので、一度お試しください。
https://egadget2.web.fc2.com/python/PiCalc/PiCalc.html
akatuki様
ちなみに、以下のモデルで動作検証して最大桁数を調べました。
FXモデル:fx-9860GIII、fx-9750GIII
CGモデル:fx-CG50, fx-CG100, Graph Math+
やす (Krtyski) 様。親分、遅れて申し訳ない !
オツムが弱ってきて、電卓の Solver で計算遊びをしてゐる日々という情けない有様 ...
> AIを使ったコーディングの体験談として、いずれ私のブログで紹介使用と思っています。
是非とも、その様に、であります ! ハイ。
> それよりもAIが作ったコードの背景にある数学を理解しながら、その美しさに感動しているところです。
... (引用割愛) ...
> MicroPython、特にカシオモデルのPythonは15桁精度を保証し、...
この辺りの記述も、親分の blog で詳細を述べますと、大変有意義なものとなる事、請合いであります !
当方の comment 欄で埋もれさせてしまうのは、実に勿体ない。
> 小数点以下何桁まで計算できるかを何度もスクリプトを走らせて調べたところ、FXモデルでは980桁、CGモデルでは 3220桁まで得られることが分かりました。
オオッ ! ここまで計算できるとは !
> CGモデルではshell出力のスタックが200行分であり、スクリプトの出力方法として1行20桁、5行(100桁)ごとに区切り行を追加する様式で、200行まるまる表示できました。
> 一方、FXモデルではshell出力のスタックは100行分あるのですが、今回のスクリプトではなぜか65行分が限界で、これを超えるとメモリーエラーになります。何度も更新される2x2行行列に伴う変数の更新では、数値そのものの桁数が非常に大きくなることが、出力スタックに加えてメモリを圧迫しているのだろうという予想です。
結構意外な感じであります。
単純に Text buffer に表示するという具合ではなく、任意桁数整数のハンドルに係る部分で heap memory が使われているのかしらん ?
動的に heap を取っていたら、Text buffer にしわ寄せ、とか。
> 私が作ったユーザーモジュール (u.py)にある isCG() [FX/CGモデル判定関数] を使うことで、1つのスクリプトでFXとCG両モデルに対応するようにしました。
そうでありましたネ。
画面状態で機体を識別する機能で、機体ごとに分岐する手法はウマい方法であります。
> ... 小数点以下のstart桁からend桁までを指定して、その範囲の値を表示する機能 (Mode 1) を実装しましたが、円周率の全桁をメモリが許す限り表示する機能 (Mode 0) も追加しました。ソースを変更せずに、Mode 0 か 1 を選んで、範囲も自由に入力できるように仕上げました。
多機能化も素晴らしいです !
> 以下から、ダウンロードできますので、一度お試しください。
> https://egadget2.web.fc2.com/python/PiCalc/PiCalc.html
有り難く、利用させて戴きたく思います。
元々、Machin 式 による円周率計算という Bench Mark 的な作業で、ポツポツと思ったのですが、親分が BBP計算という「刺客」を引っさげて来たので、
「コレはヤラレタ !」となってしまいました。
BBP計算という知見が勉強になりまして、大変有り難く !
akatuki様
ええと、PiCalc.pyで採用したのはBBP計算のフリをして、実は違いというオチです。BBP計算は16進数で円周率を効率的(メモリ使用量を抑制して高速)なのですが、10進数での出力には向いていないとのことです。
Geminiが出力したコードでは、BBPのコードがありながら、別のコードで結果を出力しておりました。AIにヤラレてしまったのです。
で、今回の計算に使われたのは、5つの変数のみを順次更新しながら、桁を出力しつづける(垂れ流す)ことで、全桁をメモリに置かずに省メモリだというのが特長で、円周率を得る無限に続き連分数を、n桁を出力するための再帰的な関数を2x2行の行列の積に置換えて、実現するといったものです。特に名前な無さそうなのですが、Bill Gosper という人が開発したアルゴリズムなんだそうです。
コードを出力したAI君に数学的背景や祖のアルゴリズムが数学的に正当性があることを証明させようとしましたが、今のLLMモデルのAIでは、ネットに散らばっている情報をつぎはぎで出力するので、まぁ計算が間違っていたり、記号や論理に一貫性が無かったり、異なった人が公開した情報の切り貼りなので、まぁ一見してAIの出力さと分かるような、テキトーなものを読んでも、なかなかキチンと理解するのに苦労しておりました。
それらの断片的な情報を元に、自分なりに昔ながらの方法でGoogle検索して、ようやく理解ができつつあり、自分なりに文書を作れそうになってきました。
...ってころで、BBPは別途16進数専用ということでした。
ファインマンポイント、πの2倍のτでもほぼ同じ位置に現れるのは偶然にしてはなんかすごいですね。
BBPの話が出ていたので、できるだけ正確に自由な桁数で計算するために浮動小数点数を使わない形で実装したもので十六進法で数字が並んでいるポイントを計算してみました。
コメントでは画像を貼れないみたいなので、bloggerのアカウントを使ってアップロードしてみました。
https://k-cg50.blogspot.com/2026/01/blog-post.html
第1引数が「小数第何位から」、第2引数が「何バイト分」←表示桁数の半分、となっています。
888のところは円周率の先頭なので計算は一瞬、
8888のところは12秒、
おまけの314のところは3秒かかりました。
やす (Krtyski) 様、ようこそお越しくださいました !
> ええと、PiCalc.pyで採用したのはBBP計算のフリをして、実は違いというオチです。BBP計算は16進数で円周率を効率的(メモリ使用量を抑制して高速)なのですが、10進数での出力には向いていないとのことです。
> Geminiが出力したコードでは、BBPのコードがありながら、別のコードで結果を出力しておりました。AIにヤラレてしまったのです。
ありゃ、そうでしたのですか !
BBP計算ちうのが初めてだったので、ポツポツ調べてみようか、などと思っておりましたら「まさかの逆」でありますね、コレは。
> で、今回の計算に使われたのは、5つの変数のみを順次更新しながら、桁を出力しつづける(垂れ流す)ことで、全桁をメモリに置かずに省メモリだというのが特長で、円周率を得る無限に続き連分数を、n桁を出力するための再帰的な関数を2x2行の行列の積に置換えて、実現するといったものです。特に名前な無さそうなのですが、Bill Gosper という人が開発したアルゴリズムなんだそうです。
アアッ ! そうでしたの !
そう言われてみれば、Machin の式でも、加算する項が順次小さくなって行きますから、同様の手法が使えるかもですネ !
これは良い事を聞きました。有難う御座います !
> コードを出力したAI君に数学的背景や祖のアルゴリズムが数学的に正当性があることを証明させようとしましたが、今のLLMモデルのAIでは、ネットに散らばっている情報をつぎはぎで出力するので、まぁ計算が間違っていたり、記号や論理に一貫性が無かったり、異なった人が公開した情報の切り貼りなので、まぁ一見してAIの出力さと分かるような、テキトーなものを読んでも、なかなかキチンと理解するのに苦労しておりました。
web 空間にある code を集約、essence を coherent するのが AI の眼目らしく、その意味ではまだ、 Garbage in garbage out の域の様でもあります。web 空間にある text/code を抽出するのが、AI との session らしく、この部分で skill が求められているとか。Skill and Hide .
一頃、web 検索の skill を磨くとかで seracher とかいう職種もあったそうですが、今日、AI との session を行うのは、知識を満蔵した Tower of Babel から oracle を受け取る medium という具合であります。
そんな session を個々人が行う事で、そうした作業が加速化、「智の大爆発」の様な具合になって来るのでしょうか ?
> それらの断片的な情報を元に、自分なりに昔ながらの方法でGoogle検索して、ようやく理解ができつつあり、自分なりに文書を作れそうになってきました。
> ...ってころで、BBPは別途16進数専用ということでした。
お知らせ有難う御座います !
K 様、ようこそ越し下さいました !
> ファインマンポイント、πの2倍のτでもほぼ同じ位置に現れるのは偶然にしてはなんかすごいですね。
πの2倍のτ というの、知らんかったです。勉強になります ! 不勉強で申し訳ない。
手近の飛び道具で調べたら、仰る通りでありました。
π (750:769) 0518707211 3499999983
τ (750:769) 1037414422 6999999967
言われてみれば、999999*2 = 1999998 でありましたネ。
> BBPの話が出ていたので、できるだけ正確に自由な桁数で計算するために浮動小数点数を使わない形で実装したもので十六進法で数字が並んでいるポイントを計算してみました。
お疲れ様であります !
> コメントでは画像を貼れないみたいなので、bloggerのアカウントを使ってアップロードしてみました。
> https://k-cg50.blogspot.com/2026/01/blog-post.html
> 第1引数が「小数第何位から」、第2引数が「何バイト分」←表示桁数の半分、となっています。
> 888のところは円周率の先頭なので計算は一瞬、
> 8888のところは12秒、
> おまけの314のところは3秒かかりました。
オオッ ! こちらの BBP計算, 電卓で動くのでありますね !
blogger だったので、これについての記事とか、何か書かれませんでしょうか ? (コレじゃ"クレクレ中" ... Zelenskyy じゃねェんだから)
BBPそのものは記事とかいろいろあるので、私のオリジナルかなと思える部分は計算に利用するバッファ(小数部分の幅)を何ビットにするかという部分だけなんですよね。で、そもそもBBPを使うなら普通は速度を求めてバッファとして浮動小数点数を利用するとか、整数を使うにしても32bitとか64bitとかCPUに合わせたりしてしまうのが当たり前なので、 ニッチ過ぎて誰得なんだとしか思えず……といったところです^^;
K 様。どうにも体のキレが悪く、遅れておりました申し訳ない !
BBPちうのが、そもそも良う知らんかったので、妄想とクレクレが発現してしまいました。
申し訳ないであります。
よく調べて、手を尽くすなどして行きたく思う所であります。
コメントを投稿