検証テストが出力する大きいサンプルの描画で不良が出ている．
▲コラッツ木ツールからZTを直接起動して，ImportEndで停止する．
このエラーはデバッグモードでは起きない．⇒Nリング上の特定のノードを検索するデバッグ用のコードが残っていた．
テスト回数4000では三極検定のループを34周で抜けているが，テスト回数3000では抜けられない．⇒どうもこれは，三極検定の欠陥が露呈したものであるような気がする．errcntは周回するごとに単調に減少してゆくが，ある点まで来るとまた跳ね上がってしまうという動作を繰り返している．以前はこれに加えて，ルートノード直下の結婚枠が結婚点不一致のとき，CheckMargBoxを実行しても移動量がゼロにならないという事象があったが，いまは再現できない状態になっている．
このサンプル自体が特殊なものになっているという感じもする．後で再試する必要があるので，このサンプルを取り分けておこう．⇒「CollatzTest.X.ADL」としておいた．
コラッツ木というのは紛れもなく「単純な木」なので，これが解けないとなると身も蓋もない．⇒中間の状態が見たいので，SUWを仕掛けてみたが，まったく描画できない．この三極検定はMainExprerimentの手前のTribeRelocationで実行しているので，TribeRelocationをまるごと止めてみたところ，ともかく描画することはできた．
ただし，この図を見るとどうもMainExprerimentの中では三極検定をやっていないように見える．CompleteTribeBoxは，①TRIBELIST::CheckCompleteList，②TRIBEBOX::StackTribeGeneから呼び出される．⇒MainExprerimentの中ではStackTribeGeneさえ呼び出されていない．⇒⇒出た！
出たのはよいが，少し形状が違い過ぎる．多分これは間違っているのだと思う．衝突検定が入っていないのではないだろうか？⇒正しく動作するためには，少なくともTREEVIEW::GetMaxMoveを実行する必要があるようだ．⇒この関数はTribeRelocationで実行される前にTREEVIEW:SetDispParmの中からすでに２回呼び出されている．
ここで更新されているのは，maxloopcountとMAXLOOPCOUNTの２つだけと思われる．これらの値はそれぞれ，20→2261，128→2261のようにかなり大きく変化している．maxloopcountは計算用の内部変数なので，外部に影響するのはMAXLOOPCOUNTの値だけだ．この値が急増するのは，この値がカード数と結婚数よりも大きい数になっているためだ．テスト回数3000のサンプルではこの値が1680になっている．
変動しているのは，ルート直下の結婚枠の幅だ．本来の配置なら30000くらいの幅があるはずのところが，313まで縮退し，また膨張するという運動を繰り返している．これでは収束するはずがない．⇒水平セグメント検定で失敗している．この解析はかなり難しいかもしれない…