ようやく作業がルーチンで回り始めた．こうなれば，もう怖いものなしだ．今回作業再開の目的は一義的には「Sultanの論文の検証」だが，その前に「コラッツ木生成ツールの再構築」と「ゼルコバの木の増強」に取り組まなくてはならない．現在，ゼルコバの木は「コラッツ特注版」というかなり変則的な方向に進んでいるが，この方向性をむしろ「本則」として標準化する必要がある．
コラッツ木は単純な木であり，これを最大限・最高速で処理できるようにすることは，一般の系図を扱う上での前提であると考える．ゼルコバの木はこれまで，最大1000点というスケールの領域を扱ってきたが，これを機会に1万点を超えるデータを扱えるように仕立て直したい．かなりハードルは高いが，やっておく必要がある．
▲カードを2点削除した後で，Undoを2回行うと，UndoNumberの不一致が発生する． (UndoCurptr-> UndoNumber != UndoNumber)が起きている．UndoCurptr-> UndoNumber=1, UndoNumber=2だ．このエラーは初回だけで，その後の Redo，Undoでは収まってしまう．
UndoNumberという値は，①UNDOBASE，②UNDOCOMMAND，③noduleの各クラスで保持されている．UndoNumberは「重複バックアップの回避用」．UNDOBASE::MakeNewCommandでシステムとチェーンのUndoNumberの同期がなされている．SetUndoListではバックアップの対象となるオブジェクトに現UndoNumberが格納される．
UNDOBASE::CommandEndでは出口でUndoNumberの調整が行われる．⇒UndoStartでコマンドを開始する時点で，前方のコマンドチェーンがパージされる．このとき同期が一時的に崩れる場合がある．UndoCurptrが変更された場合には，つねにUndoNumberを更新する必要があるのではないか？UndoCurptrは以下で切り替えが発生する．
- UndoBase::UndoProcessの出口
- UndoSystem::UndoProcessの出口
- PergeZenpoChainの出口
- UNDOBASE::MakeNewCommandの出口
- UNDOBASE::CommandEndの出口で(UndoCount <= 2)のとき
UndoBase::UndoProcessは実質的には（ほぼ）使われていない．UndoBase::CommandEndで例外がキャッチされた場合にのみ，強制的にUNDOを実行して復帰するような作りになっているが，これが実行された試しはないと考えられる．
▲MAXUNDOCOUNT=5のとき，最大4コマンドまでしか保持できない．なぜか？⇒MakeNewCommandで(UndoCount >= MAXUNDOCOUNT)で打ち切っているためではないか？等号を外せば，MAXUNDOCOUNTまで作れるはずだ．⇒これでよい．
ここで一旦バックアップを取っておこう．
▲一覧画面の列ラベルをクリックしたときのテーブル並び替えが実行できないのはなぜか？⇒いや，動いている．セル項目をテキストしてソートしているので期待したような結果にならなかったためではないか？⇒カード番号は数値としてソートしているのに正しい並びになっている．見間違えだったのだろうか？まぁ，ともかく，これでよしとしよう．
少なくとも今当面の目的では，①カード番号，②氏名，③所属，④肩書きだけは数値としてソートしたい．⇒特注版の「数値で並び替え＠20221225」オプションとして処理しておく．⇒うまく行った！
▲NAMESORT::NameNarabekaeのcheckがオンになっているとき，STOP文で止まらない（場合がある）のはなぜか？⇒ブレークポイントを置けば停止する．⇒STOP try {__asm { int 3} } catch (…){}を{ int 0}に書き換えたら毎回停止するようになった．
コラッツ木生成ツールから出力される隣接リストファイル（ADL）では，氏名欄にそのノードの値である巨大整数が入っている．カード番号はテーブルの範囲内であれば，その値をそのまま採用する場合もあるが，通常はオーバーフローしてしまうため，ハッシュして小さな数に変換している．ここで使っているハッシュ関数は単純なもので，すべてのビットが1であるようなある桁数の整数とANDを取っているだけだ．テーブルサイズを２のべき乗にしていたのはこのような事情による．
テーブルサイズが小さくなった場合はどういうことになるのか？現行では，0x1FFFという定数に固定されている．この値はテーブルサイズによって伸縮されるべきだと思う．カード番号のデータ型はlongなので，最大でもその範囲を超えることはできないが，テーブルサイズ AND FFFFFFFF まで使えるのではないだろうか？
▲発行されたカード番号が実際のテーブルサイズより大きくなる場合がある．テーブルサイズが1000のとき，最大#1097というカードが存在する．登録データはきっかり1000点だ．つまり，1000より小さい領域に97個分の穴が開いているということになるのだが… 実用的にはこれでも特に問題はないとも言えるが，参照番号はテーブルのレコード番号と一致するのがベストであるという観点からすれば，見直しの余地はあるのではないだろうか？⇒やってみることにしよう．
多少厄介なので，一度バックアップを取っておいた方がよいかもしれない．⇒どうも見ているところが違うようだ．カード番号はLINKTABLE::GetRefnumで決めていると思っていたが，通っていない．いや，いまテストしているのはADLファイルではなく，ZELファイルだ．⇒テーブルサイズを6000に拡大して読み込んだら，カード番号も振り直しされている．ただし，最大6000を超えるカードが97点ある．どこで振り直しをやっているのだろう？
カード番号が決定しないとテーブルは構成できない… COUPLING：InitLinkTable辺りでやっているのではないだろうか？⇒確かにそのようだ．参照番号が空スロットならばそこを使い，空いていないときは，空スロットを探してそこに居を定める論理になっている．BASETABLE：newlinkでは，まず指定番号のスロットが空いていればリンクを生成してそこにリンクする．空いていない場合は，makenewlinkを使って空スロットを探し，そこにリンクを（newlinkを使って）生成する．
しかし，この方式なら参照番号がテーブルサイズを超えることはないように思われるのだが… makenewlinkには２つのバージョンがあり，emptyrecnを使うパターンとgetnewRefnumを使うパターンがある．後者はmaxrefnumをインクリメントした番号を返すので増長してゆく可能性がある．⇒getnewRefnumの代わりにemptyrecnを使うようにしてみたが，効果なかった．⇒現行方式では参照番号の振り直しまでは実行していないので，テーブルサイズより大きなカード番号の存在は不可避である．⇒参照番号の振り直しというのがどこかにあったのではないか？
▲テーブル並び替えで系統並び替えが実行される．
テーブルサイズ8192（0x2000）でテストしてみた．最大で8289というカードがある．8289-8192=97でこの場合もはみ出しているカードのオーダーは同じだ．⇒MAXPDB=12300, MAXMDB=10300でCollatz12146.ZELを開くことができた．カード番号のはみ出しは解消した．ただし，三極検定でループカウントオーバーが発生している．