検証テストの結果をメールで自動送信する

反例が出てくる可能性はゼロなので,ある意味でやっても意味がないテストではあるが,コラッツ問題に対する我々の最終回答の妥当性を直観的に印象付けるためには,ある相当広い範囲で「検証テスト」を実行し,その結果が確認されなくてはならない.しかし,2^24の範囲ですら16時間も掛かっているので,2^32の範囲をチェックするためには,16x2^8=4096時間も掛かってしまう.しかし,もし,256人の協力者がいれば,この計算を16時間以内に完了することも可能だ.テストを任意の奇数から開始できるように改変したのには,このような分散計算を実施するという意図がある.

分散したコンピュータを連結して一つのスーパーコンピュータを構成するようなことができれば最高だが,そこまでのスキルはないので,テストの結果を(半自動的に)メールで送信してもらい,それを手作業で集計するという方式を考えてみた.このためには,まずリモートからメールを発信できるようにする必要がある.プログラムからメールを送信するという処理は昔どこかでやったような記憶はあるが,古いコードは見つからないし,ネット上の記事を参考にして書き下ろしたコードもすべてエラーになってしまう.何もかもが牧歌的だった昔はシンプルなコードでメールの送受信ができていたのだが,ゼロトラストの時代に突入した現代では通用しないものになってしまっている.

最終的に以下の記事を見つけて送信に成功したが,たとえば,gmailのように認証に二段階認証が組み込まれている場合には,このコードでも送信できない.MailKit によるメール送信のコード

LibreOfficeを導入し,画像編集はすべてこのソフトでやることにしたので,ペイントもタスクバーから外してしまったのだが,それも少し早まった判断だったようだ.ペイントでなければできないこと,ペイントの方が使い勝手がよいところもあり,直ちにすべてをLibreで代替という訳にもゆかないということがわかった.それぞれのソフトには,それぞれの設計思想というものがあり,すべてを代用できるというものではないのかもしれない.Libreの一番大きな制約はすべての画像が「用紙」ないし「ページ」の上に配置されているという点だ.ペイントにはこのような概念はなく,画面上におかれた画像のサイズが描画領域そのものになっている.ペイントでもっともよく使っているツールは「クリッピング」だが,Libreにはそれがない(ように思われる).

Collatz Regular Tree Generator V1.03をリリースして,ownCloud にアップロードした.前回リリースは1月7日の「新年版」で,この版の目玉は.NET 5.0のBigIntegerを採用して,事実上取り扱う数値の範囲が無制限になったという点だ.しかし,配列サイズには以前として制限があり,これを回避するためにあらかじめコラッツ木上の有効ノード数を計算しておいて,可能な限り極小な配列で間に合わせるようにしてみたのだが,あまり効果的と言えるようなものではなかった.(この計算式をもう少し緻密なものにするようモヒティに注文しているが,まぁ当てにならないことは目に見えている)

そこで,切り札として登場したのが,配列を使わない「再帰関数に転換」するという方式変更で,これによって基本的に配列サイズオーバーやメモリ不足などの空間的制約から完全に解放され,「時間」さえ許されれば基本的にどのように大きなコラッツ木でも生成できるようになった.出力はファイルに保存というオプションがあるので,ランタイムで使用するメモリの容量はほぼ一定だ.

image

コラッツ木の生成で再帰関数を使うというのは,コラッツ木がフラクタルであることを考えれば,もっとも自然な表現であることがわかる.フラクタルというのはマンデルブロの定義によれば,「部分が全体と自己相似的であるような図形」であり,再帰関数というのは,その関数自体を再帰的に実行するような関数であるからだ.

もう一つの追加機能として,「コラッツ木生成論理の検証テスト」ないし,「コラッツ木構造検定」と呼んでいる機能を追加した.このテストは任意の奇数から開始して指定した個数の奇数がコラッツ木上にあることを確認するというものだ.このテストはすでに実装されている①Get the sequenceという機能と,②Get the numberという機能を組み合わせたもので,①と②はそれぞれの逆演算になっている.

①は奇数番号を指定して枝番号リストを生成し,②は枝番号リストから奇数番号を特定するというものだが,検査対象となる奇数番号Nが与えられたとき,処理①→処理②,つまり,N→枝番号リスト→N’という処理を実行する.検定実行中は「Copy branch numbers from the sequence」というチェックボックスがつねにオンになっている.

NとN’が一致しなかったり,処理の途中で不都合が生じたりした場合には検定は失敗である.原理的にそのようなエラーが発生する可能性はゼロと考えられるが,コラッツ木構造から生成されたコラッツ木がすべての奇数を網羅しているかどうかを実証的に確認するためには,このようなやや冗長な検定を実施することも忌避できない.

image

検定結果をメールで開発者にフィードバックできるようにした.imageボタンは通常は不能状態になっていて,検定を実施した直後だけ操作可能となる.このボタンを押すと,画面下部の出力バッファに表示されている内容が直接babalabos@outlook.jp に送信されるような作りになっている.送信テキスト(本文)は以下のような内容だ.

Verification Test for the Collatz Tree Structure ( 22/01/11 19:29 UTC )
Start From 812997 upto 817091
Total odd number count: 2048
Big number : 1144540205
Max degree: 8 @ 251221
Tree height: 137 @ 813307
Time spent: 00:00:17
Verification Test Complete !
Click the mail button above and send the result to us (babalabos@outlook.jp) !!
Thanks in advance…

時刻にUTCを使っているのは,世界中のどこから届いても時間がわかるようにという配慮だが,果たして使ってくれる人がいるのだろうか?(モヒティはPCを持っていないというのでその時点で番外だ…)

▲一つ不審な点がある.コラッツ木構造検定のメール送信ボタンの位置が実行時にあいまいだ.サブノートではVerifyボタンの上にかぶってしまっているが,予備の薄型ノートではむしろ開き過ぎるくらいに離れている.上図はサブノートの画面で②つのボタンに重なりが生じている.なぜこのようなことが起きるのか理解に苦しむ…

▲コラッツ木生成時にダンプ出力を格納しているRichTextBoxがどこまでも増大してゆくのを防ぐために時間経過とともに一定量以上のテキストをカットするという処理が入っているが,文字数でカットしているため,冒頭の一行が損なわれてしまうという問題がある.これを避けるためには,カットを文字単位ではなく,行単位で実行することが考えられる.行の終わりを検出してそこまでをカットするという処理はそれほど難しくないので,やっておいた方がよいと思う.

この調整は最後の回に一度だけ実施すればよい.なぜかと言うと中間の時点では自動スクロールしていて,端の始末などをチェックしている余裕はないからだ.つまり,検定が完了してスクロールが停止した時点で調整しておけば十分と言える.RTFの中で改行コードが見つからない.テキストを格納するときにはvbCrLfをセットしているのだが,RTFに格納した時点で書き換えられているようだ.何を使っているのだろう?vbLfで見つけることができた.

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA