どうもまだ方針がぐらついている．完全木という構想を捨てて仮想木に絞り込んだ積りだが，完全木には完全木の優位性があり，仮想木にもそれなりの弱点がある．これは結局，「三本桜」という方針が正しかったということを意味するのではないか？というか，どこかでポイントを見失っているのではないだろうか？目標は何か？それをまず確定する必要がある．これまで得られた知見の中でもっとも重要なポイントはノード番号の4進数表記の中には，親から継承したDNAコードと枝番号が埋め込まれているという点だ．これをアドレスコードの流儀で書き下せば，
ノード番号:=｛親から継承したDNA｝.｛枝番号｝
のようになる．つまり，ノード番号は遺伝情報と枝番を「.」によって連結したコード（テキスト）であると言える．親から継承したDNAは長子ノード番号に等しいので，
ノード番号:=｛長子ノード番号｝.｛兄弟順位｝ （１）
｛長子ノード番号｝の中には親番号が埋め込まれていると推定されるので，仮にそれが
長子ノード番号:=｛親ノード番号｝.｛長子識別子｝ （２）
のように分解可能であるとすれば，
ノード番号:=｛親ノード番号｝.｛長子識別子｝.｛兄弟順位｝
のように表示可能であることになるから，｛長子識別子｝.｛兄弟順位｝を｛地番｝と置いて，
ノード番号:=｛親ノード番号｝.｛地番｝
のようになり，これを再帰的に展開すれば，
ノードN:=｛地番1｝.｛地番2｝.｛地番3｝…｛地番k｝
のように分節できる可能性がある．つまり，自然数Nをある適切な方法で暗号解読できれば，自然数Nを直接一般コラッツ木上のアドレスコード（ないしそれと等価なある表現形式）に変換できることが期待される．（１）式はNの4進数表記からデコードされ，（２）は3N+1の2進数表記によってデコードされる．3N+1という計算は3進表記した値を1左シフト（した上で1をプラスする，つまり1を右端に連結）することによって得られるから，「演算（代数的操作）」というよりは，「文字列操作」として（形式的に）実行可能であると推定される．このような解析を行う上で有効なフォーメーションとは何か？ということが問題になるが，ともかく，仮想木上で定義された汎用アドレスシステムの実装という仕掛りの作業を片付けておくことにしよう．
以前拡張アドレスコードを実装したときは完全木を対象としていたが，今回の仮想木上のアドレスコードの書式はそれとはやや異なるものになっている．前回の方式では1.2-1というアドレスコードでは
1 [1]→ 5 [2]→ 53 [-1]→ 141
のようなコラッツ数列が出力されていたが，今回方式で{1.2/1}とした場合には，
1 [1]→ 5 [2]→ 113(1)=453
のような動作になる．つまり，5の２番目の長子ノードである113は出力されず，直接非コラッツ数である453が出力されるようになる．既存論理で，453のコラッツ数列を求めると
113 453
5 (2) 85 [2]
1 (1) 1 [3]
が出力され，枝番号リストには{1. 2}が出力されるので，これをアドレス→番号変換すると113という答えが返ってくるため，デュアルな動作になっていない．これはもちろん，{1.2/1}→ 453→ {1.2/1}とならなくてはならない．従って，コラッツ数列取得では
453 453
5 (2/1) 85 [2]
1 (1) 1 [3]
が出力されなくてはならないだろう．この場合，区切り文字の「/」は以前提案されたように「:」とした方が（私の主観だが…）むしろわかり易いかもしれない．つまり，
453 453
5 (2:1) 85 [2]
1 (1) 1 [3]
のようになる．アドレス⇔番号変換ならば，{1.2:1}→ 453→ {1.2:1}となる．この方が読み易いような気がする．また，以前にも示唆しているところだが，本システムでは最終的に「偶数」は扱わないということにしたい．この制限によっても特に不都合が生じることはないと思う…既存コードでCore treeモードで検証テストを実行して出力される隣接リストはかなりあいまいなものになっている．つまり，望むような結果になっていない（と言うより間違っている）．これは上記のような「辻褄の合っていないところ」が存在するためと考えられる．多分，これは上記のようなアドレスコードの導入によって改善されるはずだ．