予備機の検証テストは11時間走って40％，残り時間16時間24分．フロントエンド機を起動したら，また画面の崩れが始まってしまった．しかも，電源を落として再起動しようとしても立ち上がってこない．もうこれはいよいよダメかと諦めかけたところ，外部デバイスをすべて外して電源投入で起きてきた．そのあとは画面の乱れもピタッと止まっているので，まだしばらくはこれで使えそうだ．
コラッツ核木（Core Collatz Tree）の生成処理を実装した．まだ細かい詰めは残っているが，走っている．コラッツ核木とはコラッツ数のみからなるようなコラッツ木，コラッツ数とはそれから1引いた数を4で割った商が奇数とならないような奇数である．コラッツ核木の別名をコラッツ長子木(Eldest Sons Tree)としているが，系図を読み慣れた人でないとピンとこないかもしれないので，コラッツ放射高速路系（Collatz Radial Highway System）と呼んでみたい．コラッツ木というのは基本的に環状線を持たない放射線状の経路網で合流点以外の交差を持たないことが特徴だが，コラッツ放射高速路系はそれらの支線道路を1本の本線にまとめた幅広い複数車線を持つ自動車専用道路であるとみなせる．
コラッツ放射高速路系の経路状には通常のコラッツ木では行き止まり点（終端ノード）となっている3の倍数が含まれる場合がある．たとえば，3や75などはその例である．コラッツ放射高速路系の経路は通常のコラッツ写像ではトレースできない経路（トンネル）を含むある種の「仮想経路」であり，あまり直感的ではないかもしれないが，ノード数が大幅に減じているので広範囲の奇数の検定を短時間で実施できるとい利点がある．実際，枝数3，樹高12という設定のコラッツ木に含まれる奇数は最大でも1106193406531349だが，コラッツ核木なら…
同じ設定で計算を開始したが，どうもかなりの時間が掛かりそうな形勢だ．Max node countは797161で多分この数字はまった変わらないはずだが，コラッツ核木は基本的に完全正則木なのでこの数値が実際の有効カウントになってしまうためだ（１をルートとする場合にはこれよりも多少少なくなるが…）コラッツ木生成では残り時間をカウントしていないので，あとどのくらい掛かるか予測できないが，ともかく，しばらく走らせてみることにしよう．８分経過した時点の最大奇数は279418798644035773131889で，上の1106193406531349と比較すればどの程度「高速化」しているかがわかるだろう．
おおっ，意外にも短時間で停止した．所要時間24分８秒，有効ノード数は265721で最大ノード数の797161よりだいぶ少ない．差分は531440．これはノード1が5という子ノードしか持たないためだ．最大奇数は595730981401673782972529で前の数から倍増している．ルートノードを5にすると名実ともに完全正則木になる．1をルートとしたときの有効ノード数は最大ノード数の1/3程度なので，この3倍の時間を掛ければ完了できるかもしれない．仕掛けてみよう．どのくらい大きな数が出現するかを見るのが楽しみだ．
コラッツ放射高速路系という命名は直感的で悪くないと思われるが，実態をもっともよく表す名称として，「コラッツ仮想木(Virtual Collatz Tree)」というのを提唱したい．これは物理的なロケーションとは独立に仮想的なアドレスにデバイスを割り付ける仮想化と呼ぶ考え方にかなり類似した手法であり，「仮想化」という考え方に馴染んでいる人には理解し易いのではないかと思う．
コラッツ仮想木を考える最大の利点は，それが完全正則木を構成可能であるという点に尽きる．つまり，あちこちに穴のあいたシステムではなく，完全な均一性を持ったシステムとして扱うことができる．多分この利点は最終的な証明を与えるときに効いてくるだろうう．つまり，「我々の最後の切札」であるコラッツ木の仮想化という方式の導入によって最後のリングが繋がったと言えるのではないか？これにより，理論的な弱点/難点は完全に払拭されたのではないかと思う．あとは証明を与えるだけだが，その前にコラッツ木生成ツールを整備して，コラッツ木生成以外の4機能でもコラッツ仮想木を扱えるようにしておきたい．マニュアル整備まで入れるとまだしばらく掛かりそうだ…
ルートノードを5に設定したコラッツ仮想木生成が完了した．枝数3，樹高12で１時間15分．有効ノード数は797161で最大ノード数と一致している．最大奇数は95374949936989296587566193という巨大数だ．４桁で区切ると95 3749垓 4993京 6989兆 2965億 8756万 6193．無量大数10^68にはまだほど遠いが相当大きな数であることは間違いない．1までのコラッツ数列をトレースすると，
95374949936989296587566193
71531212452741972440674645 [1]
209564098982642497384789 [5]
613957321238210441557 [5]
1798703089565069653 [5]
5269637957710165 [5]
15438392454229 [5]
180918661573 [4]
33922249045 [2]
99381589 [5]
291157 [5]
853 [5]
5 [5]
1 [1]
で13階になっている．1から数えているので樹高が1増加している．しかし，それを除けば仮想木と通常のコラッツ木との間には階数の相違はない．つまり，これは仮想木が実コラッツ木を正確に翻訳したものになっていることを示している．「垓 」の次の「」の字が出ない…フォントがこの字形を持っていないのだろうか？
コラッツ仮想木の実装を進めよう．コラッツ木生成タブの処理はほとんど動作しているが，一部パラメータに未整備のところがある．というか，多分3の倍数のカウントが出ていないだけであとは動作しているのではないかと思う．Void node countもカウントされていない．ルートが５以上の場合はこれで問題ないが，1の場合はMax=Void+Validという式が成立しなくなるので，やはり更新しておいた方がよい．
3の倍数ノードをカラー表示してみた．カウントは40になっている．
女子を選択して部分図に登録し，ノード数のカウントを取って比較してみる．40で一致している．3をルートとしたときにどんな図になるのか見ておこう．⇒ルートは当然3で枝数3を指定しているので，その下に3つノードがある．17, 35, 1137だ．標準コラッツ仮想木のルート5と比較してみよう．⇒3は5の直下のノードでその部分木は3をルーツとする仮想木と完全に一致する．問題ないようだ．Void node countも実装してみたが，数字が一致しない．⇒一致した．3の倍数でも算入していた．
CSVファイル名も変えておいた方がよい．⇒コラッツ仮想木の場合は，CollatzCore.csvの名前で保存するようにした．同じD=3, H=4の正則木でもコラッツ正則木の場合は46点，仮想木の場合は121点と大きな違いがある．これは仮想木が完全正則木になっているためだ．これでタブAに関してはほぼ修正は完了したのではないかと思う．タブBには4つ処理が入っている．修正箇所はできるだけ少なく，かつ既存論理を壊さないようにしなくてはならない．まず，Get the Sequenceから見ることにしよう．⇒一応ここでバックアップを取っておこう．
もう一つ確認しておくことがある．ルートノードに非コラッツ数を指定した場合だ．⇒いや，それはすでに確認済みのはずだ．ルートノードは非コラッツ数でそれ以外は仮想木という構成になったはずだ．たとえば，13をルートとすると，直下ノードは17, 35, 1137になる．53をルートとしたときの直下ノードは35, 1137, 2275だ．13と35はいずれもコラッツ数3の兄弟ノードだが，13がノード３の部分木を完全に引き継いでいるのに対し，53には17は入ってこない．これは53を最右ノードと見立てたときの動作になっているからだ．動作的にはこれでよいのではないかと思う．どんな奇数が与えられた場合にも，その左には無数の兄弟ノードが存在するので，仮想木を構成するのに過不足はない．
Get the Sequenceという処理は通常のコラッツ数列を得るための手続きであり，幹線を通る場合も基本的には段数は同じになると考えられるが，支線から幹線に乗り換えるのに1段必要になるので系図的には1世代高くなると考えられる．あるいは，水平移動を省略して垂直下降して幹線に乗るというのでもよいのかもしれないが…Get the SequenceとGet the Numberは逆手順にならなくてはならない．つまり，GTSの出力はGTNの入力であり，GTNの出力はGTSの入力とならなくてはならない．