987654321と123456789 この数字の配列に隠された驚きの法則
引用元：https://news.ycombinator.com/item?id=45712620
123456789を8倍すると987654312になるって、最後の2桁が入れ替わるんだね。これって他の基数でも同じで、例えば16進数だと0x123456789ABCDEFを14倍すると0xFEDCBA987654312になるらしいよ。あと、123456789をそろばんで8回足すのは、いい練習になって目で結果が確認しやすいってさ。
これも面白いんだけど、基数nで昇順の数字列に「(n-2)を掛けて、それから(n-1)を足す」ってやると、降順の数字列になるみたいだよ。16進数だと123456789ABCDEF16 * (16-2) + 16 - 1 = FEDCBA98765432116ってなるし、10進数でも987654321になるんだ。色々な基数で成り立つ一般法則を示しててすごいね。
これって元の記事にもう載ってる話だね。num(b)/denom(b) = b - 2 + (b-1)/denom(b) って形で書かれてるから、分母を払えば同じ式になるよ。
「最後の2桁が入れ替わる」って話だけど、入れ替わった数字って順序通りから+9ずれてるんだね。12345678を8倍すると98765424になるんだけど、これも順序通りから+9ずれてるんだってさ。
俺も順序じゃなくて「差」に注目してみたよ。16進数の場合だと、差は15 (0xEFと0x12)だったね。それで「任意の基数Bで、昇順の数字をA、降順の数字をDとすると、(D-(B-1))/A = B-2」っていう法則を見つけたんだ。2進数から4進数まで例を挙げてて、数が大きくなるほど「数パイのスライス」が小さくなるっていう面白い解釈もしてるよ。
あ、ごめん。2つ目のやつは+8って書くべきだったね。
8桁電卓だと、この手の計算でよく知られてるのが「12345679 * 8 = 98765432」ってやつだよね。
コードと証明がこんなに相補的だなんて、めちゃくちゃ興味深いポイントだね！全ての数学の証明でこれをしてくれたら最高なんだけど。「証明よりスクリプトを入れる理由？一つは証明が単純だけど面倒で、スクリプトがコンパクトだから。もっと一般的な理由は、プログラムが証明を補完するから。両方バグの可能性はあるけど、同じバグは出にくいし、プログラムは詳細を明確にするから、証明では十分に説明されてない部分を埋めてくれるんだ。」
子どもの頃、競技数学はまあまあ得意だったけど、TI-Basicの方がもっと速くて得意だったんだ。電卓だけじゃ答えが出ない問題でも、いくつかのアイデアからプログラムで間違ったものを消していくのに使ってたよ。著者のスクリプトはそれ自体が証明じゃないんだ。もし命題が間違ってたら、反例が最高の証明になるけどね:p
俺も同じことやってたよ。テストで計算できる問題があったら、自作プログラム使うか、その場でコード書いて裏で動かしながら、電卓なしで他の問題に取り組んでたんだ。
これって賢い方法だよね。
これって誤解を生むよ。Curry–Howard対応は、証明とプログラムの静的型付けの間のものだからね。証明のバグは、プログラムの静的型付けのバグに対応するんだ。他のプログラムバグとは違うよ。(あと、complementaryとcomplimentaryも間違ってるよ)。
著者はC–H対応について言ってるんじゃないと思うな。
単に、a) ある性質がものすごい数まで成り立つかチェックするのは、すべてについて成り立つ証明じゃなくても、実際に役立つってことと、b) もし証明にバグがあったら、ものすごい数までその性質をチェックするプログラムが、反例を見つけ出す可能性が高いってことだよ。
＞ あと、complementaryとcomplimentaryも間違ってるよ
それはオートコレクトのせいにするわ。でも、指摘してくれてありがとう。直したよ！:)
大事なのは、対応関係に固執しすぎないことだよ。問題を違うやり方で（たとえそれが「一部」と「全体」みたいな別の問題でも）考えることが、実はすごく役立つんだ。
両方で同じ間違いをする可能性が低くなるからね。ユニットテストでコードを2つの言語で書く手法があるけど、それも異なる視点とツールを使うことがポイントなんだよ。
俺はこれ、違うと思うな。コードは証明で、型は命題だよ。
コードは、そのコードが持つ操作がちゃんと動くっていう証明にはなるよね。でも、それ以上に一般的に何かを証明するってのが、よくわからないんだ。そういう目的で作られた特殊な言語とか技術を使ってる場合を除いてね。
理論的には、公理や仮定なしに絶対性を証明するのは無理だよね。実践的な定理証明器では、コンパイラにバグがあったらどうする？とか、意図通りにコンパイルされたかどうやって知る？って問題がある。基本的には、ちょっとした間違いが「ハードフェイル」してくれることを期待するしかない。普通のプログラミングでのタイプミスみたいに、些細なエラーから根本的な誤解まで、ズレを検知できるのが定理証明器のいいところだね。友達がDFSの証明でも大変だって言ってたよ。
型は、証明によって示される命題のことだね。証明が正しいことと、プログラムが健全に型付けされていることは同値だよ。
そのセクションを引用しに来たんだけど、先にコメント見てよかったよ。スクリプトで証明を示すことの価値について、こんなに簡潔な説明は初めて見たね。今後は「証明にはバグがある」って表現にしようと思う。
他の返信も良いけど、俺も一つ追加しとくわ。0.987654321/0.123456789 = （1.11111111-x）/x = 1.11111111/x - 1 と書けるんだ。xは0.123456789だよ。1.11111111は10/9で、xはy = sum_i＞0 i/10^i を使うと近似できる。関数 f（t） = sum_i＞0 i*t^i は f（t） = t/（1-t）^2 となるから、y = f（0.1） = 0.1/0.9^2 = 10/81だね。これを代入すると、元の比率は約8になる。Taylor法で誤差評価もできるけど、めんどいからやめとくわ。
sum i/10^i を計算するもっと簡単な方法があるんだ。sum 1/10^i を二乗するんだよ。（1/9）^2 = （sum 1/10^i）^2 = 1/10 sum i/10^i ってなるんだ。導関数のトリックも便利だけど、この方法は0.12345678..の解を出すのに速くて、もっと簡単に正当化できるぜ。
証明してやろう。一般的に、sum（x^k, k=1…n） = x（1-x^n）/（1-x）だ。それを微分すると、sum（kx^（k-1）, k=1…n） = （nx^（n+1） - （n+1）x^n + 1）/（1-x）^2 になる。元記事の分子と分母はこれで証明できるんだ。スクリプトが証明と同じくらい使えるって意見には反対だな。スクリプトは建設的でも網羅的でもないからね。
作者はスクリプトが証明と同じくらい使えるなんて言ってないぞ。
もっと怠けたいなら、生成関数を見つけた後、SymPy にぶち込めば代数計算を飛ばせるぜ。
こういう電卓の変なところが好きなんだ。子供の頃、テンキーで遊んでて、数列に幾何学的な重心があることに気づいたんだよ。（14787 + 36989） / 2 が 25888 になるってね。二つの数列が描く幾何学的な形の平均が真ん中で平均される、みたいな感じさ。
もっと簡単な例の方がはっきりするな。（147 + 369） / 2 = 258 と （741 + 963） / 2 = 852 だよ。
これって当たり前じゃない？
（741 + 963）/2 = （700+900）/2 + （40+60）/2 + （1+3）/2 って、ただ各桁で平均を取ってるだけだよ。
今じゃ当たり前だけど、振り返るとすごくクールだよな。
10進数の数字たちには明らかに共謀があるぜ。
どんな基数でも同じことだね。シュメール人が好きだった12進数なら、もっと面白い法則が見つかりそうだよ。2,3,4,6で割り切れるからね。指が5本しかないのが残念だなぁ。
もっとコメントを表示（1）
親指で他の4本の指の関節を数えれば、片手で12まで数えられるって知ってた？
俺は子供の頃から片手で20まで数えてたよ。指の根元、下関節、上関節、先端で数えて、親指も使って5倍。親指で他の指を数えて、16過ぎたら人差し指で親指を数えるんだ。体が覚えちゃってて、自然とできるんだよね。
俺も一緒だよ！片手で20、両手で40まで数えてた。親に教わったんだ。子供の頃使いすぎて、今でも40までの数字は指に場所がある感じ。大人になってから、周りにこの数え方をする人がいないって気づいたんだよね。同じ方法を使ってる人を見つけられて嬉しいよ！
指をそれぞれ二進数（バイナリ）の桁とすると、片手で15、両手で255まで数えられるよ！親指も使えば1023だけど、俺は親指を繰り上がりとかオーバーフロービットとして使うのが好きだね。
俺、ずっと前にこれ（バイナリでの数え方）を自分でできるように訓練したんだ。もう他の数え方なんて考えられないくらい自然で便利だよ。特定の数字のトリックにも使えるしね。もっと早くから子供たちに二進数（バイナリ）を教えるべきだよ。
僕はフランス人だけど、うちは拳から指を伸ばして数えるんだ。普通は10までね。子供の頃、右手で5の倍数を数えれば25までいけるって気づいたよ。アジアで市場の人を見て、親指で他の12の関節を数えれば144まで数えられるって分かったんだ！12の掛け算を知ってればOKだよ :)
読んだ話だけど、親指を5として使う数え方があるんだ。片手で親指を下ろすと0～4、親指を立てると5～9。これで0～99まで数えられるって！すごいでしょ。
電卓の「1110」のことも思い出したよ。キーパッドの数字の並びって、741+369とか123+987みたいに、意図せずエレガントな数学的関係を含んでるんだよね。人間の創造物には、常に予測不可能な”面白くて奇妙”な結果が伴うって現象だと思うな。
それって直感的な知識で、後から理解されるものなんだよ。（イツァーク・ベントフの『ストーキング・ザ・ワイルド・ペンデュラム』より）
記事の法則は「14789 + 36987 / 2」でも説明できるのに、なんで回りくどいことしてるの？って疑問だね。
147と369でも同じ話だよ。要するに桁ごとの平均ってことだから、たいして面白くないんじゃない？
好奇心を持つのは素晴らしいことだよね！
「できる」ってことを示すためにだよ。例えば14861と36843を足して2で割ると25852になるってこと。
Carrot TopのCMを思い出しちゃったよ！90年代とか2000年代にAT&Tがやってた「1-800-CALL-ATT」ってコレクトコールのCMの話ね。Carrot Topを知らなくても、それはそれでいいかもね。
すごいASCIIアートだね、よくやった！
どうやってこの表をHacker News (HN) に投稿したの？？
行頭にスペースを2つ以上入れるとコードブロック（＜code＞）になるから、好きな記号を使ってね。例：┌──────╖
│ OK ║
╘══════╝
詳しくはここ見てね: https://news.ycombinator.com/formatdoc
(参考までに) キャンセルボタンのASCIIアートもどうぞ。┌──────────╖
│ CANCEL ║
╘══════════╝
0.987654… と 0.123456… を無限級数として考えると、それぞれ80/81と10/81に簡略化できるんだ。だから約8倍の比率になるんだよ。
他のコメントが共有してくれたStackOverflowの2つ目の回答を見るまで、これが何のことか全然分からなかったよ。
https://math.stackexchange.com/a/2268896
どうやら1/9^2は0.12345679(012345679)…になるってよく知られてるらしいね。編集：そう、8が抜けてるんだよ（最初は書き間違えたけど）。
https://math.stackexchange.com/questions/994203/why-do-we-mi…
どうしてこうなるのかは面白いけど、親コメントが言うほど直感的じゃないと思うな。あの書き方だと、すぐに理解できなかった自分をちょっとバカにされた気分になったけど、よく考えたらコンテキストなしで分かる人なんていないよね。
実際のところ、繰り返される小数の中で8はスキップされちゃうんだよね。1/9^2は、すべての正の整数kに対するk * 10^-kの無限和って考える方が分かりやすいよ。8がスキップされるのは、…789(10)(11)…みたいな感じで、”10”と”11”からの1が繰り上がって9をインクリメントし、それがまた繰り上がって8が9になっちゃうからなんだ。
それと、12345679x9 = xxxxxxxxxっていうのもあるんだよ。例えば1234567969は666666666になるんだぜ。
9の2乗は81で、1/81は0.012345679012345679…ってなるんだよ。やっぱり8は見当たらないね。
8は元々あるんだけど、その後に9と10が続いて、10からの繰り上がりで8が押し上げられちゃうんだよ。
ゼロが2つ見えない理由はこうだよ。まず、.123456789があって、
小数点以下10桁目に10を加えると、.123456789(10)になる。ここで括弧は10以上の「桁」を表してて、きちんとした小数にするために繰り上げ処理が必要なんだ。2回繰り上げると、.12345678(10)0になって、
.1234567900になるんだ。だから一瞬はゼロが2つできるんだけど、今度は小数点以下11桁目に11を加える必要があるから、.1234567900(11)になって、
または繰り上げると.12345679011になるんだよ。だから結局、ゼロは1つだけになるんだ。
これがうまく説明してくれてるよ: https://math.stackexchange.com/a/994214
説明してくれない？なんで0.987654が80/81になって、0.123456が10/81になるの？
0.123456…はx=1/10の時、x + 2x² + 3x³ + … って式で表せるんだ。
これを分解して等比級数の和の公式を使うとx/(1-x)²になるから、x=1/10を代入すると10/81になるってわけ。
0.987654…は1 - 0.012345…だから、1 - (1/10)(10/81) = 80/81だよ。
無限級数とか多項式でごちゃごちゃしなくてもいいんだよ。
1/9は0.1111…だよね。そしたら、1/81は1/9 × 1/9だから、0.111… × 0.111…って計算すると
0.0111… + 0.00111… + 0.000111… + … って足し算になって、結果的に0.012345…になるんだ！
これって結局、形式が違うだけで同じことじゃない？
0.1111…はx=1/10の時の(x + x² + x³ + …)のことだし、1/9 = 0.1111…はx/(1-x)の公式を直接使ってるだけ。
0.0111… + 0.00111… … の足し算の部分は、(x + 2x² + 3x³ + …)の分解と同じ（10で割ってるけど）。
そして1/81 = 1/9 × 1/9も、x/(1-x)²の結果だよ。
もっとコメントを表示（2）
これ、俺の答えよりいいわ。特に、N進数（base b）で考えるとさらに分かりやすい。
その場合、最初の2行は
1/(b-1) = 0.1111…
1/((b-1)²) = 1/b × 1/b = 0.111… × 0.111… =
ってなるんだ。
誰が低評価したか知らないけど、これは正しいんだよ。
級数の使い方はちょっと”ぞんざい”に見えるかもしれないけど、x + 2x² + 3x³ + … は|x|＜r＜1の範囲で絶対一様収束するし、複素数|z|＜r＜1でも同じだ。
複素解析の素晴らしい特性として、その範囲内なら”めちゃくちゃ”ぞんざいでも大丈夫だって、Conwayの本にも書いてあるよ。
似た証明を投稿するけど、俺のは-1/10と丸めを使うから、多分もっと悪いな。
x = 0.123456…とすると、それに(10 - 1)をかけると9x = 1.111111…になるんだ。
さらに(10 - 1)をもう一度かけると81x = 10、つまりx = 10/81になるってわけ。
これは形式的に書いてないけど大体の考え方だよ。0.987654…も同じやり方で80/81になるんだ。
面白いね！でも俺にはそんなに驚きじゃないかな。
987,654,321 + 123,456,789 = 1,111,111,110で、これにさらに123,456,789を足すと約1,234,567,890になる。
つまり987,654,321 + 2 × 123,456,789 が約10 × 123,456,789ってことだから、987,654,321 / 123,456,789 は約8になるんだね。
他のN進数でも似たような法則が見えるはずだよ。
これを正確に8.0にする補正があるよ。分子を1減らして（987654321 - 1）、分母を1増やす（123456789 + 1）と、8になるんだ。
他のN進数でもこれはいけるよ。TXR Lispでbase 4の場合、(poly 4 ’(3 2 0)) / (poly 4 ’(1 2 4))は2.0になる。
base 2でも動くよ。記事のPythonコードは3からだけどね。base 2だと比率は1/1。補正すると(1-1)/(1+1)=0で、これは2-2だね。
浮動小数点演算について知っておくべきことに関する論文や記事をいくつか見てみてね。
David Goldberg, 1991: https://dl.acm.org/doi/10.1145/103162.103163
2014, ”Floating Point Demystified, Part 1”: https://blog.reverberate.org/2014/09/what-every-computer-pro… ; https://news.ycombinator.com/item?id=8321940
2015: https://www.phys.uconn.edu/~rozman/Courses/P2200_15F/downloa…
最近、浮動小数点数でごく簡単な計算を表現するバグと格闘してたから…ありがとう！
なんでb ＞ 2って条件なんだ？b=2の場合でも、3つの式全部うまく動いて比率は1になるよ。これは誤差項が整数で、その誤差項（1）が支配的になる唯一の面白いケースだね（b-2=0）。大きい基数だとb-2の部分が支配的になるのにさ。
b=2のケースだと、1 / 1 = 1 = b - 1、1 % 1 = 0 = b - 2になるね。これって逆だよ。例えばb=3のケースを見てみて:21 (基数3) = 7、12 (基数3) = 5。7 / 5 = 1 = b - 2、7 % 5 = 2 = b - 1だよ。
b=2の場合、1/1 = 1 = (b-2) + (b-1)/denom(b) = (b-2) + (b-1)/1 = 2b - 3 = (b-1)*b^1 -1 (b-1)になるよ。基数2（そして基数2だけ）では、denom(b) ＞= b-1だから、”小数部分”の(b-1)/denom(b)が1の位に繰り上がって、さらに2の位（bの位）に繰り上がり、両方のビットが反転するんだ。
これってRamanujan’s constantのTemu版みたいだね。
https://mathworld.wolfram.com/RamanujanConstant.html
”なぜ証明じゃなくてスクリプトを入れたの？理由は、証明は簡単だけど面倒で、スクリプトはコンパクトだから。”
確かにスクリプトは結果が正しいか確認できるけど、証明は”なぜ”正しいのかがわかるんだ。良い証明は、どうやってその結果を発見できたのか、どうやって一般化できるのかを感じさせてくれるかもしれないね。
偶数基数における”誤差”は、https://oeis.org/A051848 にあるものみたいだね。pp = lambda x : denom(x)/ (num(x) - denom(x)*(x - 2))の結果は、[pp(2),pp(4),pp(6),pp(8)]で[1.0, 9.0, 373.0, 48913.0]だったよ。
で、そこの説明を見ると、https://oeis.org/A023811 に辿り着くんだ。こっちの方がもっと明らかに関連してるよ。
俺も子供の頃、電卓で何時間も遊んでたな。その時に気づいたのはこれ:11 * 11 = 121111 * 111 = 123211111 * 1111 = 1234321
って感じで、答えの最大桁数は、掛けられる数の桁数と同じなんだよね。
もっと一般的な解析的な証明はこちらだよ:
https://math.stackexchange.com/questions/2268833/why-is-frac…
その質問、8年前にもされてたんだって。
偶然？まさか！
半世紀も前、子供の頃に8桁電卓をもらってね。ちゃんと動くかチェックする方法として、12345679に8をかけると98765432になるって教わったんだ。逆の割り算も試してたよ。
電卓が動かなかったことある？
そのテストじゃ、右から2番目の桁の左側が壊れてても検出できないじゃん。
それはフル機能テストじゃなくて、よくある表示やキーボードの欠陥を見つけるためのものだったんだ。
電卓ディスプレイは多重化されてるから、よくある欠陥は1桁が何も表示されないとか、1セグメントが全桁で消えるとかね。
君が言ってる欠陥は独立した桁を持つディスプレイ（デジタル時計とか）でよくあるやつだよ。
俺のVFDディスプレイとかLEDディスプレイでは、セグメント自体が壊れるなんて見たことないな。
これ、昔の電卓トリックを思い出すね。
1から9の整数を選んで9を掛ける。その数に12345679（8はスキップ）を掛けるんだ。
例えば3を選んだら、3 × 9 = 27。そして12345679 × 27 = 333333333になる！
これは111111111を9で割ると12345679.0になるからなんだ。
より小さな基数だと、基数-1に収束するのかな？
Base 3なら21/12 = 7/5（decimal）
Base 2なら1/1 = 1
Base 1なら|/| = 1（||||=4って考えるとして）
＞正確な比率は14ではないが、標準の浮動小数点数としては14に限りなく近い。
科学だと、そういう制限ってどうやって回避してるの？
有理数なら、Pythonの標準ライブラリにFractionクラスがあって、正確な整数演算ができるよ。python<br>＞＞ from fractions import Fraction<br>＞＞ f = Fraction(0xFEDCBA987654321, 0x123456789ABCDEF)<br>＞＞ f%1<br>Fraction(1, 5465701947765793)<br>＞＞ f - f%1<br>Fraction(14, 1)
これは0xFEDCBA987654321 / 0x123456789ABCDEFが正確に14 + 1/5465701947765793になることを示してる。
分母が52ビット必要で、64ビット浮動小数点数の仮数部のビット数より少し多いから、精度不足で結果が14.0に丸められちゃうんだね。
MathematicaやSageみたいに任意の桁数を使えるツールを使うといいよ。
https://www.wolframalpha.com/input?i=FEDCBA987654321_16+%2F+…
あとは、もっと仮数部が多い浮動小数点用の特別なライブラリを使ったりね。
ほとんどの科学分野では、数値って最初から正確な整数じゃないから、分子と分母に誤差範囲があって、結果にも誤差範囲が出るのが普通だよ。
