月: 2022年4月

「三本桜の復活」というテーマで作業を進めてきたが，ここで大きく方向転換することに決めた．「完全正則木」というアイディアは（少なくとも当面のところ）完全に破棄される．なぜ，「完全正則」というところにそこまでこだわってきたのかと言えば，コラッツ予想問題を解くためにはどうしても，1を出発点としてコラッツ木をボトムアップで構築可能であることを示すことが必要であり，そのためには「完全正則」という縛りが必須であると考えたためであるが，それ自体，ある種の「呪縛」であったと言うこともできる．「仮想木」にはやや変則的なところがあり，「完全正則」から逸脱している部分があるため，それが可能な「完全木」という概念を導入しようとしていたのだが，最終的には「完全正則にこだわる必要はない」という結論に至った．

▲隣接リストをインポートしようとすると，必ず「ライセンスキーの登録」パネルが現れて，キャンセルしても前に進まない．⇒「インポート」機能そのものが，「ライセンス」で保護されているためだ．ゼルコバの木コラッツ特注版はライセンスフリーで公開予定なのでインポートは無条件で可能でなくてはならない．

我々が知ろうとしているのは，「完全正則木」の一般的な性質ではなく，「コラッツ木」という「特殊な木」の性質を調べようとしているのだから，その「木」が「完全正則」でないということを受け入れるしかない．前稿では「長子木」を再定義して，「仮想木」からノード１を除去したものとしている．この再定義は有用である可能性もあるので，一応維持するということにしておこう．つまり，長子木は依然として完全正則木として取り扱うことができる．仮想木とは一般コラッツ木上の兄弟ノードを長子ノードに縮約した簡略木であると考えられるから，仮想木を還元すれば一般木に展開可能であると言えるはずだ．「完全木」に関係するコードをまるごと破棄することになるので，開始プロジェクトはかなり前のバージョンに戻ることになる．

プログラムのタイトルは「コラッツ完全木検定」から「コラッツ仮想木検定」ないし「コラッツ長子木検定」に変わることになる．ここでは一応，Collatz Eldest Sons Tree Experiment というのをプロジェクトの正式名称として採用することにしよう．仮想木検定の最終バージョンを探してみよう．「コラッツ銀河高速道路系プロジェクト」というフォルダにはCollatz Milky Highway V2.0.1 2022/02/11というのが入っている．おそらくこれが最終版ではないかと思われるが，V2.0に入ったばかりなのでもっと新しいものがあるかもしれない．CollatzCoreTreeというフォルダに入っているのはタイトルは上と同じだが，少しだけ新しい．ゼルコバの木のエクスポート機能が廃止され，Virtual TreeがCore treeに変わっている．このCore treeというのは完全木ではなく，仮想木を意味している．ビルド日付は前者が2月20日，後者が2月22日だ．

2月23日にはプロジェクト名がCollatzCompleteに変わっているので，ここで方向転換していることは確かだ．日付入のバックアップではこの他に，CollatzCoreTree 2022-02-22-1というのがある．ビルドの時刻ではこちらの方が新しいので，こちらの方が最新である可能性はある．確かに，バージョンもV2.1.0に変わっているのでこれが最終版と思われる．しかし，オプションのラベルがComplete treeに変わっているので，すでにこの版では完全木に移行しているのかもしれない．いや，内容は変化していないようだ．アドレスコードの区切り文字がコンマからピリオドに変わっているところやボタンラベルがあちこち変わっているなど，新しい構成に移行しつつあることが看て取れる．この版を最新版としてよいのではないだろうか？

ともかく，ここから始めることにする．念のため2月22日頃のログをチェックしておこう．2月22日のログのタイトルは「コラッツ完全木検定と呼ぶことにする」だ．この頃はコラッツ長子木のことを中核木と呼んでいる．いや，少し違う．というより，この版はすでに完全木に移行してしまっている．この記事では「銀河系」と呼んでいるが，そこまで戻らないと抜け出せない．「コラッツ銀河高速道路系プロジェクト」に入っているのはすでに完全木だ．CollatzMilkywayのバックアップは最終が2月12日でかなり古い．いや，もっと新しい版もある．2022/02/20 7:40というのがおそらく最新ではないか？いや，これはすでに完全木に移行してしまっている．⇒ダメだ．頭が完全に混乱している．１→5という単枝しかないのが仮想木だ．もう一度調べ直しだ．

やはり，最初に見たように，2月23日を境目に銀河系から完全木に移行したと見て間違いないようだ．プロジェクト名はCollatzMilkyway→ CollatzCoreTree→ CollatzCompleteのように遷移しているが，CollatzCoreTreeはその過渡期でごく短い期間，多分1,2日しか使われていない．従って，このCollatzCoreTreeというのが，仮想木としての最終版と見てよいと思う．上で採り上げたCollatzCoreTree 2022-02-22-1はすでに完全木に切り替わっている．CollatzCoreTreeというプロジェクト名はほとんど使われていないので，このプロジェクトのフォークという意味で，”CollatzCoreTree”を継承することにしよう．コラッツ完全木検定の最新版はV3.0.0となっているが，このバージョンはここで凍結されるので，新たなバージョンをV3.0.1から始めることにする．

この方向転換はある意味で銀河系に回帰することを意味する．コラッツ銀河系では一般道路を（仮想的に）束ねたものが高速道路であるとしているが，「仮想木は一般木の縮約，一般木は仮想木の展開とみなす」という立場はこれと基本的に等価であり，その関係をより実質的なものとして具体化するのが今回のプロジェクトの目標であると言える．この意味では完全に銀河系路線の継承になっているが，Milky Highwayという名称を用いるかどうか？というところが問題だ．CollatzCoreTreeのアセンブリ名はCollatzCoreTreeになっている…Milky Highwayという名称は結局一度も公式には使われていないので，これを正式名称としてもよいのではないだろうか？タイトルにはMilky Highwayと入っているので，アセンブリ名もそれに倣うことにしよう．

オプションの出力モードにはCore treeが使われている．これは当面そのまま使うことにする．Auto-copy branch ordinal numbersというチェックボックスは廃止する．Export adjacency listはA面と独立にB面でも設定できるようにしておこう．とりあえず，A面はすでに完成しているのではないかと思う．Root numberには2倍数と3倍数は設定できない．いずれも一般木では終端ノードとして扱われているためだ．しかし，仮想木では3倍数は設定できる．これでよいのだろうか？

たとえば，3や75などば3倍数でも仮想木上に存在するが，21や69などは仮想木上のノードではない．21をルートに設定した場合の子ノードは113, 227, 7281などが出現する．これらのノードの親ノードは本来は5なのだが，21という非長子ノードが長子ノードの5の代理人になっているという動作だ．ただし，自ノードより前方にあるノードは21の部分木には現れない．これでよいのか悪いのか，判断に迷うところだが，とりあえず「保留」としておこう．

B面の動作を見てみよう．こちらも特に問題はなさそうだが，汎用アドレスコードには未対応だ．仮想木処理に関してはほぼ現状で完備しているので，今回の修正の本旨は，「仮想木で汎用アドレスコードをサポートすること」にあると言ってよい．それを実現することが，一般木⇔仮想木の対応関係の実装に当たると言えるだろう．

この修正は本来デバッグなしで一発修正で決めるはずだったのだが，結局デバッグになってしまった．あちこちかなり微妙なところがあり，形式論理的なコード操作でカバーできなかった．

▲開始ノードを2に設定してコラッツ数列取得を実行して，IsCollatzNumberで停止する．この関数はNが偶数でないことを仮定している．⇒B面では原則として2倍数・3倍数を含むすべての整数を扱うとしているので，ここで停止するのは不規則動作だ．IsCollatzNumberは仮想木上のノード（長子ノード）をコラッツ数と認定する関数なので，偶数（コラッツ数ではない）は当然偽を返すべきだ．

この関数を呼び出しているGetCollatzNumberはNのコラッツ数つまり長兄ノードを求める関数で，IsCollatzNumberが偽の間はループするようになっているため，この論理では無限ループしてしまう．Nが偶数であるとき，Nの長兄ノードとして何を返せばよいのだろう？標準的なコラッツ木は偶数を含まないので，そもそもNはコラッツ木上に存在していないのではないか？偶数Mが2で割り切れなくなるまで2で除算することで得られる奇数NはMの親なのか？兄弟なのか？

3倍数は一般コラッツ木のノードだが，仮想コラッツ木上に存在する場合もあり，そうでない場合もある．３倍数は完全コラッツ木上には存在しない．3倍数は一般木のノードなので当然親ノードと兄弟ノードを持っている．2倍数は一般コラッツ木のノードではないが，完全木の終端ノードとして表示される場合がある．親ノードは任意の奇数ノードと考えられる．兄弟ノードはこの親ノードPを共有する偶数ノードと考えられる．Pの子ノードである奇数NとPを親とする偶数Mの関係は，言ってみれば異母兄弟のようなものではないだろうか？この意味では異母兄弟の奇数ノードの中の長兄ノードが偶数Mのコラッツ数であると言えないこともない．新版では2のコラッツ数列として以下を出力する．

2
1 [*1]

これは2=1×2^1という計算を表している．１の長子は5である．2と5の間には直接の接続関係は存在しない．もう少し大きい偶数を見てみよう．たとえば，12のコラッツ数列は下記のように表示される．

12
3 [*2]
5 [1]
1 [1]

これで見ると，12の親が3であることは明らかだ．しかし，アドレスコードは以下のように表記されている．

1. 1*2

標準的なアドレスコードは「.」で区切られた正数の並びであるから，上記のアドレスコードは

1.X

のように読まれるべきだろう．Xは詳細付番で1*2という区画を示しているが，完全木上の地番として考えれば，1.1というポイントを示していると考えるのが妥当だ．旧版では2倍数はコラッツ数列取得の対象から除外されているので，偶数が仮想木上でどのような位置を占めているのか（占めるべきか）は分明ではない．仮想木上では一般木上の実親子関係を拡張した「義理の親子関係（養親子関係）」によって木が構成される．つまり，長兄の甥姪ノードはすべて長兄の下に配置される．

話をできるだけシンプルにまとめるとしたら，完全木検定からすべての偶数を排除するというのがむしろ一番わかり易いかもしれない．そうしたからと言って，この論証の正当性はいささかも損なわれることはない．2倍数を含むすべての自然数を表現する汎用アドレスという考え方は魅力的ではあるが，いたずらに問題を難解なものにしているのではないか？アドレッシングという観点から問題をもう一度整理してみよう．

一般コラッツ木は，コラッツ写像（N→N/2，N→3N+1）によって自然に構成されるグラフ（コラッツグラフ）の簡約グラフであり，すべての偶数ノードとそれに隣接する枝を短絡・縮約して得られる奇数ノードのみからなる木である．一般コラッツ木上のノード位置（アドレス）は1からノードNに至る経路上の枝番号の並びによって標識される．一般コラッツ木にはすべての奇数がノードとして含まれる．

仮想コラッツ木は，一般コラッツグラフをさらに簡約したグラフで，同じ親ノードに接続する兄弟ノードはすべて1個の長子ノードに縮約されている．仮想コラッツ木の特徴は（完全）正則木を構成可能であるという点にある．ただし，この正則木にはやや変則的なところがあり，１の直下ノードは5しか存在しないため，厳密には「完全正則木」ではない．仮想コラッツ木はコラッツ数と呼ばれる奇数のみが含まれる．

完全コラッツ木は，一般コラッツ木から３倍数ノードを除去したものであり，完全正則木を構成することができる．汎用コラッツアドレスはこの完全コラッツ木を拡張して３倍数と２倍数を含むようにした「拡張コラッツ木」で定義されるアドレスコードシステムであると言える．完全コラッツ木には3倍数を除くすべての奇数ノードが含まれる．拡張コラッツ木には2倍数・3倍数を含むすべての自然数が含まれる．汎用コラッツアドレスで用いられる枝番号には，2倍数のみをカウントする系統，3倍数のみをカウントする系統とそれらを除外した正準系統の別がある．

新版（完全木）と旧版（完全木）を合体させるという作業を行っているところだが，そのいずれでもないもう一つのバージョンが存在する．タイトルはCollatz Complete Tree Experiment V2.2.0 2033/02/23というバージョンだ．この版はすでに完全木に統一された版になっているが，B面のオプションはOdd numbersではなく，Complete treeとなっていて，この版ではB面でも奇数・偶数の別なく処理することができる．Odd numbersの方が新しいはずだが，むしろデグレードしているような気がする．もう一度開始プロジェクトを調べ直した方がよい．

この版はCollatzComplete 2022-02-24-1というものだ．この後のCollatzComplete 2022-02-25になると，Complete treeというオプションが消えて，Odd numbersに変わっている．⇒この版を取り分けて，CollatzCompleTeとした．もう一度，ここから出直すことにする．この版で12のコラッツ数列を出力すると，一般木では

12
3 [*2]
5 [1]
1 [1]

のように出力され，完全木では

12
3 [*2]
5 [-1]
1 [1]

のようになる．このサンプルには2倍数と3倍数が出てくるので試すのに都合がよい．この版では仮想木のコラッツ数列は取れないが，旧版で3をテストすると，

3      3
5 (1)    5 [1]
1 (1)    1 [1]

のようになる．従って，12から始まる仮想経路は

12
3(*2)
5 (1)
1 (1)

となればよいのではないだろうか？

▲一般木，仮想木，完全木の構成の違いを見るために，印刷しようと思ったのだが，印刷機能が未サポートの状態になっている．横書きサポートに入った時点で止めてしまっている．サンプルファイルは作ってあるが，印刷できない．古いバージョンで印刷は可能と思われるが，横書きがサポートされていない．PageLayoutという関数を復活させれば多分動作可能と思われるが，横書き対応の修正が必要になるので，動くようになるまではかなりの時間を要する．⇒とりあえず，ないよりはましと思われるので，縦書きでプリントしておこう．

確かに，現物が目の前にあるとかなりわかり易くなり，何が問題なのかも把握できる．何をやろうとしているのか？

1. 3種のコラッツ木があり，それぞれが固有のアドレス方式を持っている
2. 3種のコラッツ木にはそれぞれ収容するノードの範囲がある
3. 一般木にはすべての奇数ノードが入っている　つまり，一般木ではすべての奇数ノードに「実アドレス」を与えることができる
4. 仮想木には「長子ノード」だけが入っている　「非長子ノード」のアドレスは未定義と考えられる
5. 完全木には3倍数ノードは入っていないが，別枠のアドレスコード（詳細付番）で位置を特定できる
6. アドレシングの基準は仮想木であると考えられるが，仮想木に載っていないかなりの数の「非コラッツ数（非長子ノード）」がある
7. 偶数ノードは上位奇数ノードに詳細付番を付加して位置を特定する

やはり，偶数ノードは一度システムから省いて考えた方がよいのではないだろうか？偶数ノードを除外すると，特殊ノードというのは長子ノードと3倍数だけになる．仮想木というのは一般木の縮約グラフであり，アドレスの基点がつねに長子ノードにあるという点からすれば，基準コラッツ木と呼んでも差し支えないと思われるが，むしろ，一般コラッツ木から拡張コラッツ木に展開するというのが本筋なのではないだろうか？「コラッツ定理」を証明するためには，「完全正則木」を構成することが必要不可欠と考えられるが，拡張コラッツ木を「拡張正則木」として再構成することも考えられる．

これとは逆に，仮想木を拡張するということも考えられる．仮想木はルート１を除去して５をルートとする木としてみれば，容易に完全正則木を構成可能であり，長子ノードがアドレスの基点になっていることが確かであるとすれば，これはむしろコラッツ木の基準座標系のようなものになっているのではないか？上記項目4で「非長子ノードのアドレスは未定義」としているが，仮想木上に現れない非コラッツ数に付番を与えて位置を特定することは可能なのではないか？

今後は仮想木から1を除去したグラフを「長子木」と呼ぶことにしてみよう．長子木はすべて一般木の長子ノードのみから構成される木であり，ルートは５であるとする．このグラフには本来１の直下にあった部分木は省かれている．たとえば，21, 85, 341, 1365,…などはすべて５の兄弟ノードだが，長子木上には現れない．これらのノードを5+3のような感じで5と同位にあることを示すことはできるだろう．長子木上のノードをNとすると，その兄弟ノードN+kをF(N, k)とすれば，F(N,k)は以下のような漸化式で表すことができる．

F(N, i+1) = 4 * F(N, i) + 1

長子木は完全正則であり，長子木上のノードNは複数の兄弟ノードを持っているが，これらのノードはすべて義兄弟ノードであり，実兄弟ではない．つまり，長子木ノード上のノードの実兄弟ノード（一般木上の兄弟ノード）はすべて長子木上では非表示になっている．上記の式によってこれらの実兄弟ノードにアクセスすることが可能であるから，長子木はすべての奇数に一意のアドレスを与えることができるだろう．これが本当の拡張コラッツ木なのではないだろうか？もちろん，このグラフがすべての偶数を含むように拡張することは難しくない．

長子ノードと親ノードの算術的関係は明確に定義されているので，長子木上で定義された汎用アドレスコードからそのノード番号を割り出すことは難しくない．また，任意のノード番号が与えられたときに，その番号から長子木上のアドレスコードを生成することも可能であると考えられる．もし，この考察が正しいとすれば，現在取り組んでいる完全コラッツ木という概念は破棄されることになるのではないか？つまり，一般コラッツ木と拡張長子木が並立するという構成になり，三本桜は二本ザクラに縮退することになる．長子木が一般木を縮約したものであるとすれば，一般木はむしろ長子木の拡張ないし展開とみなすこともできる．

上記ではNのk番目の実兄弟をN+kと標識するとしているが，むしろ，N:kのような感じで表記した方がよいかもしれない．この場合はもろにNのk番目の弟という意味になり，トポロジー的にも整合性がよいかもしれない．たとえば，

1. 2. 3:4

は，５→３→35→1507→(((1507*4+1)*4+1)*4+1)*4+1 を表すことになる．このような形式で表示されるNの兄弟ノードがすべてNの親のDNAを継承していることは（多分）容易に示せるはずだ．完全コラッツ木というのも悪いアイディアではないが，どこかで座礁する可能性は高い．それよりも長子木を直接拡張する方向のほうが正しいと思う．再定義された長子木にはコラッツ変換のゴールである1が含まれないというところが「奇妙」なところだが，逆にそれがこの問題の「鍵」なのではないかと思う．「コラッツ完全木検定」はすでにかなり作り込んであるが，まるごと廃棄ということになりそうだ．

A面はすでに修正完了しているので，後はB面に対応するだけだ．B面には4つの処理が入っている．①コラッツ数列生成，②アドレス→整数変換，③幹線木生成，④検証テストだ．それぞれを3モードに対応させるとすると，処理は3×4=12個必要になる．しかし，B面で扱っているコラッツ木はすべて直列のチェーンだけなので，一種に統一することは不可能ではないかもしれない．特殊扱いが必要なノードは偶数と３倍数に限られるが，それらは基本的にチェーンの終端にしか現れないので，汎用的なユニバーサルコードシステムで扱うことができる．

④の検証テストは①と②を組み合わせたものだが，「検証テスト」の趣旨から考えると，偶数まで含むユニバーサルコードシステムでカバーすれば十分であるようにも思われる．幹線木というのは，②で生成されるチェーンに枝葉を追加するだけのものなので，従属的な扱いでよい．しかし，①のコラッツ数列取得のダンプ出力はモードによってかなり違う．たとえば，対象ノード番号に15を指定した場合，最新版（最終版）では以下が出力される．

15という整数は，15→ 23→ 35→ 53→ 5→ 1のようなコラッツ数列を生成するが，23[-1]という表記は，15が3倍数であることを示している． 旧版では同じ15から出発してもかなり異なる結果が出力される．下図で左が一般木，右が仮想木モードの出力だ．

　　

右図の仮想木モード出力の右側の列は，左図の一般木モード出力と完全に同じものが出力されている．つまり，旧版では（仮想木モードのときには）一般木と仮想木の両方の結果が出力されている．一般木上のコラッツ数列と，仮想木上のコラッツ数列にはかなりの相違がある．

一般木：15→ 23→ 35→ 53→ 5→ 1
仮想木：15→ 23→ 35→ 3→ 5→ 1

仮想木では数列上に3倍数が現れるというのがもっとも大きな相違点だ．最新版の完全木出力と旧版の一般木出力は15の枝番が負値になっている点を除けばほぼ一致している．ただし，一般木と仮想木の枝番が終端ノードを除けばつねに一致するとは限らない．完全木の（正の）枝番は3倍数を除外した兄弟ノードの順位になっているからだ．旧版の仮想木モード出力を拡張して，①一般木，②仮想木，③完全木の3種のパターンを併記することが考えられる．これ以外の対処法というのも考えられないので，結論的には，（１）B面ではモードを区別しない，（２）コラッツ数列生成では3種のパターンを併記する，（３）それ以外ではユニバーサルアドレスコードを適用する，とするのが妥当ではないだろうか？

これでよいとすれば，修正はコラッツ数列生成の出力に完全木の列を追加するだけで済む．これなら間違いの発生する余地もないだろう．早速実装に移ることにしよう．修正に掛かる前に，既存画面から「Auto-copy branch ordinal numbers」というオプションを外してしまうことにする．このオプションはコラッツ数列生成時に二次的に生成される分岐枝リストをコピーしてアドレス→整数変換のときに再利用するためのスイッチだが，これまで運用した限りではつねにオンにしたままで一度もオフにしたことはないので，「要らない」ということでよいと思う．その方が仕様が単純になってわかり易い．

旧版では，コラッツ数列生成はGetCoreSequenceとGetTheSequenceに分かれている．GetTheSequenceは一般木のみを扱っているので実質的にGetCoreSequenceに含まれているはずだ．GetCoreSequenceと最新版のGetTheSequenceを組み合わせればよいはずだが… ⇒一応修正は入ったが，仕上がりにはほど遠い．3のコラッツ数列を求めただけで無限ループしてしまう．細部をもう少し詰める必要がある．

過去ログもほぼ読み終わったので，実装に移ることにしよう．「コラッツ三本桜」が，①コラッツ完全木，②コラッツ長子木，③コラッツ一般木の3つからなるとすると，プロジェクトの最終版には①と③が含まれているものと考えられる．いや，A面には完全木(full regular)というオプションがあるが，B面にはそのようなオプションはない．つまり，B面は完全木一色になっているはずだ．B面にはOdd numbersというオプションがあるが，これは検証テスト（Verification）を偶数まで拡張するためのものだ．従って，B面ではコラッツ一般木は扱われていない．

「コラッツ完全木検定」に移行する前のプロジェクト「コラッツ銀河高速道路系」ではA面，B面のどちらにも仮想木(Vertual tree)というオプションがあり，デフォルトでは一般木を出力するようになっていたが，最新版の「コラッツ完全木検定」では「ユニバーサルアドレスコード」を前面に押し出しているので，長子木をベースとするアドレッシングは不用になったものと判断された．しかし，ノード番号の4進数解析などで出てくる「兄弟順位」は長子ノードを基準とするものであり，「ユニバーサルアドレスコード」はむしろ便宜的なコーディングとも言える．

この意味では，「ユニバーサルアドレスコード」ないし，「コラッツアドレスコード」というのは，ちょっと気の利いた「アイディア」，ないし「思い付き」に過ぎない．ただし，このコードを使うとコラッツ木全体にシームレスにアクセスできるという利点もあり，捨て難いところもある．逆に「詳細付番」などやや回りくどい説明が必要になるというデメリットもあるが…A面を最新版，B面を銀河系から取るなどの折衷案も考えられるが，却って混乱の元になるような気もする．やはり，単純に三択できるようにするしかないのではないだろうか？

いずれにしても，ロジックはすべて実装してあるので，それらを継ぎ接ぎしてパッチするだけだ．慎重な作業は必要だが，注意深くやればそれほど難しい作業ではない．ともかくやってみることにしよう．「コラッツ銀河高速道路系プロジェクト」というフォルダがある．これが「旧版」の最終版であることを確認しておこう．この中に入っているExEは2月20日にビルドされたものだ．「完全正則コラッツ木を構成するためのもう一つの方法」というのは2月20日に出てきているので，これが最終版と考えて間違いないだろう．この版はV2.0.2 REL 2022-02-11だ．最新版の方はV2.2.1 REL 2022-02-26となっている．

間違いないようにまず，バージョン番号から変えておくことにしよう．V3.0.3 REL 2022-04-01とする．アセンブリ名もCollatzCompleteTreeに変更しておこう．ビルド後イベントも書き直しておく必要がある．アイコンも変えたいところだが，これは後で考えることにしよう．⇒とりあえず，旧版のVirtual Treeというボタン2個を最終版の画面に追加した．さて，このあとどう調理したらよいか？⇒いや，ボタンではなく，最初からコンボボックスを使って三択できるようにしておこう．選択肢は，①General tree，②Virtual tree，③Complete treeとした．

モードを選択するとボックスの背景色が変わるようにした．A面では一般木と完全木はすでに実装済なので，仮想木処理を追加すれば完成する．GenerateCollatzTreeをトレースして差分だけを挿入するようにしてみよう．処理本体はGetRegularCollatzTreeだ．いや，ここまではまったく同じだ．CollatzTreeStructureで相違点が出てくるのではないか？⇒この関数の内部で場合分けするようにした．無効ノードカウント以外は完全に動作するようになった．この数字はUpdateParameterで更新されている．⇒対処した．これでA面は完全に動作するようになった．

B面は明日ということにしよう．