月: 2022年1月

予備機の検証テストは2^28で現在91.4%まで進んでいる．2^32を仕掛けている開発機の進捗は10.6%だ．現在，1日＋15時間なのでこの10倍ということは10日＋150時間となるので，2週間，つまり半月掛かる見込みだ．どちらも堅調に走っているので，まぁ，これでいいのではないかと思う．⇒予備機で走っていた検証テストが完了している．1日＋19時間27分だから，2^28で43時間半掛かっている．検証済み最大奇数は1006634081になった．サイトを更新しておこう．遊ばせておくのもなんだから，開発機の続きを仕掛けておこう．開発機はまだ10日以上掛かるので，予備機も2^30まで増量してみる．これでもまだ，予備機の方が先に上がってしまうかもしれない．⇒いや，とんでもない．2時間掛かってまだ1%も終わっていない…

マニュアルの執筆/編集に掛かっているところだが，書いた分だけ書くことが増えてしまうので完成までにはまだかなり掛かりそうだ．大体パターンも出揃ってきたので，あとは淡々と進めるだけというところには来ているが…⇒まだ仕上がっていないが，PDFに出力してみた．Good！これなら問題ない．LibreWriterの編集画面と寸分変わらないものが表示されている．これでなくてはならない．

HTMLでは表示にいろいろと難点があり，悩んでいたのがきれいに吹っ飛んだ．数式もきちんと表示されている．PDFならダウンロードしてオフラインで読むこともできる．一石二鳥だ．配布パッケージに組み込むこともできる．LibreOfficeはどうもHTMLが苦手なようだ．HTMLはルールもやかましく，ブラウザごとに動作が異なることもあるので，対応しきれていないのだろう．おそらく，LibreOfficeのファイル形式とPDF形式は相性がいいのではないかと思う．

あとはともかく書き上げるだけだ．⇒ゼルコバの木のリリース版を予備機にインストールしているが，ここではCSVのインポートでおびただしい数の障害ファイルが生成されている．同じ版のはずなのだが，開発環境ではそれが起こらない．なぜだろう？いや，何か勘違いしていた．インポートでは障害は発生していない．画面設定を操作したときに起きていたのだろうか？幹だけのコラッツ木の画像を取ろうとしているのだが…いや，それどころではない．Truncated treeの出力がおかしい．

#15を対象にTruncated treeをCSV出力して，ゼルコバの木で読み込んだところ高さ3の木が出力された．本来なら，(15, 23, 35, 53, 5, 1)なのだから，高さ5の木にならなくてはならないところだ．⇒画面出力は間違ってはいない．CSVファイルが悪いのだろうか？CSVファイルをダブルクリックしたらExcelが立ち上がってきた．このマシン（VAIO2）にはOfficeがプレインストールされているのだろうか？Microsoft Officeが使えて悪いということもないのだが…確かにMicrosoft Office 2013がインストールされているようだ．このマシンにはまだLibreOfficeをインストールしていないので，ともかく使うしかないだろう．

１→5→53→まではよいが，53の子どもの{35, 141, 565}が3の子どもになってしまっている．また，35の子どもの{23, 93, 373}が13の子どもになっている．53の下には{15, 61, 245}が配置されているが，これは23の子どもだ．CSVを見てみよう．確かに，CSVが間違っているようだ．#35の親が#3になっている．おそらくこれは，隣接リストの出力順が変化しているためだろう．以前の論理ではルートから一段目を水平に処理してから，次段に移るようなフローになっていたはずだが，現行は一番右端の下降パスを行きがかり順に垂直下降しながら出力するようになっているが，カード参照番号の振り方が従来通りになっているため，合わなくなっているのだろう．

Collatz Tree GeneratorのCSV出力は問題ないように見えるが，なぜだろう？正則コラッツ木の出力も再帰関数を使う形に変更されているはずなのだが…他の処理の出力を見てみよう．Get the sequenceとGet the numberはファイル名は違うが，どちらも1をルートとしているため内容はまったく同じものになっている．Get the sequenceは画面上では最後に1が出力されるようになっているが，あえてそれを逆転させて出力している．むしろ，素直に転倒木として出力してもよかったのではないか？

いずれにせよ，刈り込み木出力が間違っていることは間違いない．正則コラッツ木が正しく出力できるのなら，できてもよさそうな気はするが…確かに，正則コラッツ木と刈り込み木ないしナンバー木では上下関係が逆転している．これは後で見ることにして，先に刈り込み木をゼルコバの木上で編集して画像だけ取ってしまおう．刈り込み木というのは幹だけの直線図式に直結する葉を付け加えたものなので，ストレートに表示するためには，血統軸線図を使う必要があるが，動作しない．エラーになってしまう．この図はどうしても必要なので，ゼルコバの木をデバッグするしかない．どうもいろいろと厄介なことになってきた．ともかく，この機会にできる限り並行してデバッグするという方針なので，行きがかり上途中下車になってしまうのはやむを得ない．まぁ，この辺りの図面がなくてもまだ書ける部分はあるので，そちらを急ぐことにしよう．⇒仮の画像を作って貼り込んでおいた．

Collatz Tree Generatorの最新版では，所要時間が24時間を超えた場合には日数を表示するようにした．これで原理的にはいくらでも長時間のテストができることになったので，予備機と開発機にそれぞれかなり規模の大きなテストを仕掛けてみた．予備機は15時間経過して32%，開発機の方は同じく15時間経過で4.2%だ．予備機のテストはあと2日くらいで終わるだろう．開発機には2^32という検証テストを仕掛けている．これが完了するのにはあと2週間くらい掛かるという見通しだ．それでも，2^32までのテストを通すというのは，「当面の目標」だったので，それが単独で可能ということになる．

いや，テスト開始時の奇数番号は1よりもかなり大きいものになっているから，実際には2^32をかなり超えたものになるはずだ．いまの目標値は5301601377だが，電卓で調べれば2^cの値を取れるだろう．mmm…32.4という数字が出た．大雑把には2^32のオーダーということになる．ちなみに，2^32=4,294,967,296だ．テスト範囲（検査回数）を2^cで設定するようにしたのは，大きな数字を打ち込むのが面倒と思ったからだが，値を設定するようにした方がよかったのかも…

2つもボケを連発してしまった．一つは，「Verification Testで検証に失敗」の件で，これは明らかに，うっかりどこかのボタンを押してテストが停止していたのを「検定に失敗」と誤認したものだ．画面に「Verification Failed」と出ていたので錯覚するのも無理はないとも言えるが，その場合にはメッセージパネルが出るはずであり，単純な停止とは区別できたはずなのだが…B面ではVerifyボタンはStopに変化するが，それ以外のボタンではラベルを書き換えていない．しかし，他のボタンを押しているのならその検定を実行しているはずだから，当然RTFテキストボックスの内容も書き換えられていなくてはならない．

V1.05, V1.06, V1.07のすべてで問題の区間でエラーが発生していないことを確認しているので，原因がうっかりテストを止めたことにあることは間違いないが，他の検定を実行しないでそれが可能なのか確認しておく必要がある．⇒いや，B面でVerificationを実行しているときには，他のボタンはすべて隠蔽されていて，アクティブなボタンはVerifyから変化したStopボタンしかない．実際，これを押して止めたことは明らかだ．障害が起きたバージョンで現物テストしているのだから間違いない．このときの状態は確かに騒動が起きたときの状態と同じになっている．StopボタンはVerifyに戻り，RTFボックスにはVerification Test Failed!が出ている．メール送信ボタンはアクティブになっていて，表示されたテキストのボトムはThanks in advanceだ．

最新版ではこのような場合には，Verification Test Stopped at xxxx のよな表示が出るようになっている．進捗率と所要時間も表示される．停止した場合にも，その結果を送信することは意味があるから，Click…Thanks in advance となっているのは問題ない．メール送信ボタンも送信可能になっている．まず，これでよいのではないか？

もう一つのボケは，「Facebookに2000人分の友だちを抹消されてしまった」という騒動だ．これは明らかに勘違いで，数学基礎etcにコメントを付けようとしてログインしたとき，常用のアカウント以外の別のアカウントでログインしていたためだ．ただし，このアカウントは長期間放置されていたもので，パスワードも忘れ，変更手続き中だったのだが，マイクロソフトからは認証を拒否された状態になっていた．

アカウントに登録された情報との一致が認められる有効な身分証明書をお送りいただけるまで、このアカウントへのアクセスは認められず、お客様のリクエストにはお応えいたしかねます。

これは，ウェブカメラで撮った顔を左右に振る動画とパスポートの顔写真が一致しないと判定されたためだが，パスポートを更新するお金もヒマもないので（その必要もなくなった）放置していたので，本来ならログインできないはずなのだが…上記の拒絶通知の日付は2021/12/28で，その後，2022/01/04に「アカウントのロックが解除されました」というメールが入っていた．これは，頻繁に入ってくる「いつもと違う場所からFacebookにログインしましたか？」という通知に似ていたので，多分同種のものと思って見過ごしていた．このメールがoutlook.jpアカウント向けのものであることに注意すれば分かったはずなのだが…ともかく，古いFBアカウントが復活したことは喜ばしい．

確かにこのアカウントは使っていた痕跡はあるが，復活させようとしていたアカウントとはまた，別のものだ．わたしが復活させたいと思っているアカウントはプロフィール画像に百舌鳥の写真を使っているもので，アカウントは本名で登録されている．theory-edgeなど，過去の数学領域での活動はすべてM.N.で行っていたので，これを使いたいと思っているのだが…このアカウントではそもそも，メールアカウントとして何を使っていたのかも分かっていない状態だ．（時期的に見て）AYANETのアカウントである可能性はほぼないとは思うのだが…AYANETのアカウントはとっくの昔に死んでいる．

AYANETに連絡を取って，このアカウントを復活させるということも考えられなくはないが…それができれば古い友人たちとのコンタクトを復活させるのにも一番早いのだが…AYANETとはもう10年以上前から解約交渉を進めていて，ずるずるとここまで来ているのだが…まぁ，もちろんコラッツ問題の賞金が入ってくれば，恒久的にこのサイト（冷たい森）を維持することも難しい話ではなくなる，とは言えるのだが…

Facebookから電話番号変更の通知が届いた．OutlookのアカウントとGmailのアカウトで同じ番号を登録しているためだが，古い電話番号を「他の人が登録しています」という状態になっている．Outlookではすでに電話番号を変更しているので，上記のモズアカウントだろうか？Facebookは本来実名登録が原則だ（だった）が，実際には複数アカウトの使い回しを認めているようなので，多分同じ番号でも通るだろう．（アカウント分だけのスマホを持つなんて不可能だし…）

最新版の動作に一つ問題がある．Verifyを実行して，ボタンが「Stop」になっているとき，これを押すと停止してStopped at xxxx が表示されるが，その直前に何かのダンプが瞬間的にスクロールしている．おそらく，Stopを押したタイミングではまだ検証論理が別スレッドで走っているから，このタイミングでフラグが落とされたためにダンプが可視化されているのではないか？これは画面が停止したときには上書きされているので，実害はないと言えばないのだが，あまり芳しくない．

アノーマルな停止の仕方ないし出力画面の更新には複数の場合がある．①Stopボタンが押されて停止，②検証テストが失敗したために停止，③実行時なんらかのシステム障害が発生して停止，④メール送信エラーが発生してエラー情報をダンプ．⇒始業時バックアップと仕掛り版で異なる動作になっている．どこかいじってしまったのだろうか？⇒確かに一箇所修正が入っていた．Running_Click_1の冒頭で

If Working and Not Runflag Then

となっているところで and Not Runflag を削っている．このように修正すると，Stopボタンを押したタイミングで例外が発生するようになる．オリジナルではStopボタンではこの論理を通らない．Working というのは，検証テスト中でかつ，検査ルーチンのGetTheSequenceとGetTheNumberのペアを実行中という意味だ．Runflag というのは，検証テスト中という意味だから，どこかでRunflag が落とされた場合には無視するという意味になる．しかし，もう少し進んだところで出口に向かうようになっている．しかし，この論理もややおかしい．出口に分岐する前に実行しているのは各種パラメータの初期化だが，ここで開始時刻なども設定されている．

しかし，それにしては正しい値が表示されているようにも見えるのだが…おそらくこれは，上書きされているため正しい表示になっているのだろう．本来はこの処理はフラグだけ変更して抜けるべきものだと思う．この意味で上記のNot Runflag を外した修正というのは正しい．⇒Not Runflag を外すことで余分な処理を実行することはなくなったが，逆につねに Test Completeになってしまう．RunFlagを落としてやればよいのだろうか？⇒そのようだ．気持ちよく止まるようになった．

これ以外のアノーマルケースの動作も確認しておこう．②は問題なく動作する．②の検証テスト失敗と，③の実行時システム障害は本質的に同じだ．③ではたとえば，整数演算でエラーが発生するなどのことが考えられるが，メモリ不足を除けば，これらすべては論理ミスということになると考えられる．メモリ不足は避けられないが，これもある意味では「検証テスト失敗」と呼べなくもないので，同じ扱いでよい．メール送信エラー時にはすでに検定は完了しているのだが，その後に発生したエラーをログとして記録するという趣旨なので，現状でよいと思われる．

メール送信結果はメッセージパネルで通知されるが，ユーザとの応答をテキストボックス上でやっているのだから，ここにも何か残した方がよい．⇒対処した．これで完成だ！リリース版を起こしてみよう．⇒所要時間は24時間制になっているが，24時間を超える場合もあり得る．dayまで表示するようにしておいた方が安全なのではないか？⇒対処した．一日を超える場合にだけ日数をdays.hh:mm:ssの形式で表示するようにした．これで完成というところかな？

このパッケージには，高さ8の3-正則コラッツ木のサンプルをPDFファイル形式で添付する予定だ．Collatz Tree Generator のCSV出力をゼルコバの木にインポートして，CubePDFに出力し，LibreOfficeで調整したものだ．全766点というゼルコバの木としては大型のサンプルになったが，「正則コラッツ木」というものがどういうものか，直感的に理解してもらうにはちょうど手頃のサンプルではないかと思う．V1.1.0とした．今度は24時間を超えても対応できるので，予備機では少し欲張って2^28という設定で仕掛けた．24時間くらいあれば完了できるのではないかと思うのだが…

開発機にも仕掛けておくことにしよう．予備機の受け持ち区間の続きをやらせることにする．こちらは，ちょっと無茶だが，2^32まで仕掛けてみる．スタート時点ですでにかなり大きい数になっているので，どういうことになるのか…まぁ，一種の限界テストないし耐久テストということでやってみる．⇒さすがにこれは少々無理っぽいという感じもする．いつまで経っても0.01%まで上がってこない．⇒予備機の方は，30分で1%くらいなので，1時間で2%として，50時間，ということは丸2日は掛かりそうだ．開発機の方はもっと遅く，30分でわずか0.15%だ．うまく行っても，3時間で1%くらいだろうか？何日掛かるのか見当もつかない…1ヶ月は掛からないとは思うが，1週間では終わらないだろう．

予備機に仕掛けておいたVerification Testで検証に失敗している．

Verification Test for the Collatz Tree Structure ( 22/01/16 18:00 UTC )
Start From 402654307 upto 469763169
Total odd number count: 33554432
Big number : 2194137831130865
Max degree: 14 @ 2102744405
Tree height: 361 @ 423186581
Time spent: 03:36:36
Verification Test Failed!
Click the mail button above and send the result to us (babalabos@outlook.jp) !!
If you have any additional infomation, use the colored textbox as a sticky ote.
Thanks in advance...


Enter any additional information here.

サイトの掲示では，すでに469763169までは検証完了となっていたので，402654305まで巻き戻した．このエラーが発生していることは昨晩中に確認されているが，すでに少しアルコールが入っていたため，そのときどう対応したのかよく覚えていない．レポートは送信されているので，「メール送信」ボタンはクリックしているようだが，パネルに表示されているテキストには少し不審な点がある．上掲のメール本文には

Start From 402654307 upto 469763169

とあるが，画面ではこの行の後ろの部分「upto 469763169」が欠けている．

このテキストが表示されているRTFテキストボックスは読み取り専用で，間違っても上書きしたり，修正したりすることはできないはずであり，うっかり消してしまうようなことは起こり得ないはずなのだが…念のため，スクロールして下の部分もスクショを取っておいた．

ピンクのテキストボックスは書き込み可能で，「VAIO2 FAILED」の文字列はわたしが後から書き入れたものだ．ただし，「メール送信」ボタンは一度しか使えないため，この画面内容は送信されていない．ともかく，障害が再現可能かどうかを見るために，開発機で同一設定のテストを開始したところだ．ただし，走っているのは最新版のV1.07でエラーが起きているのはV1.06だから，必ずしも再現できるとは限らない．エラーが発生した実機でV1.06を走らせて再現性を見ることにする．

RTFテキストボックスはRead Onlyのはずだったが，書き込みできてしまう．これはかなりまずいと思う．また，エラーが発生したときの進捗率が表示されていないのも問題だ．Odd numberに表示されている423186581という数字はエラーが発生したときの対象となる奇数番号とみられるから，この数字から開始してエラーが発生するかどうか確認できるはずだ．ともかく，このエラーは最重要なのでじっくり取り組むことにしよう．コラッツ木構造に何らかの欠陥があるとすれば致命的だが，修正ミス，その他の理由も考えられる．

現行版で423186581からテストを開始してみたが，再現しない．もう少し若い番号から初めてみよう．1000番ないし10000番前から開始してみたが再現しない．V1.06に戻って確認してみよう．どうも，この版はバックアップされていなかったようだ．あるいは削除されてしまったのだろう．EXEは残っているが，パッケージが見当たらない．⇒EXEを走らせて再現を試みたが，再現できない．⇒この一つ前のV1.05で試してみよう．今回は実機と完全に同じ条件で走らせてみる．予備機では障害発生までに3時間36分掛かっているのだが，開発機ならもう少し速いだろう．この版ではすでに「Test Failed」を表示するようになっているので，条件はほぼ等しいと見てよいはずだ．

V1.05とV1.07を開発機に仕掛け，V1.06を予備機で走らせている．予備機では設定を間違えていたためやり直しになっているが，開発機のV1.07はすでにエラーが発生したポイントを通過している．⇒当初は検証テストが失敗して奇数Nとそれから計算したコラッツ木枝番号数列から得られる奇数N’で不一致が生じた場合，当初はStop文で停止するだけになっていたところ，V1.06辺りからエラーメッセージを表示するように変更している．このとき，エラー処理の動作を確認するために，ある条件が成立したときにはこのエラーを発生させるような論理を暫定的に組み込んでいるが，もしかしたら，この仮修正を残したままリリース版を起こしてしまったという可能性もある．

ただし，もしそうであるとすれば，その条件はたとえば，対象の奇数があるきりのよい数より大きくなったときとか，カウンタがあるきりのよい値を超えたときにエラーとなるように作っているはずだが，エラーの発生状況から見るとそのいずれにも該当していない．本命の予備機で走らせているV1.06はまだ6%を超えたばかりで，障害地点に達するまであと3時間は掛かる模様だ．最新版のV1.07はすでにこの地点をパスしているので，「コラッツ木構造に何らかの欠陥がある」可能性は少ないと見ているのだが…

Facebookで2000人近くいた友だちをすべて抹消されてしまった．グループ登録も消え，メッセンジャーにも何も残っていない（発信できなかった下書きが1本だけ残っている）．数学物理etcに山本氏が投稿した「あのシュレーディンガーが、実は小児性愛者だった、という話。」に付けたコメントが虎の尾を踏んだのだろう．わたしはネット上の住人なら誰でも知っているような「公知の事実」しか書いていないのだが…https://www.facebook.com/groups/2354748741306929/posts/4738902149558231/　辛うじてアカウントだけは残っているがFBからすればいますぐにでもパージしたいところなのだろう．まぁ，わたしはFBと刺し違えるつもりはないからね．

ごみ箱からRel 2022-01-17というフォルダを2つ見つけた．もしかしたら，この中にV1.06のソースコードが入っている可能性はある．しかし，開発環境では最新版を実行中なので，それが終わるまでは開くことができない．いま，96%というところをやっているので，ほどなく終わるだろう．⇒終わった．これはV1.06でエラーが出た領域の再試験に当たる．いや，おかしい．アプリは閉じたのにまだ走っている．V1.07と思ったが，走っているのはV1.05の方だ．こちらは，まだ15%しか進んでいない．

VSのインスタンスをもう一つ開いてみよう．［ごみ箱に残っていたフォルダは］2つともV1.06だが，一つはStopで止まるだけのものだ．もう一つはエラーパネルを出すようになっているが，動作確認用の仮修正は残っていない．予備機にはV1.06のEXEが2つ残っている．いまテストしているのがそのうちのどちらなのかは分からない．もし，新しい方なら多分停止しないで最後まで走ることになるだろう．古い方であれば，同じ障害が再現されなくてはならないはずだ．しかし，仮に障害を再現できたとしても原因を突き止めるのはかなり難しい．

すでに予備機で走っているテストは障害ポイントをパスしてしまっているので，おそらく新しいバージョンの方なのだろう．古い方を立ち上げて試してみよう．いや，見ている場所が違う．古い方というのは，BlackHawkのフォルダだった．⇒もう一つのケースとしては，単純にボタンを2度押しして停止しただけという可能性がある．ノーマルに終了したとき以外はすべてVerification Test failedを表示するようになっているので，何かの理由で停止したのを忘れていたのかも知れない．⇒いずれにせよ，単に打ち切った場合とエラーが発生した場合を切り分けるようにしなくてはならない．

メールを送信しようとして，エラーになったような場合，エラーメッセージの内容がメール本文に書き込まれるようになっている．検証テストでエラーが発生した場合も，例外を発行してエラーハンドラで処理するようにした方が安全なのではないか？こうしてあれば，メール本文を参照することで本物のエラーか，単に停止しただけなのかを読み分けることができる．どうも，いまのところ，状況判断した限りではテストを打ち切っていたのを忘れて，ないし，うっかり止めてしまったのを，画面上の「Failed」というテキストだけを見て勘違いしてしまった可能性が一番高いような気がする．

▲Odd numberが空の状態でVerifyボタンを押すとハンドルされていない例外が発生する．⇒関数の冒頭でOn Error GoTo を実行すると，エラーが反復発生するようになる．⇒ボックスが空でないことをチェックして警告を出すようにした．

B面のDegreeとTree heightはInt32の範囲に限定するという仕様になっているが，内部計算でそれを超える場合が考えられる．従って，内部では従来通りBigIntegerを用いるようにした方がよいのではないか？⇒一度バックアップを取ってから修正に入ることにしよう．⇒いや，とりあえず，そこまではよいのではないだろうか？確かに，32767×32767の木をくまなく調べればIntegerで間に合わない場合が出てくる可能性はあるが，Integerの範囲は2147483647なのでまず，大概のところはカバーできるのではないか？⇒当面は現状のままとする．

▲Collatz Tree 3-8-766.zelを人名枠幅を調整してから印刷しようとして，GetPageCountのエラーになる．

Collatz Tree Generatorはほぼ完成に近いと見られるが，まだ多少未整備のところが残っている．というか，Get the Numberの出力に修正ミスがあったので対処した．未整備な点としては，①Get the SequenceでランタイムにTree heightとそれに対応する最大ノード番号が更新されない，②Truncated treeも同様という点だ．①は終端ノードから1に下降する手順になっているため，原理的には計算が完了しないと高さは決まらないということになるのだが，途中経過として表示しても問題ないのではないか？②に関しては，Get the numberと論理を共通化すれば解決するはずだ．⇒いや，同じ論理を使うという訳にはゆかないのではないか？Get the numberとGet the sequenceではチェーン上のノードだけを見ればよいが，Truncated treeの場合，周辺ノードが最大ノードになる可能性はある．

大体収まったのではないかと思う．冗長な論理が入り込んでいないかチェックしておこう．⇒リリース版を起こした V1.06 Rel 2022-01-17．これは基本的に最終リリースに近いのではないかと思う．⇒リリース版を走らせて，32767×32767のコラッツ木生成をやらせてみた．Hideをチェックして，ダンプ出力を抑制すると，かなり速くなる．以前は1点処理するのに小一時間掛かっていたが，わずか16分で150点以上を処理している．Max tree heightは135なので底に達するまでにはまだまだ掛かりそうだが…B面のVerificationもなんだか速くなっているような気がする．Upto 2^16がx分x秒で終わった．これなら2^32を一息で片付けることもできそうだ．⇒いや，それはあまりにも甘そうだ．実際，1分走らせても進捗は0.01%に満たない．2^28くらいならある程度目に見える進捗がある．

▲A面を上限の限界で走らせて，停止したところ，応答なしになってしまった．⇒しばらく放置して復帰した．問題なさそうだ．再帰から戻るまでに時間が掛かっていたのだろう．

さて，またマニュアルに戻ることにしよう．⇒B面の画面レイアウトをもう少しだけ変えることにした．B面には機能が4つあるが，それぞれの機能の相互関係を飲み込まないとこのツールは使いこなせない．一番分かりづらいのがVerificationなので，それを他の機能から区別するために，できるだけ離すようにしてみた．現行はこんな感じになっているのだが…Get the sequenceとVerifyの垂直位置関係を逆転させて，Get the sequenceと他の処理の一体性を強調するようにしてみた．

上の図ではGet the sequenceボタンとメールボタンがくっついてしまっているが，デザイン画面でははっきり離れている．このマシンはどうも画素のアスペクト比の関係なのか何か分からないが，デザイン画面通りの表示にならないところがある．⇒Verification testではOdd numberを2づつインクリメントするような動作になっているが，テスト終了時には，最後にテストした番号が表示されている．むしろ，その次の番号を表示した方が分かりやすいのではないか？⇒対処した．その他，A面のBuild Collatz TreeとB面のVerification Testを主機能として，ボタンサイズを大きくし，青色（Turquoise）で着色した．⇒これでほぼ完成したのではないかと思う．

A面はこんな感じになった．

このトルコ石カラーのボタン2つが出てくると，「クイックスタート」というシナリオが浮上する．つまり，まず，「黙ってこのボタンを押してみてください」ということが言えるようになる．ともかく，始めることにしよう．もう一度画像の差し替えをやらなくてはならない．これが結構手間の掛かるところだ…

予備機で走らせていたVerification Testで，Verification Failedが出ている．何が起こったのだろう…今日はもう飲んでしまったので無理だ．明日，見ることにしよう．

スタックサイズを１GBに増大させた．通常は1MBくらいで走っているので，千倍に拡張したことになる．巨大数を扱う処理を再帰実行しているので，スタックが巨大化するのも避けられない．再帰の深さに関わるのは木の高さだが，画面上でInt16より大きい数字は入力できないようにした．最大でも32767までだ．従って，このプログラムで生成できる最大のコラッツ正則木は枝数32767x樹高32767ということになる．この設定で動作するかどうか確認しておこう．⇒走っていることは走っているが，ノード１個を処理するのに32767の枝を派生しなくてはならないので，有効ノード数1の状態でMax numberの書き換えを反復する状態がひたすら続いている．

時間も，1ノードを処理しないと更新しないため，経過時間ゼロ秒の状態が続いている．小さいサンプルなら余分な処理が入ってもそれほど負荷にはならないし，巨大サンプルの場合はどっちみち時間が掛かるのだから，時間ロスにはなるが経過時間が見えるようにした方がよいのではないか？⇒EXEを作って走らせてみた．開発環境よりはずっと高速で見ていても心地よい．Max tree heightは0のままだが，これが1に変わるのにどのくらいの時間が必要か？それが分かれば，その値を32767倍すれば最初の葉に到達するまでのおよその時間を見積もることができる．そこまで計算できればあとはほとんど所要メモリは一定だから「時間さえ掛ければ計算終了可能」と言える．

最初の１ノードの計算の中ですでに相当大きな数が生成されているはずだが，いまのところはMax Numberは途切れなく更新されているので，桁数が32767を超えるほどの巨大数は出現していない模様だ．（Max node countはすでにその範囲をはるかに超えているので空欄になっている）10進桁数で32767超と言えば超巨大数というしかないが，その数をテキストとして保持するだけでも32Kくらいのメモリを要する．（BigIntegerは数それ自体をバイト列として保持している）

14分を経過したが，まだ最初の1ノードの処理が終わっていない．1ノード処理するのに1時間掛かるのではないか？そんなことになったら，最初に木の底に着くまでに途方もない時間が掛かることになり，すべてを計算するのには一生掛かるなんてことにも成りかねない…まぁ，一週間程度で終わるのなら仕掛けておいて放置ということも考えられるが…現在，テント村ではユーザに「検証テスト」への参加を呼びかけているが，むしろ，この正則コラッツ木生成の方をやってもらった方がよいかもしれない．正則コラッツ木も部分木を出力できるようになっているから，作業の分担は可能だ．

Root numberは巨大数を受け付けるようになっていただろうか？※ DegreeやTree heightはInt16の範囲でよいとしても，ノード番号に巨大数が入力できることは必須だ．⇒問題なさそうだ．と言っても表示できる数の範囲を超えた場合にどうなるのかは分からない…⇒1時間14分が経過してMax tree heightは1に変化している．Valid node count=2は2番目のノードの処理に入っていることを示している．正確な時間は分からないが，およそ1時間あれば1点を処理することはできそうだ．それにしても，木を垂直に登って（表示では下って）葉に達するまでには少なくとも32767時間=1365日＝3.7年も掛かってしまう．それから，この巨大木のすべてのノードを訪問するころには，すでにこの地球は存在していないかもしれない…いやはや…

※昨日のログに出てくる5303桁の巨大数を入力してみた．問題なく走っている．D=3，H=7という設定で382個のノードの出力を34秒で完了した．ダンプ領域を隠蔽すれば3行で完了する．ただし，5303という桁数は，テキスト入力ボックスでレンジ外となるInt16の最大値から見るとほんの端切れだ．32767桁なんて数字は見たくもない…

現行ではA面画面下半分の隣接リストはノードを1個出力するまでは更新されない．しかし，これではテスト中のサンプルのように1ノード出力するだけで1時間も掛かるようなサンプルでは画面がまったく変わらないことになってしまう．これは分岐枝リストを生成する段階で出力すべきではないだろうか？⇒対処した．

32767×32767の最大コラッツ正則木を開始して5時間45分，Max tree heightは5, Valid node countは7になっている．つまり，現在7個目のノードを処理しているところだ．平均してノード1個につき，1時間以内で終わっていることは確かだろう．3の倍数ノードが1個出現しているのに，Void node countが空欄になっているのはなぜだろう？ノード１個のサブツリーだけでレンジオーバーになってしまったのだろうか？有効ノード数９個目で5時間54分．これを360分で8個と見れば平均1個45分くらいになる．順調に走っているが，ここで一旦打ち切っておこう．

ノード1個分の処理の中でスクロールするようになったが，こんどは少し重過ぎ感が出てきた．一時的に止めることもできるようにしておこう．多分，スピードはかなり違うはずだ．⇒止めるのではなく，枠全体を隠すようにした．これで倍速くらいにはなったが，目覚ましく速いというほどでもない．もっと高速化するには書き込み自体を止めなくてはダメだろう．⇒対処した．これなら更新されているのはMax numberだけになるのでかなり速くなる．D=3, H=12で17倍速くなった．

リリース版 V1.05 を起こしたが，まだアップロードしていない．この版はマニュアルと同時公開することにしたい．動作確認もまだ十分ではないが，マニュアルを書きながらチェックすることもできるだろう．予備機と開発機にはそれぞれ受け持ち範囲を分け合って検証テストを仕掛けた．開発機の方が速いので2^26とし，予備機は2^24で走らせている．同時くらいに終わってくれるとうれしいのだが…さて，これでようやくマニュアルの編集に戻れる．画面が少しだけ変わったので，画像を差し替えるところから始めなくてはならない．

▲Collatz Tree GeneratorのDegree欄に大きな数字を入力して，メモリ不足エラーのパネルが表示された後の動作が悪い．画面が薄色のハング状態になっている．⇒再現しない．というか，開発環境ではメモリ不足ではなく先に整数レンジオーバーが発生している．サブノートではもっとずっと小さい数で障害が発生する．Degreeに1111111を入力してGoでエラーも出さずにハング状態になる．おそらくメモリ不足状態と思われるが，かなりまずい．開発環境では長整数の範囲ならほぼ無制限に動作してしまうため，再現できない．現在でもぎりぎりというところなので，サブノートにVSをインストールするのはかなりしんどい．

しかし，エラーも出さずにハングというのはかなり問題だ．サブノートは元々メモリが乏しいところにLibreやOpen Live Writerなどを開いているので逼迫しているのだろう．メモリ3.9GBのところ，46%使用して残り1.8GB，開発環境では15.7GBの36%を使用して残り5.6GBというところだ．何か余分なアプリを起動して追い込むことはできるだろうか？VS2017を立ち上げたら逆に空き容量6.4GBと増えてしまった．いや，読み違えている．数字は空き容量ではなく，使用中メモリ量だ．VS2017とVS2019を複数個立ち上げてデバッグモードで走らせてみた．再現できそうだ．メモリ使用量10.4/15.7GB(66%)という状態だ．

CollatzTreeStructureという再帰関数の中でハングしている模様だ．ハングしているというより，応答に時間が掛かっているということだろうか？⇒ここでは一行分の分岐枝リストを作成しているので，1111111個ものリストを作るのに手間取っているようだ．しかし，開発環境ではこれより遥かに大きい数字を与えても楽々と走っているので，メモリが不足しない限り時間的には問題は生じていない．起動していたプログラムを終了させてほぼ初期状態にまで戻したが，回復しない．ただし，ハングしている訳ではない（ループは回っているが，解放されたメモリの割当が回ってこないようだ）

このような状況を回避するためには，最初にメモリ容量をチェックして処理に入らないようにするしかないような気がするが…仮想記憶と実メモリの間でスラッシングが起きているようだ．一度このトラップに堕ちると這い出せないようになる．⇒ループの中にDoEventsを入れてみた．これで，少なくともMax numberが更新されるようになったので，システムが停止していないことだけは目に見えるようになった．これしかないのではないか？Degreeが1111111になると，扱う数字も巨大なものになるので，バッファサイズも半端なものではなくなる．

Stopボタンは応答したが，処理は停止しない．ループから脱出する機構がないからだ．ループの中でStopFlagを見るようにした．Quitボタンも効くようになった（２度押しする必要がある）

▲Tree heightに1111111を入力してGoで「BigInteger cannot represent infinity」というエラーになった．Max node countがオーバーフローしているのではないか？MIN = System.Math.Pow(D, H) / 3 + System.Math.Pow(D + 1, 3)という計算の中でエラーが発生しているようだ．しかし，これより大きい計算でエラーが出ていないのだが…⇒計算式が違う．一方はBigIntegerの関数を使い，他方ではSystem.Mathの関数を使っている．System.Mathを使ったのは，べき乗に実数値を使う意図があったためではないかと思われる．

動作するようにはなったが，Max node countとVoid node countは空欄になっている．テキストボックスの範囲を超えているのだろうか？⇒Max tree heightが60台でこんなに遅くなるのも疑問だ．しかも，停止しているはずなのにまだ動作しているように見える．「The value could not be parsed」というエラーまで出た．StopFlagは立っていない．GoボタンのラベルはGoに戻っているので，停止していなくてはならないのだが，おそらくStopFlagのリセットがループからの脱出より先に来てしまったのに違いない．どこかで待ち合わせする必要があるのだろうか？それもかなり厄介な話だ．

テキストボックスの最長文字列は32767になっている．Int16だ．Max node countとVoid node countの最長文字列をInt32の上限の2147483647にしてみた．しかし，Tree height は11111以上にできない．樹高が11111のときのMax node countの値は，以下のような巨大数だ．しかし，それにしてもInt32の上限に達しているようには思われない…実質的にはInt16で切られているのではないだろうか？

2953605235887922076986378442975100733421380433595488436437675563862279339636402284171077108640824492567945743660848308432773274251758294134422272781393529260708423985567074562376453698742113143788729790540670032661983383583264784373515863947681418431231600872837603844688035862251750065151097207961708009175997851643046165387328678207210679516050903812546334558591851764497664676434996294739662557148059693600289454149489147537316076690357353342068905966545282831648439149007479683084332895809064434398262904074105454182349778021798603400218224012863909260258462677169061262207288629959430375345537969555899094212302491008931013324401565581391038230449877641472497396251209333870828659780033640482414624459293308630820964721219830209788127320707309301681050799520792563039769351003070781921104941811308840451608085583180556595173507563999097055183333070730416445616170775220884250852997371330663007063757479850908482270876120591837949660659133837577438463791152489190083042247316022362886246805301711608002272205422719760380408437671657032815750474487423483498363174469587702435709535117807694637079869252054221254536755904380380985252727687649666702323026878447758068804635813294095679985543884226912628994953823505112046464129504178964133835215465031774986825229329761879793655236633325596314044479287971111236288766804874934999938484483937562652945979258855713992445279787472903892281958917369815092346326602772090535995278792584898576568153322660990794248744827214825337234481591700169509140254358089227959966817229151527837339001885588119162292660200830769862465716148422912721579573038694948415443492285328166231082320350059283262652985674275598722661958799384211057329107359791498334557558560258714734439979843307793166639365444986518526924384730689227896436396096357395407544931568582924892540786158542235973075609676537844404439600687921946142907192647614499377349848850513517788008144494605654547439690629060631724088751397606044320763618365145817682733085421083431774025971183090722932894166629388596212316160143319795602912480175075409572386253590500334523171706468488045531728011595893150716261348543344640166810158266971949803948342139650655350564626451329461151437822257367066847250992798971329661941975427279965603581351442701086297157300538857447608584554143292165350648005988680626688349013866643831271709858946053565730983856077081716030583714950887817203845332638278612891501472276916864209046254611194222890041834666609541019595133400489876280631300134821296089683541508426428594268228575225420579612130414488621064249863966431842166639318773020289801201248366877754830826448862809207535850691295043275358832481115753621755050417391468028791428843327503991373967071851724262628069792791065793134175244348237391306264487253705979319157311567888600768540933159629065962995209389368546347265876253769080008598829898780872014395921395727278532600477043952800427889864968443913001038657282221865623607645562360730736414508951615648092518934014281607239894179623091424511251115337104605065839496302258322185897396815351399498349920264296496134618678347372408304966280634973683448066379905815275840324070164174242809779422497980171988148842731872181629065283717474788073878450911239741425222249958904900692783463476747864375695613682259325270526249118724337466530615938656708130291862191416740689565391094635610051841433240092405122156874017910491182033892260220441100264507685824802444484621594701088592785835096120216514057502113076922130743203033833069070028073141574063721534019564154479990326717129311132662935426153909541359843848917140940551876132675219100118915889607335646451806654176630835860564184272993298885348106439939578851127338437684802282058581358868794086951785329107919027811250248110746858060524232666133190458093064491349488686944036427745131309511175361984018759355978415336382054185991527706132765928119294414252004883948864008920559325937149217599625315043322613614393523978796623311588863968094289173510990083408051502486424871471964517627477082203831670190482657688399190838923813657762032472370166556571429057199444408246965460008497381707035856540193640021018820983604136075328275010888926432709885422710734969202215047088553751198230025881935299085760864791201519439182988748575126920778498827087113284245484151598692958763612311165248724519642793982683222470278785737605066963638496108060614540655520591242769528306037560838304489683930072041808655325046364233006472164787060631355845656133693737601430524816677695199872457304163426405676813700516660168836966244165750847437239372169049314609601750384916934753863323201898860653937841928677798135923683817633828305142429696075932838623304791581633313873877280091778676006497945320722607622547438850541848185106481101488583987172006668154747455829415798455013034774418900843038862678955383301601531678406267258173795652512152421235416421647198531819646250017299304404970241298175160691377235910976425551378432785749376613742284507244792812213890223878080463244824786378920987086789507258558505600283857905639541827286114346438894763810209179694695250275930809802266340778340070866781411418432407505324767755570085460106365991790678933763476949878705506609504313910548052486237255855035208105862462188254027577531060106970782819991599365065699230421487997765939432354565453872215039358770395720050317565976720

これは表示されないというだけで，動作的には問題はないが…Tree height=11111でスタックオーバーフローが発生した．しかし，エラーハンドラに制御が渡ってこない．この後，直ちにアボートしてしまうので実害はないとは言え，エラーメッセージが出ないのは不都合だ．

テキストボックスの表示桁数は元の32767に戻した．障害はRichTextのテキストの切り詰めを実施しようとするところで起きている．⇒開発環境ではTree height=461でスタックオーバーフローが発生する．しかし，不思議なことにサブノートでは同じ設定で走り続けている…いや，一度開発環境を落として再起動したら走るようになった．しかし，472では起きる．471なら走るようだ．

on error goto を廃止してtry catchに変えたら動作するようになった．いや，同じだ．CollatzTreeStructureが復帰するところでBranchlist = vbNullを実行するようにして少し動作するようになったが，482で止まる．これ以上はどうしようもない感じがする．480が上限だ．DoEventsが負荷になっている可能性もある．スタックのデフォルトサイズは1MBとなっているようだ．

いや，どうもどこかで修正ミスをしている可能性もある．サブノートでは500という設定で問題なく走っている．一度バックアップに戻って見直してみることにする．⇒どうも状況がつかめなくなってきた．サブノートでは500で走っているのに，開発環境では停止してしまう．一つ前のバージョンに戻ってみたが，同じだ．1月13日バックアップという版では1000では走ったが，10000では落ちた．どうしたらよいか？ソースを比較するために，WinMergeをダウンロードしてみる．日付は異なるが，内容はまったく同じだ．ということはEXEで走るか，デバッグモードで走るかの違いだけということになる．⇒確かにそのようだ．つまり，EXEと開発環境ではスタックサイズが異なるということになる．

EXEでは，1410で落ちた．つまり，そこでスタックオーバーフローが発生したということだろう．せめて，5000くらいまでは黙って走ってもらいたいのだが…デバッグモードでは481で停止する．EXEをeditbinで直接操作してスタックを増やすという手はあるようだ．ビルド中にそれができるとよいのだが…ポストビルドイベントに以下のようなコードを入れてみた．

"$(DevEnvDir)..\..\VC\bin\editbin.exe" /STACK:8388608 "$(TargetPath)"

何も警告は出ていないので動作していると思われるのだが，効果なし．⇒できた．構文が悪かったようだ．7767まで進んでアボートした．再帰実行に入る前にodd配列を空にするようにしてみたが，まったく効果なし．分岐枝リストをパージするのは効果があるようだ．．特に時間効率に影響する．⇒修正箇所は元に戻した．現在の設定値8388608を2^32=4,294,967,296まで上げてみよう．これは４GBに相当する．開発機なら走るが，他のマシンでは無理だ．1GBというのがほどほどというところではないだろうか？つまり，1,073,741,824だ．

Max numberでは巨大数を表示できているのに，Max node countやvoid node countでは表示できないのはなぜだろう？MaxLengthは32767で同じだ．height=11111でMAXは5302文字になる．height=111111では32767を軽く超えてしまうのだろう．MaxLengthを少し増やしてみよう．MaxNumber.textには値が入っているのに表示されていない．テキストは53051文字で32767を超えている．どうも，これが仕様なのではないかと思う．テキストボックスの幅を広げてみたが同じだ．ただし，値はBigIntegerとして保持されているので計算を進めることはできる．

▲リリース版でTree heightに大きな数字を入れたらハングしてしまった．開発環境でも起きる．H=1111111のとき，BigInteger.Powの内部でハングしている．これはこの関数の限界に達したことを意味している．メモリの問題かもしれないが，例外は発生しない．⇒この関数の第2引数はInt32なのでその上限を超えているということだろう．枝数と高さは整数範囲に押さえておいた方がよい．

大体収まったのではないかと思う．枝数と高さを変えたときには，無条件で停止するようにした．枝数と高さはマニュアルでは長整数の範囲としているが，Int16の範囲内に留めることにした．この程度が現実的に見て妥当なところではないか思う．一応これで差し替え版はできたのではないかと思う．枝数3，高さ1000というサンプルを走らせてみよう．⇒2時間走っているが，問題なさそうだ．数字が大きくなるとダンプの1行が長くなり，ほとんど画面に1行しか表示されないようになる．ワードラップが切り替えられるようにできるとよい．

▲タブAが走っているとき，タブBのOdd numberに巨大数を入力→Get the Sequenceのあと，Wordwrapを操作しながらTruncated treeを実行してだんまりになってしまった．また，Get the sequenceでスクロールは続いているが，表示も遅く，degreeやheightがまったく更新されない．⇒ループ内で表示を更新し，DoEventsで再描画するようにした．

▲Verificationを中断したときにも，送信ボタンが出ているのはよいが，検定にパスしたように見えてしまうのではないか？途中で打ち切っても検定成功！が出ている．⇒対処した．

▲B面は他のボタンを押したとき反応がない．Stopボタン表示もない．VerifyにはStopがあるが，他の3つの処理は停止できない．対象が巨大数の場合など，打ち切りが必要な場合がある．Wordwrapの切り替えも入らない．いま，どの処理をやっているのかも分からない．Stopは表示しなくても，二度押しで一度停止するようにした方がよい．⇒対処した．

▲Get the sequenceで初期化→更新していない．⇒対処した．

▲Verificationで3から開始して，ODD<>ODD2で停止した．GetTheNumberの中でOddNumber.textを書き換えている．⇒上記で修正ミス（フラグ操作の落ち）があった．

KCollatz Tree Generator V1.04.zipをownCloudにアップロードした．⇒いや，途中で接続が切れてしまったのだろうか？アップロードできていない．タイムアウトが発生している．しかし，現物は入っているようだ．https://zelkova-tree.net/ownCloud/index.php/s/imIybhMdmva5qO3

サイズをチェックしてみよう．2,371,653バイトで，オリジナルと一致している．すでに公開しているCollatz Tree Generator V1.03との違いは軽微なものだが，コラッツ木検定結果をメールで送信するとき，ユーザがコメントを追加できるようにしているところが新しい．通常は枝番号リストを表示/入力するフィールドに任意のコメントを入力し，追加情報としてテスト結果とともに送信できるようにした．

このフィードバックでは画面上に表示された以外の情報はまったく送信しないようになっているので，ユーザ名やユーザのメールアカウト，その他個人情報や機器情報などはまったく取り出していないが，ユーザは任意にそれらの情報を提供することができる．これだけで，フィードバックとしてはとりあえず十分と言える．

現在テント村のトップにはつねに，The Collatz Conjecture was solved 2022/01/01というページが表示されているが，ここにダウンロード用のリンクなどを追加しておくことにする．このページへのリンクを物理数学etc（談話室）に投稿したら，ページへのアクセスがどっと（と言ってもまばらだが）増えた感じだ．さて，いよいよ，このプログラムのマニュアル作りを始めなくてはならない．とりあえずはオンラインマニュアルになるので，画像をLibreOfficeで作ってOpen Live Writerで本文を作成するか，ないし，LibreOfficeで頭からしっぽまで作ってownCloudにアップロードするかのいずれかということになるのだが…

どちらが楽かということになれば，Open Live Writerの方が使い慣れているのでずっと楽なのだが，LibreOfficeの使い方に慣れるという意味でも，こちらを使う方が正しいのではないかと思う．LibreOfficeはネットにはつながらないので，オフラインで集中して仕事ができるというメリットもあるかもしれない．ともかく始めることにしよう．

LibreOfficeにはHTMLドキュメントというオプションがある．最初からHTML専用のライターだ．⇒図形の配置が思うようにゆかない．アンカーとそこからの相対距離のようなもので位置を決めているように思われるが，ドラッグして移動しようとしてもまったく予期しないような動きになる．このソフトに慣れるまでにはかなり掛かりそうだ．

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

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

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

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

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

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

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

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

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

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

検定結果をメールで開発者にフィードバックできるようにした．ボタンは通常は不能状態になっていて，検定を実施した直後だけ操作可能となる．このボタンを押すと，画面下部の出力バッファに表示されている内容が直接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で見つけることができた．

サイトのWordPressで直接編集したページが，Open Live Writerで読み出せないという問題は，My Weblog Postsの下書きと最近投稿記事を削除してリロードで解決した．予備機で実行している2^24までの検証テストは，13時間47分経過して進捗率81.4%．あと3時間くらいは掛かりそうだが，速度はほぼ一定なのでいずれ終わるだろう．正則コラッツ木生成ツールはすでに公開するばかりの状態になっているが，2, 3まだ手を入れる必要がある．①B面ではExportCSVのチェックを無視する，②ゼルコバの木の最大カード数を3070(D=3, H=10)まで増やす，③検証テストの開始番号をOdd numberで指定できるようにする．④検証テストの結果をメールで開発者宛てに送信できるようにする，など．

ゼルコバの木の最大カード数を3070まで増加させてみたが，デバッグモードではほとんど動作しない．これは，SearchWrongObjectが過負荷になっているためで，リリースモードに切り替えることでインポートに成功した．ただし，「この図面は0.24%以上にはズームできない」というメッセージが出る．これは，描画に使っているメモリ領域に制限があるためだ．しかし，ともかく3060点というゼルコバの木的には巨大サンプルを開くことができた．3正則で樹高は10，ノードの最大値は4861201493781．これをPDF出力してLibreOfficeで回転させて数字を正立させたものを見てみたい．

プレビュー画面に切り替えようとして，「メモリ描画環境用のメモリが不足しているため，生描画に切り替えます」というメッセージが出た．CubePDFで用紙にA0を使っても，31ページにもなる．拡大縮小倍率を3%まで落としてようやく1ページに収まった．「適用」ボタンでプレビュー画面を更新するようになっていたはずだが，描画できていない．倍率には整数値しか入らない．

予備機で走らせていた2^24までの検証テストが完了している．所要時間16時間で1から16777215までのすべての奇数の検査を実施して，それらノードのコラッツ木上の位置を確定した．この検査に関わりを持つすべてのノードの中で最大枝位置にあるものは枝番号12の22369621，最高枝位置にあるものは樹高263の15733191だ．出現した最大ノードは20114203639877．

メイン機の動作がおかしい．Meryを開いているのにスクリーン上に現れない．走っているアプリを全部止めて，Meryとタスクマネージャだけにしても出てこない．Meryが壊れてしまったのだろうか？⇒一度再起動してみる．⇒再起動しても同じだ．何が起きているのだろう？Libreはプレーンなテキストエディタとして使えるだろうか？テキストエディタとして使えるためには，少なくともすべての（主要な）言語コードの読み書きと変換ができなくてはならない．余分な修飾が挿入されないことも必要だ．Meryは軽くて使い易いので愛用してきたのだが…⇒もう一度インストールしてみよう．

確かに何かおかしい．再インストールしたのに同じ動作だ．つまり，起動してもスクリーンに表示されない．考えられるのはデフォルトの表示位置がスクリーンから外れてしまっていることだ．確かに机上のPCの配置を変えて左右のスクリーンを入れ替えているので起こり得るトラブルだ．どう修復したらよいのだろう？⇒最大化したら出てきたので，タイトルバーをつかんでドラッグしたらその位置に収まった．やれやれ，人騒がせな…