修正をフィックスしてリリース版を起こしたが，ZELのアイコンをダブルクリックしてファイルを開いたとき，「基準ノード不在」が発生するという事象が残っている．開発環境でデバッグモードでコマンドライン起動できるようになっているが，そこではこのような事象は発生していない．つまり，リリース版とデバッグモードの動作が異なるものになっている．⇒リリースモードでコマンドラインを実行してみればよいのではないか？⇒おかしい，現象が再現しなくなった．⇒確かに，一つ修正を入れてからリビルドしているはずだが，すでに解消しているようだ．
コマンドラインで隣接リストのCSVがオープンできるとしたら，ダブルクリックでそうできてもよい．ただし，そのためにはCSVという拡張子をZELに登録しなくてはならない．CSVファイルは一般にはエクセルなどの表計算がデフォルトアプリになっているので，それを横取りするというのも多少問題がある．むしろ，隣接リスト専用の拡張子を決めてゼルコバの木で登録するようにした方がよいのではないか？現行ではゼルコバの木形式エクスポートも隣接リストも同じ拡張子CSVを使っているが，これも問題だ．*.ADLとしてみよう．ADLはActivities of Daily Livingで「日常生活動作」という意味だ．これには，移動・排泄・食事・更衣・洗面・入浴などの日常の生活動作が含まれる．わたしの関心のもっぱらの傾向からすると適切な拡張子であるような気がする．
このファイルが出力できるのは今のところコラッツ木生成ツールだけだが，隣接リストはテキストエディタでも簡単に作れるので，まぁ，よいのではないだろうか？⇒だいぶわかり易くなった．⇒アプリインストール時に*.ADLを登録するようにした．これでADLファイルをダブルクリックしてもコラッツ木が表示できるようになった．
▲ADLファイルはもともとCSVファイルだが，インポートしたときに内部的に一度ZEL形式のCSVフォーマット形式に変換し，それをインポートするという動作になっている．このため，ファイルを読み込んだあと，タイトルに表示される名前がこの一時ファイルの名前になっている．これはかなりおもしろくない．書き換えることは可能だろうか？⇒一時ファイルの名前を単純にADLファイル名の後ろに”.CSV”を追加するだけにした．これなら表示されてもそれほど不自然ではないと思う．
▲開発環境でリリースモードで走らせると空白画面になる．本来は新規カードが１枚表示されていなくてはならないところだ．⇒いや，コマンドライン引数を渡さないようにすれば，デバッグモードでも同じ動作になる．どこか壊してしまったのだろうか？⇒コマンドライン起動の処理を一箇所に統合するために相当書き換えを行っているが，コマンドライン引数なしの場合の処理を落としていた．
いい感じになってきた．ほとんど「最強のコラッツツール」と言ってよいと思う．*.ADLのアイコンをダブルクリックするだけでゼルコバの木が立ち上がってくるというのもうれしい．このツールには５つの機能があり，それぞれ一般木と仮想木を扱えるようになっているから，5×2=10種のファイルが出力されることになる．まずは，これらの出力ファイルを一通りチェックしておこう．
▲ゼルコバの木が立ち上がっているのに，タスクバーにアイコンが出てこない．代わりに何か白い枠のようなものが出ている．EXEのアイコンとMDIウィンドウのアイコンは出ている…タスクバーに古いバージョンのアイコンが残っていたためだ．⇒問題なさそうだ．
A面の出力は問題ないと思う．左が一般木，右が仮想木だ
▲コントロールキー＋リールでズームができるようにしたい．また，ズームボタンは押し続けていると段々速くなるようになっているようだが，初期の動作ももう少し速くてよい．
▲アドレス変換でエラーが出た．分岐枝リストは「1. 1. 2. 1. 1. 1. 1. 1. 1. 2. 1. 1. 1. 2. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 2. 1. 1. 1. 3. 1. 1. 2. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 2. 1. 1. 1. 1. 1. 2:1」でコラッツ数列が「53261」から出力したものだ．⇒一見したところどこも問題ないように見えるのだが… ⇒一般木でテストしていたためだ．現行では一般木では拡張アドレスをサポートしていない．というか，一般木の場合のアドレスはつねに実アドレスになるから，拡張アドレスという概念はない．また，そのアドレスコードの示す経路中に３倍数が入っていれば，そこでアドレスコードはカットされる．
一般木上では「53261」のアドレスコードは「1. 3. 1. 1. 2. 2. 1. 1. 2. 1. 1. 1. 2. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 2. 1. 1. 1. 1. 1. 1. 1. 1. 1. 2. 1. 1. 1. 4. 1. 1. 2. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 2. 1. 1. 1. 1. 1. 2. 2」のようになる．長さは同じ60だ．ADLファイルの名前に木の種別を入れておいた方がよいのではないか？一文字でよいと思うが，一般木をG，仮想木をV，完全木をFとしてみよう．⇒しかし，今の誤操作はコラッツツール上のもので，ADLファイルとは関わりがない．⇒現行では仮想木に切り替えると出力枠の背景色がブルーになる．分岐枝リストのフレームも同色に切り替えた方がよいのではないか？
悪いアイディアではないが，効果は限定的だ．コラッツ数列のリスト出力を転用してアドレス変換することが多いが，リストに残っているのが，どちらのモードで出力されたものかは判別できない．⇒とりあえずは，現行のままとしておこう．ファイル名にモード種別を追加するという修正は入れておいた方がよいと思う．
▲幹線木の関係がおかしい．一般木も仮想木もコラッツ番号と合っていない．⇒サンプリングが悪いのではないか？多分相応していない組み合わせになっているのだと思う．サンプルを取り直した方がよい．23637という数字をターゲットとして取り直してみる．⇒問題なさそうだ．
コラッツ数列とアドレス→ノード番号は逆順になっていて，幹線木の軸はアドレス→ノード番号の系列と完全に一致している．これでB面４機能のうちの３つの出力が確認できた．あとは検証テストだけだ．2^3という範囲で1～15までの奇数を含む最小のコラッツ木を出力してみた．
終端ノードは一般木では3, 9, 15の３つあるが，仮想木では3はコラッツ数なのでパスの中間の位置に出現する．表示されているノード数は一般木が12で，仮想木は10だ．13と53は仮想木上には表示されない．53は範囲外だからよいとしても，13は[1, 15]の区間に入るので，表示されてもよいのではないか？拡張アドレスコードを使えば非コラッツ数の位置を示すことができるのだから，表示できないというのはおかしい．
13は3の兄弟ノードだから，5の下に来るべきだ．53も同じく3の兄弟だ．コラッツ数列取得で確認すると，13には「1. 1:1」というアドレスが割り当てられている．やや，53でも「1. 1:1」が出力されている．これはおかしい．一般木で見ると5の子ども枠には，{3, 13, 53, 213,…}が入っている．従って，3:={1. 1:0}，13:={1. 1:1}，53:={1. 1:2}，でなくてはならないと思うのだが…実際，アドレス→ノード番号にこれらのコードを与えてノード番号を出力すると，{1. 1:1}→13，{1. 1:2}→53，{1. 1:3}→213が出力される．従って，アドレス→ノード番号は正しく動作していると言ってよいと思う．明らかにコラッツ数列取得処理はどこかで間違えている．
あれ？！今度は正しく動作している．読み間違えた，というか，どこかで操作を間違えたのか？このツールはあちこち操作するところが多いので勘違いを起こし易いかもしれない…ともかく，Get Collatz sequenceとAddress to numberが完全に逆演算になっているというところが肝心なところだ．この2つが正しく動作していれば，検証テストは自ずと正しく動作するはずなのだが…CSVに変換する前のADLの中身をテキストエディタで調べてみよう．一般木の方は，
1 5
11 7
13 17
17 11
23 15
35 23
5 13 3 53
53 35
7 9
のようになっている．これは正しい．仮想木を見てみよう．
1 5
11 7
17 11
23 15
3 17 35
35 23
5 3
7 9
確かにこれは，ゼルコバの木の描画と一致している．つまり，ADLの出力に欠落があるということになる．検証テストの出力は，コラッツ数列ではなくアドレスノード番号で出力していたような気がするのだが，違うだろうか？⇒確かに，そうなっている．NumberStreamに書き込んでいる場所で，かならずVerifyStreamに書き込むようにしていれば同期は取れるはずだ．NumberStreaming，TruncatedStreaming，VerifyStreamingはかならず排他的になっていなくてはならないのだが，どこかで崩れているということはないだろうか？
VeriVerifyStreamへの書き込みは2箇所でいずれもGetTheNumberの中だ．⇒おかしい．NumberStreamへの書き込みとVerifyStreamへの書き込みの位置は完全に一致している．そもそも，検査の対象から弾かれているという可能性が高い．⇒確かにその通りだ．コラッツ数しか対象としていない．⇒修正を入れてみたが，相当おかしな結果になった．⇒いや，間違えていた．Odd numberに大きな数字が入っていた．１から始めるようにしたら，カード数は11点になった．
テスト区間は[1, 15]でその間の奇数はすべて出力されている．53という数は入っていないが，この数は区間外であり，それがなくても連結性は保たれている．これでようやく正しく動作するようになった．区間を設定するのに2のべき乗を使っているというのはちょっと使い勝手が悪い．もう少し細かい範囲で調整したい．2のべき乗を使ったのは，大きい数字を入力するのが面倒だったからだが，やはり整数で指定するようにするべきだった．⇒これはやはり変更した方がよいと思う．⇒できた！
テストカウントを16で走らせてみた．
区間は１～31でカード数は53，1～31までの奇数はすべて入っている．1から一番遠いノードは27で距離は41ある．仮想木ではカード数は51で2枚少ない．この2つの図面を合併（追加読み込み）して，共通部分を取って部分図とすれば，一般木と仮想木がどのように交差しているかを見ることもできるだろう．テストカウントは巨大数になるので，かなり大きなテキストボックスが必要になる．Odd numberと同寸では画面に収めるのが難しい．
なんとか収まった！
これで大体仕上がったのではないかと思う．⇒テストカウント4000のコラッツ木を試してみたが，ハング状態になって抜けてこない．3000くらいまでは難なく描画できていたのだが… ゼルコバの木の上限は多分7000だったと思うので，仮に上限をオーバーしてもそこまでのグラフは描画できなくてはならないのだが… 計算自体は数秒で完了している…3000まではそこそこの時間で描画できるが，3200になるとほとんどハングしている．下図はテストカウント3000，ノード数4720のコラッツ幽霊木だ．前は「蝙蝠に見える」と言っていたのだが，点数が増えると，むしろ「炎」のような感じになってきた．
▲ゼルコバの木はだいぶ前に「Zelkova tree 2022」に改名しているが，まだどこかに「Zelkova-tree 2021」というのが残っているようだ．⇒AssemblyInfo.vbというファイルに入っている．このファイルはシステムが自動的に作っているものだと思うが…
なぜだろう．今回はテストカウント40000でカード数7000というADLが難なく開けた．考えられるのはカード数が不足しているため，グラフがぶつぶつの非連結になったため，却って速く描画できているのではないか？という感じだが…このグラフの木の高さは129だが，実際の描画はもっと低い木になっている．木というより，ヤブになってしまっている．実際，こんな図面になっている．
