いきなりだが，面倒くさいのでWindows 11に移行することにした．画面の外観は，けばけばしたところが一掃されてわたし好みに近いものになった上，とりあえず通常の作業で支障を来たすようなこともなさそうだという見極めも付いたので，ともかくしばらくこれで運用することにした．大量のファイルコピーで以前より少し遅くなったような感じはする．エクスプローラで詳細モードで表示したときの行間が広くなっているのは気に入らないが，まぁ，しばらく使っていれば慣れるだろう．え，もちろん「ウィジェット」はオフになってますよ．
三極検定は個別系列内の要素の配置を決定する処理で，①結婚枠の吊り位置の調整，②結婚枠の衝突の回避，③要素間の距離を詰めてコンパクト化の３つの処理から構成される．水平セグメント検定と呼んでいるのは，この３番目のコンパクト化に関わるものだが，レイアウトを崩さずにコンパクト化するためにはあるまとまった要素のグループを同時に移動する必要があり，かなり技巧的なものにならざるを得ない．テスト回数3000のサンプルで起きている不良は水平セグメント検定の誤動作によるものと考えられるが，これを追跡するのはかなり難しい．
これまで使えていたSUW（ShowUnderWear）というデバッグ用のツールが使えない状態になっている上，巨大サンプルに対応してメモリ使用量を削減するために，水平セグメント検定で個別系列ごとに確保していた作業域をシステム全体で１個にしてしまっているため，セグメント番号による色分け表示というのもできない状態になっている．SUWというのはある種の例外処理で，プログラム実行中のどのタイミングでも（書きかけの）図面を画面に描画することができるという強力なツールだったのだが…SUWでは特定の系列を描画対象に指定することができるようになっていたはずなので，まだ工夫すれば何とかなる可能性がある．まず，それを追求してみよう．
コラッツ特注版ではメモリを節約するために，MAXIMALGRAPHのsegments配列とloosebox配列を外部に追い出して静的変数としているが，MAXIMALGRAPH自体は個別系列で保持するようになっている．しかし，MAXIMALGRAPHオブジェクトはセグメント検定中しか参照されていないはずだから，システムに１個あれば十分なのではないだろうか？少なくとも当面はセグメント検定を広域化するという構想は持っていないので，徹底してしまった方がわかり易いと思う．修正してみよう．⇒いや，やはりそこまでやるのはやり過ぎかもしれない．事後にsegmentcntなどを参照する場合がある．これらは個別系列で保持するしかない．⇒いや，そういう箇所は多くはない．というより，むしろ積極的にそうした方がよい．この修正に関わる箇所には以下がある．
- TRIBELIST::IsTribeComplete
- NAMEBOX::Group
- NAMEBOX::Group
- MARGBOX::clear
- NAMEBOX::Clear
- NAMEBOX::CLEAR
- TOPOLOGY::checkRIG
- Bobject::initialize
- Bobject::SetBranch
これらの箇所でセグメントを操作するのはむしろ危険だ．MAXIMALGRAPHを共有した上で，ReleaseSegmentを実行しないようにすれば描画時にもアクセスすることができるだろう．ReleaseSegmentの呼び出しは，①TRIBEBOX::HorizontalSegmentの出口，②TRIBEBOX::CheckMaximalSegmentの出口（単独で呼ばれた場合），③TRIBEBOX::CheckMaximalCompaction，④MAXIMALGRAPH::clearSegmentの4箇所ある．④は必須だが，①，②，③は止めることができる．
この修正をやってみて気付いたことがある．MAXIMALGRAPHを共有するということは，広域検定を実装するという方向に向かっているのではないかという点だ．三極検定は基本的に系列単位の処理なので，いきなりそれを広域化するというのは現実的ではないが，「共有」という語が「広域」を含意していることは明らかである．これで，セグメントのカラー表示はできるようになったが，SUWが動かないのでは始まらない．
どうも，どこか壊してしまったようだ．急に動かなくなってしまった．⇒TableSort.cppを差し替えて動作するようになった．TOPOLOGY::MakeLeastWindowで実行しているTRIBELIST::HeapTribeBoxesを関数の冒頭で実行するようにして，画面が表示できるようになった．理由はよく分からないが，これで良しとしておこう．SUWとセグメントのカラー表示が復活したので，デバッグを再開する．さて，どうやって追いかけたらいいだろう？
少し動作がおかしい．VS2027を管理者モードで起動しても立ち上がってこない．管理者モードでなければ起動できる．おかしなことに，タスクマネージャを開いているときには，管理者モードでも起動できるという動作になっている．管理者モードでないと不都合な場面というのはそれほどないので，運用的にはさほど不便ということもないような気はするが，管理者モードでないとデバッグ中にゼルコバの木のテーマを登録したりなどのこともできなくなる．タスクバーのアイコン→ 右クリック→ Visual Studio 2017→ 右クリック → プロパティ→ 詳細設定→ 管理者として実行をオンにして，ワンクリックで起動できるようになった．
SUWはまだ動いていない．HeapTribeBoxesの前にstackTribeGeneを実行することで描画できるようになった．stackTribeGeneは系列内部の描画要素を系列世代枠の集約する関数，HeapTribeBoxesはその計算を元に系列枠全体の矩形領域を計算し，それを集約して系図枠全体の矩形領域を計算するものだ．これで見ると，どんなことになっているのかをはっきりつかむことができる．
左端の孤立点は1だと思っていたが，違う．5, 5461, 85の３人兄弟だ．
１にはこの他に，1365, 21, 341 の合わせて６人の子どもがいる．このうち，1365，21 は3倍数なので，子孫につながるのは，341，5，5461，85の4つだけだ．このうちの3つは左端で孤立しているので，右側には１系統しかないことになる．上の図でおかしいのは，３人兄弟のうちの真ん中の5461の下に垂線がないことだ．実際，カード画面で見ても5461は子どもを持っていない．しかし，上記したように5461は３倍数ではないので，子孫がいなくてはならない．
ADLファイルで見ると，そもそも 5461 というカードの登録がない．15461というカードはある．⇒見落としていた．１の子どもの位置にある．ただし，5461を親とするレコードがない．これはかなりおかしい．つまり，ADLの出力自体に誤りがある．5には13，213，3，3413，53，853 の 6人の子どもがいる．85は，113，1813，453，7253 の４人の子がある．このADL出力の誤りを見つけなくてはならない．
明らかにGetTheNumberの論理には誤りがある．⇒いや，違う．5461はテストの対象となる奇数そのものだ．従って，5461が終端ノードであることは間違いない．もし，5461→1というパスがあるのなら，1に5461が直結しているのは間違いではない．実際，5461*3+1 = 16384 = 2^14だ．従って，ADLデータは間違っていない．確かにこの不良は結婚枠を一律中吊りにしていることに関係していることは間違いない．⇒中吊りを強制しないモードで走らせてみたが収束しない．
TC（Test Count）4000のサンプルでは中吊りの場合と同等の回数（loopcnt=32）で収束している．どうもこのTC3000というのは何か特殊なサンプルになっているのだろうか？この計算自体が収束しないある種の散逸構造的なトラップに陥っているのだろうか？