ゼルコバの木テント村

やはり，不良の元凶はセグメント検定ということではないだろうか？

▲主画面のタイトル行にファイル名が表示されない．⇒系図タイトルの決定関数がZ.BaseRefnumが未定のうちに呼び出されている．というか，設定されていない．⇒mUpdateBaseRefnumという関数が呼び出されていない．⇒UpdateMaxCardでは，事前にZ.mMaxRecordCountを実行している．⇒mMaxRecordCountの冒頭でmUpdateBaseRefnumを実行するようにして表示されるようになった．いつ頃からこのような状態になっていたのか分からないが，どこか不用意に削除してしまっていたのではないだろうか？

▲BUG3000-1470.ZEL.ZELで三極検定レッドラインオーバーが起こる．BUG3000-1470.ZEL，BUG3000-1471.ZELは正常動作している．このサンプルは1469点で，結婚が0と表示され，画面にはカード１点しか表示されない．不審なのは，三極検定でレッドラインオーバーが起きているという点だ．⇒REDLINEに1という数が入っている．⇒この値は有効な結婚数＋１に設定されている．これでは無理だろう．⇒最小値を8とするように修正した．これでエラーなしで描画できるようになったが，1469点登録されているのに1点しか出ないというのはおかしい．⇒親族図になっていた．全体図に切り替えて描画できた．⇒結婚数は1007になっている．最初にカード1枚しか表示されないときは，表示数=1, 結婚数=0となっているので数字は合っている．

この辺りのファイルはBUGが頭に付いているように，当初は障害が発生していたはずなので，（いつの間にか）解消しているということになる．現状では今のところ反例サンプルとして残っているのは，Collatz12146.ZELだけになっているように思われる．

基本的なところで解決したと思っていたのだが，まだまだのようだ．Collatz4000-12243.ZELは遅いなりに正常描画できるが，Collatz12146.ZELでは左手にひどいスプリットが残っている．

ともかく，描画までに時間がかかり過ぎる．何かもう少し小ぶりの反例サンプルはないものだろうか？⇒Collatz3900-6165.ZEL（6165点）というのがあった．レッドラインオーバーは発生せず，30回ループして脱出しているが，スプリットが出ている．これは格好のサンプルかもしれない．ループから脱出してくるのでテスト時間もかなり短くて済む．⇒いや，ダメだ．解けてしまう．画面がまだ更新されていなかったのだろうか？⇒なぜだろう？コマンド引数で開いた場合と，ダイアローグから開いた場合で動作が違う．前者ではスプリットが出るが，後者では出ない！なぜ，こんなことが起こるのか？見当も付かない．ファイルのオープンの方法は内部処理にはまったく無関係のはずなのだが…
いや，違う．これはズーム倍率の違いだ．

前回セッションの最終ログの日付は2022/05/06だ．その後は，興味が「経済循環マトリックス」の方に移って，去年の暮に作業再開するまで中断した状態になっている．2022/05/06の時期の最大の障害はメモリ不足という感じだ．12146点の「極小反例サンプル.ZEL」というのは，Collatz12146.ZELと同一と思われる．ここで中断された「極小反例サンプルの生成」にもう一度チャレンジしてもよいのではないだろうか？ファイルを開くこと自体は問題なく実行できているので，今度は最後まで進める可能性はある．「極小反例サンプルの生成」を実行するためのスイッチがどこかにあるはずだが…

「コラッツ極小反例サンプル生成ツールの実装＠20220417」というコンパイルオプションがある．試してみよう．⇒いや，これは現状でもオンになっている．このオプションはほとんど作用を持っていないように見える．実際の処理はメニューから選択→実行することで始めて起動されるようになっている．まず，対象サンプルファイルを開いてから，ヘルプ→ 包括テスト→ 極小反例サンプルの生成だ．

動作のネックになっているのは，ステージ2「個人データのロード」のところだ．これはもう少し速くできるのではないだろうか？

▲setmaxrefnumでレコード番号を設定している箇所がある．CARDTABLE::makelinkでは空スロットにリンクを設定し，そのレコード番号を参照番号に流用している．その参照番号が使用済である可能性があるのではないか？Renumberでもレコード番号→参照番号を行っているが，これは仕様である．MARGTABLE::makenewlinkでも同様のことが行われている．しかし，makelinkの呼び出し元では引数は参照番号であるという認識はある．CARDTABLE::makelinkの引数名を変えておこう．⇒対処した．

emptyrecnを廃止してみよう．この関数は，①CARDTABLE::makelink ，②NODECLASS *newlink，③getnewRefnum から呼び出されている．⇒①は完全廃止，②はemptyrecnを改造して，maxRecordの次を返すようにした．③はこの関数自体を廃止して，呼び出し元ではgetmaxrefnum() + 1で間に合わせるようにした．

何か打つ手はあるのだろうか？現在のアルゴリズムで，時間は掛かっても最終的には解けているのかどうかを知りたい．Collatz12146.ZELを放置して，最後までやらせてみたい．どのくらい時間が掛かるのか予測も付かないが，もし，最終的にはつねに解けるというのであれば，アルゴリズムの正否の問題ではなく，効率の問題ということになる…

「結婚枠だけをセグメント検定の対象とする＠20230125」というオプションをもう一度試してみた．これは結構おもしろいかもしれない．これだけでかなり高速化する．Collatz4000X.ZEL（12243点）を開いて，系統並び替えを154秒でこなすことができた．3分掛かっていない．スレッドとスレッドの間が，相当開いてしまっているが，これはこれで対処できるのではないだろうか？

あるいは，処理を二段階に分けて，①結婚枠のみで概略ソート，②人名枠を含めた詳細ソートのような手順も考えられる．というか，たとえ結婚枠だけのソートであっても，これほどスプリットが出るというのはおかしいので，まず，そこに注力すべきではないだろうか？⇒「結婚枠だけをセグメント検定の対象とする」と言っても，実際には人名オブジェクトもすべて検定の対称となっている．修正箇所は，TRIBEBOX：JoinAdjacentBoxで人名枠が接触している場合のみマージしていたのを，同一ボックス内では無差別にマージしているという違いだけだ．従って，人名枠が結婚枠内でどれほど開いていても圧縮が掛からない．

暫定的にTRIBEBOXにフラグを設けて，二段階処理を組み込んでみよう．⇒組み込みは簡単に終わったが，53直系血族図.ZELではループを30回回すまでフラグが立ってこない．つまり，「結婚枠のみ検定」でもほとんど動作には変化が見られないということになる．Collatz4000Xなどではおそらく，かなり顕著な効果はあるものと思われるが，問題が解決しているかどうかは走らせてみないと分からない．⇒解けた！結婚点一致と衝突検定を独立にループしてerrcntとcollisionがゼロになってからセグメント検定に掛けるという手続きに変更してみた結果，134回ループして解を得ることができた．従って，アルゴリズム的には閉じていると言っても間違いではないと思う．

そうなると，あとは効率の問題ということになる．もう少し，というかもっともっと改善の余地はあるのではないだろうか？

ともかく，この版を一応バックアップしておこう．

午前0時を回るところだが，スナップショットを取っておこう．1000に近い来訪者があったということになっている．この理由は不明だが，かなり驚異的な数字だ．

今日のペースはまた通常に戻っているようなので，一過性の現象だったようだが… 何はともあれ，数字が上がるというのは悪い話ではない．⇒今日も順調にカウントが上がっている．午前5時15分で343人の来訪者があった．今日中にトータル95000人を超えることは確実なので，一週間以内に10万人の大台を超えそうだ．⇒完全な勘違い！343人というのは昨日の数字だ．今日は午前6時半でまだ，46人しかいない．

実験的に「結婚枠だけをセグメント検定の対象とする＠20230125」を試してみたが，無理そうなので解除．⇒試みに「MakePairListCleanを一時止める＠20220215」を解除してみたら，解けてしまった．

MakePairListCleanという処理は，ノード対の配置を最適化するための操作であり，今の場合にはノード対はまったく使われていないはずなので，このような変化が起きているとすれば，「基本的に必要な処理」がノード対処理と分離されずに混交していたということになる．この部分を切り出して，基本処理に統合する必要がある．まず，ノード対が生成されていないことを確認しておこう．ノード対の発行数をどこかで確認できるだろうか？⇒Nringには生成されたすべてのオブジェクトが登録されているはずだから，CheckNringCountでカウントできるのではないか？⇒オブジェクトの総数32460のうち，ノード対はゼロだ．

MakePairListCleanはTRIBELIST::MainExprerimentに入って始めて呼び出される．この関数は2度呼び出されているが，ループしないで一度で脱出している．ただし，内部にもループがあるのでそこでループしている可能性はある．この関数の中では複数の処理が実行されているが，何かしらの作用がある場合にはconflictが立ってループになるはずなので，ループしないで抜けているとすれば，「何事もなかった」ということになってしまうのだが，だとすれば動作が変化しているという理由が立たない．おそらく，どこかで，暗黙に何かが操作されているのだろう．

MakePairListCleanの内部で実行されているBuildCompleteTreeを止めると無限ループしてしまうので，この操作は必須処理になっているが，conflictは起きていない．BuildCompleteTreeは，CheckMultiCardsとStackTribeGeneを実行しているだけだ．⇒MakePairListCleanを暫定修正してBuildCompleteTreeを実行しただけで抜けるようにしてみたが，解けている．つまり，BuildCompleteTreeを実行することはノード対のあるなしに関わらず必須ということになる．

いや，MakePairListCleanを実行するか否かの問題ではない．単にCompleteTribeBoxの収束が遅いというだけの問題だ．実際，REDLINEを32まで引き上げたら正常描画できた．Collatz12146.ZELを読み込んでみよう．ループカウント上限32では，結婚点不一致84件, 衝突346件で収束には程遠いものがある．いずれにしても，三極検定をもう少し強化しないことにはどうにもならない問題であるようだ．とりあえず，ここで一旦打ち切って出直すことにしよう．

CompleteTribeBoxで結婚点不一致と結婚枠衝突を先行処理し，これらをクリアしてからセグメント検定に入るように修正して，一発でループを抜けられるようになったが，セグメント検定で動作不良が起きている．つまり，先祖ノードの「5」とその子どもの「53」が孤立した状態でループを脱出している．明らかにこれはセグメント検定に欠陥があることを示している．先祖ノードは#84230で，当初のセグメント番号は1．最終的にすべてのオブジェクトのセグメント番号は1724になる．

CompleteTribeBoxのループ出口でIsTribeCompleteの再検査を実行すると，結局31回ループするという動作になってしまう．少なくとも今の論理ではこれだけ回らないと解けないということのようだ．これは，セグメント検定で前詰めするとき，結婚点不一致が発生してしまうことが原因と考えられる．やはり，結婚点を維持しながら前詰めする方法を編み出すしかないのではないだろうか？⇒MAXIMALGRAPH：MoveSegmentBlockではBobject::MoveNeutralでオブジェクトを移動しているためと考えられる．

MoveSegmentBlockでMoveNeutralを使わないように仕様変更してみたが，31回ループという状況にはまったく変化がなかった．⇒「コラッツ特注版ではつねに中吊り＠20211217」をオフにしたところ，HorizontalSegmentでまったく停止しなくなってしまった．⇒とりあえず，この論理は元に戻すしかなさそうだ．

どうなっているのだろう？まだ午前6時43分というのに，今日の訪問者数が340を超えている．カウンタが壊れてしまったのだろうか？

少なくとも時計は壊れていない．3つのPCで同じ時刻を示している．いや，BlackHawkの時計は1:39になっている．どうも，このマシーンはフリーズしてしまっているようだ．今日は動いているが，メイン機も朝になるとたいがいフリーズしている．どちらもリブートしないと動き始めない．つまり，どちらもほとんど棺桶に足を突っ込んだ格好でいつご臨終になっても不思議ではない状態だ．中古のノートを一台送ってもらうことになっているが，ロックが掛かった状態になっているので，果たして使えるかどうかも定かではない．

一週間ほどコンソール卓から離れてしまっていたので，ペースが戻ってこない．当面の課題はコラッツ木ジェネレータの出力ファイルを安定に表示できるようにすることなので，その方向で作業することにしよう．「コラッツ対応版応急措置＠20211219」と「コラッツ対応版応急措置＠20211223」という2つの応急措置はとりあえず，解除してある．現在テスト用サンプルとして開いている「53直系血族図.ZEL」は1931点という，それほど大きくはないが，小さくもないファイルだが，REDLINE＝25という設定でレッドラインオーバーが発生する．

REDLINEの上限をもっと大きくすると正常描画できるようだが，25でもすでに十分大きいと思われるので，この状態でシューティングを試みることにする．上層で孤立点が発生しているというのが不良の原因だ．

さて，どう対策すればよいだろう？明らかにこれは，「極大セグメント検定」と呼んでいる「圧縮処理」の機能不全であることは確かなのだが，どうやって強化すればよいか？少し考える必要がある．孤立しているのは，先祖ノードの「5」とその子どもの「53」だ．「5」は子ども１人，「53」の下には141, 2261, 35, 565の 4人の子どもがいる．この先祖グループの2人を除いた部分はまともな配置になっているのに，これだけが孤立していて，それが矯正できないというところが不審な点だ．

理由として考えられるのは，「5」と「53」という2つのノードがどちらも，結婚枠という殻を持たない剥き出しの状態になっているという点だ．⇒いや，それも違う．少なくとも「53」はそれを囲う結婚枠の中に入っている．「5」を世代0とすると，「53」の子ども世代である世代2には上記の子ども4人が入った結婚枠が一つあるだけだ．これを「53」の直下に配置すればそれで完了というはずなのだが…

▲系図画面下部のステータスバー：基準カードの値が0になっている．系統並び替えを実行しても変化しない．現参照カードの表示もおかしい．⇒ダンプでは正しく表示されている．

レッドラインオーバーが発生した時点で，結婚点不一致が8件発生．

▲ShowUnderWearが動作しない．というか，画面が出てこない．

どうも，かなり悪い．最後のラウンドで結婚点不一致を処理した直後にブレークするようにして，下図のようになった．

三極がバラバラでまったく協調動作していないように見える．衝突検定の直後にブレークしてみたが，状態はほぼ同じだ．結婚点の一致検定を実施する前の状態はまだ，大分まともな状態になっているのだが…

極大セグメント検定と結婚点一致検定のどちらが悪いかというのも一概には言えない．いずれにしても，設計上の致命的弱点がどこかにあるというしかない．「MAXIMALGRAPHを共有する＠20220414」と「MAXIMALGRAPHを縮小する＠20220221」という2つのオプションを解除してみたが，動作には基本的な変化はない．セグメント検定から人名枠を除外して，結婚枠だけの検定を行おうとしたが，うまくゆかなかったので，便宜的に結婚枠内のすべての人名枠に結婚枠と同じセグメント番号を付与するようにしたところ，描画はできたが，完全に緩んだ「loose box」になってしまった．まぁ，当然と言えば当然なのだが．というのは，そのようなloose boxを締めてタイトにするというのが，セグメント検定の目的であったのだから…

これはどうも，一筋縄ではゆきそうもない…

レコード番号と参照番号の切り分けという課題はほぼクリアできたのではないかと思う．2021年の末にコラッツ対応版を初めた時期に，「コラッツ対応版応急措置」というのを何件か入れている．この辺りが今どうなっているのかを調べてみよう．作業を開始したのは，2021/12/11だ．この頃は，コラッツ木サンプルのデータ入力をやっている．発生していたエラーには以下のようなものがある．

1. 先祖ノード絶対世代番号不一致
2. LINKTABLE::MargTakeChild 結婚リンクが消えていない！⇒このエラーは，子ども氏名を消去した時に発生する
3. 選択状態が残ってしまう，他のカードを選択しても消えない
4. ページ設定パネルが開けない，印刷もできない
5. 先祖並び替えが動作しない，ボタンが効かない，ドラッグ移動もできない
6. インポート・エクスポートが動作しているバージョン：Ver 2.2.0.030 Rel 2021-03-17
7. 最終版からリスタート，2021-04-10
8. 氏名欄で左右カーソルキーを押すと入力文字が消える
9. カード画面上部ツールバーの氏名欄で名前の後ろに余分な空白が入る
10. カード数1000点のコラッツ木のインポートに時間が掛かる，1点処理するのに25秒掛かっている
11. CARDLINK::makelinkで時間が掛かっている，UNDOは止めておく
12. ZTYW処理が作動している，暫定的にgoodsonを空としている
13. 人名枠高の計算がおかしい，フォントサイズを大きくすると人名枠が世代境界を超えてしまう
14. コラッツ1000.zelを開くのにかなりの時間が掛かり，マネージド・デバッグ・アシスタントが作動して停止する
15. 親の垂線が兄弟連結線から突き出ている
16. TOPOLOGY::ClearTableで参照番号不整合が発生したとき ⇒ すでに止めてあるが，「コラッツ対応版応急措置＠20211219」というリテラルで明示する
17. NAMEBOX::Drawで人名枠高が世代高を超えた ⇒ コラッツ対応版応急措置＠20211219」で止める
18. MARGBOX::makeGoodSonの冒頭で「つねに中吊りする＠20211216」でゼロ復帰 ⇒ コラッツ対応版応急措置＠20211219」で対処
19. TRIBEBOX::CheckAbsoluteGenerationで系列優先ノードのbreakupがオフという理由でエラーが起きている．「コラッツ対応版応急措置＠20211223」で止めておく
20. 基準番号を1～1000に振り直すことにした
21. 垂直親子連結線が兄弟連結水平線を突き出ている．

Collatz12146.ZELというサンプルを開いてみた．名前の通り，12146点のデータが登録されている．系統並び替えだけ700秒掛かっているので，全体では15分くらい掛かったのではないだろうか？上の方でかなりひどいスプリットが起きている．多分，これが「極小反例の自動生成」ということに取り組むことになった原因だろう．

一番気がかりなところでもあるので，まず，これをシューティングしてしまいたいところだが，その前に，「コラッツ対応版応急措置＠20211219」と「コラッツ対応版応急措置＠20211223」を解除するところから始めよう．今後の作業の目標は，「コラッツ特注版をノーマライズして公開版に向けて統合する」ことだ．

▲コンパイルエラーが出ている．CARDDATA::refnumが存在しないというエラーだ．CARDTABLE::tablesizeという値でも不在が起きている．前者は多分「setRefnumはCARDBASEで実行する＠20230107」に関係しているものだろう．暫定的にrefnuｍをRefnumに変更している．後者はBASETABLE::tablesizeを暫定的にtablesize2としためだ．元に戻しておこう

▲KAKEIZU::getmarriageでは参照番号を指定してデータの取り出しを実行している．レコード番号でアクセスできるようにした方がよい．⇒KAKEIZU::getmarriage/getcarddataでは，num ないし refnum という語を使っているが，これは参照番号ではなくデータベースのレコード番号である．参照番号はデータベース内部では「登録番号」と呼ばれている．紛らわしいので，引数をrecnのように書き換えておこう．

KAKEIZUのメンバー関数の中でnumないしrefnumを引数とする別の関数がある．これらもチェックしておこう．QUICKDBのcurnumもcurrecnに改めておく．savemarriage，savecarddata，makemargfile＠もrecnに変更した．

参照番号のハッシュ化は，コラッツ対応修正により，登録カード数の上限が1000のオーダーから10000を超えるようになったことを直接のきっかけとしている．しかし，そのことによって，「リンクがどこに置かれていてもまったく問題なく動作する」というNシステムの最大の特長が著しく損なわれるか，ないし制約を受けるようになった．テーブルにハッシュでアクセスするためには，そのレコードはテーブルの固定位置に配置されることが前提となる．それと，Nシステムの「リンク配置の自由度」は明らかに背反している．

参照番号のハッシュ化が後戻りのできない決定であるとすれば，どこかで折り合いを付けなくてはならない．参照番号のハッシュ化はゼルコバの木の最大構成要素である人名テーブルと結婚テーブルに関わるものではあるが，それ以外の要素ではこれまでと同様，配置の自由度は損なわれてはいない．テーブル並び替えというのは一覧画面出力に関わるものであり，人名/結婚テーブルのレコード並びとは独立であるはずなので，人名/結婚テーブル上のリンクが固定位置にあったとしても，実行可能であるはずだ．⇒どうもlookupテーブルを作り損なっているようだ．⇒NAMESORT::SortNameSubで「lookupを前詰めする＠20230113」の論理にミスがあった．⇒修正して動作するようになった．

▲基準ソートの実行で選択カード数不一致が発生する．TOPOLOGY：RebuildCardListではUndoStartFlagがオンのときには選択リストから選択フラグを再設定し，オフのときにはフラグから選択リストを再構築している．どちらの場合も，フラグのカウントとリストのカウントは一致しなくてはならないのだが… リナンバーを実施した場合には，選択リストは無効にしなくてはならない．⇒いや，そういう動作になっているはずだ．⇒CARDTABLE::Renumberが間違っているのではないか？lookupに格納しているレコード番号を書き直している．⇒「Renumberではリンクを移動しない＠20230116」で収まったようだ．

▲58点削除→ 基準ソート→ Undo→ Undoで大量のエラーが発生する．親リンク不整合，カード参照番号の重複，子インデックスが負，親番号不一致などの後，どこかで例外を起こしている．⇒MARGLINK：CheckMargLinkのエラー出力に誤りがあった．

カード削除単独，ないし，他のタイプのソートとの組み合わせではエラーは生じないので，原因が基準ソートにあることは明らかだ．おそらく，それもリナンバーしていることが最大の原因と思われる．⇒確かにそのようだ．ということは，リナンバーをUndoしたとき，元の状態に戻っていないということなのだろう．

リナンバーでは「リンクを移動しない」ことになっているから，変化しているのはカードの参照番号だけだ．⇒カードの参照番号はCardNumListのリストアで復元できているはずなのだが，参照番号を参照しているすべてのリストが復元されているかどうかが問題だ．いや，そもそもCardNumListが保全されていないのではないか？

UNDOSYSTEM::BackupPointDataのSORTREFNUMにSetUndoListを実行するようにしたが，エラーは収まらない．CardNumListを生成しているタイミングが悪いのではないか？⇒確かにそのようだ．⇒NAMESORT::NameNarabekaeの入口でBuildNumListを実行するようにして解決した．多分これで，ほぼ問題は解決したのではないかと思う．まだ，何か見落としがあるだろうか？

昨日の修正では，基準ソートでRenumberを実行し，その代わりにUNDOをリセットするという作りになっているが，基準ソート時にlookupを保全しておけば，UNDOできるのではないだろうか？仕様的にはまるごと廃止という方向に向かっているところだが，試しておいてもよいのではないか？⇒lookupでは復元できない．lookupにはリンクテーブルのレコード番号しか入っていないから，参照番号を保全したことにはならない．もし，やるのであればやはり，CardNumListを生成・保全するしかない．

仕様的には参照番号のリナンバーというのは廃止で決定なのではないか？もし，なんらかの理由でリナンバーする必要が出てきたら，その場合には，内部処理として独立に再構築する以外ないと思う．ただし，アプリとのインタフェース上参照番号は不可欠であり，一覧表のテーブルにその情報が記載されていなければそもそも動作しない．ただし，それを公開情報として表に出さないというだけだ．あと腐れのないように実装しておこう．⇒いや，CardNumListを復活させて，基準ソートでもUNDOできることを確認しておくべきだ．

仕様がぐらついているが，CardNumListの操作を復活させた．これで一応基準ソートを実施してもUNDOできるようになったが，エラーが発生している．カード削除とテーブルソートを複数回実行→ Undo→…でRestoreShadowのエラーが起きた．CARDTABLE::InsertLinkで例外が発生している．再現できるだろうか？

カードをブロック削除→ 基準ソート→ 氏名でソート→ 肩書でソート→ Undo→ Undo→ Undo→ Undo→ で再現した．カード削除の復元に失敗している．リンクを戻そうとした位置に先住者がいたためだ．recn=243．RestoreShadowではshadowの親番からレコード番号を割り出している．この操作は（元の状態を完全に復元するのだとすれば）正しいと思われるのだが… ブロック削除→ 基準ソート→ Undo→ Undoで再現できる．基準ソートの動作自体おかしいところがある．ソートしただけで，系図画面に表示されているカードが減ってしまう．設定は「親族図：直系血族図」で一覧画面はすべてのカードだ．

全カード数=307のうち，親族図には278点が含まれる．このうち58点を選択して削除すると，画面には37/249点のカードが残る．選択したカードはすべて親族図に含まれるものだから，278-58=220点が残りそうに思われるが，37点まで減ってしまうというのは，「直系血族図」であるためと考えられので，間違ってはいないはずだ．これを並び替えても表示カード数は変化しないが，Undoで7点にまで減ってしまう．これはかなりおかしい．基準ソートのUndoでやり損なっているのだろう．

これは，おそらく基準カードが変化してしまったためと思われる．⇒全体図ではこの事象は起きない．ただし，InsertLinkのエラー（先住者の存在）は発生する．レコード番号は246．⇒Renumberの中でリンクを移動（前詰め）していた．⇒Renumberではリンクの移動は行わないように修正した．これで一応解決したはずだが，エラーはまだ続く．

▲ブロック削除→ 基準ソート→ Undodeで，TopologicalSort→ MakeActiveListを実行して，(treeview->validcard != ActiveList->count)のエラーになった．validcard=249に対し，countは198のままだ．フェーズはDECOMPOSITIONなので，すでにフィルタリングは完了しているはずだ．⇒PDBのlookupのカウントが198しかない．これはかなりまずい．いや，こちらの数字の方が正しいのではないか？PDBのrecordcountは249になっている．なぜだろう？

元々のカード数は307点だ．それから58点削除しているので，249点でなくてはならない．198というのはどこで起きているのか？基準ソートの入口では249になっている．⇒RebuildCardListで変化しているようだ．UNDOSYSTEM::CommandEnd→ RebuildCardListで変化している．RebuildCardListの中でもう一度NameSortが呼び出され，その中でcountの変化が起こっている．ソートは_MAXITEMモードで実行されている．⇒確かにlookupを前詰めする＠20230113という処理が入っている．これはカード削除などでできた空欄を前詰めするための処理だが，誤動作しているようだ．

どうも，かなりまずい設計になっているような気がする．というか，元々はそういう設計になっていたのだろう．参照番号＝レコード番号という設計だ．確かに，リンクを移動しないで参照番号の付け替えだけを実施すれば，参照番号〰レコード番号という前提が崩れてしまうのは当然だ．やはり，参照番号のリナンバーというのはバッドアイディアというしかないような気がする．現行では，参照番号というより，ハッシュ値というべきものに変化してきているので，それに対応して変化するしかないのではないだろうか？

参照番号をハッシュ値として扱うというのはそれ自体は悪い発想ではないが，逆にNシステムの本来の思想である，リンクがどこに移動しても問題なくアクセスできるという理念からはかなり大きな後退であるような気もする．この2つを両立させることは不可能なのだろうか？

▲Undo処理中にRestoreShadow→ InsertLinkでエラーが出た．挿入しようとしている位置にすでにリンクが存在しているというエラーだ．⇒再現しないが，別のエラーが出た．

linkの参照番号は@233でこれからrecnの233が計算されたものと推定されるが，その場所には@233の別のカードが存在している．削除されたカードの参照番号は基準ソート以前のものと推定される．この状況で間違っているのはどちらのリンクと言えるか？

UNDOSYSTEM::RestoreShadowでは，レコード番号をshadowの親番から取っている．これは正しいのではないか？基準ソートのUndoが正しく動作していない可能性が考えられる．⇒従前では，NAMESORTはCardNumListとMargNumListを保持していたが，現行では完全に抹消されている．これらのリストには有効な参照番号の写しが格納されている．これは必要だったのではないだろうか？⇒確かに基準ソートでリナンバーしなければこのエラーは発生しない．

▲カードを70点選択→ 単点削除→ 単点削除→ 単点削除→一括削除→ 基準ソート→ Undoを実行して，UpdateCardBaseで基準ノード不在エラー(!basenum && CHARTTYPE != DISP_IMPORT)が起きた．⇒*basecardは0だが，*basepartには237が入っている．表示モードは部分図だ．呼び出し元のmZelkova::mUpdateBaseRefnumでは，BaseDispAll=3079，BasePartial=134が入り，それを引数で渡している．「参照番号が一致しない場合は更新とする＠20180129」という論理で*basecard = 0に変わっている．⇒エラーを無視して続行で，上のエラーが再現した．

完全に抹消してしまっているので，かなり大変だが，CardNumListを復活させておこう．BuildNumListという関数も必要だ．「参照番号を永久コード化する＠20230109」というオプションでパージした部分だ．⇒「参照番号を永久コード化する」というのは覆されてはならない決定である．抹消したコードを復活させることは不可能ではないが，必ずしもベストソリューションとは言えないのではないか？むしろ，この方向を突き詰めて，「基準ソートを実行しない」，「参照番号をユーザから隠蔽する」という方向に進むべきなのではないか？

基準ソートを実行すると，参照番号が１から始まる通し番号になるというのは悪くないが，たとえば，結婚参照番号はまったくユーザに公開されていないが，それによる不都合は基本的に存在しない．もし，仮にカードの参照番号をソートするのであれば，その時点ですべてのUNDOを一旦破棄せざるを得ないだろう．そこまでして，実現するだけの意味があるだろうか？基準ソートを実行するか否かは今のところペンディング事項だが，それを実行した場合にはUNDOをリセットするという作りにしておいた方が安全だと思う．⇒一応動作チェックしておこう．

▲基準ソート→ Renumberを実行→ UNDOリセットを実装して，基準ソートを繰り返したところ，CARDTABLE::Renumberで(max && max == maxrefnum)のエラーになった．maxrefnumは基本的に単調に増加すべきものと考えられるので，同じ値をセットする操作はイレギュラー動作とみなされる．しかし，Renumberは参照番号の振り直しなので，そうなることは避けられない．⇒Renumber時には，maxrefnumをリセットしておけばよいのではないか？⇒解決

▲部分図から全体図に切り替えて，どこかでハングしてしまった．⇒かなりまずいことになった．系統並び替え→ 三極検定→ 極大セグメント検定でハングしている．maxloopが302という大きな数字になっている．REDLINEの値は50だ．⇒どうも，UNDOのインタフェースが壊れてしまったようだ．VB側で，LineageSort→ ChangeBaseRefnum→ UpDating→ UndoStatus→ RefreshSub→ LineageSortで無限ループに陥っている．ChangeBaseRefnumで誤動作しているようだ．

Z.BaseRefnumが3079なのに対し，Zelkova1.TopologicalSortが171という数を返しているためだ．画面は部分図になっているのに，DispPartialMapがFALSEになっている．⇒DispPartialMapを強制的にオンにしたら，抜けてきたが，エラーパネルが出ている．

画面はいつの間にか全体図になっている．カード画面は「系図画面上のカード」で，全体図なら300が正しい．部分図なら271のはずだ．どうも，かなり話がこじれてしまったような感じだが，再現できるだろうか？⇒基準ソートとおそらくそれに伴うUNDOリセットの影響と思われる．起動→ 基準ソート→ 部分図⇒全体図で再現できる．UNDOチェーンのリセットだけでそれほどの影響が出るというのはほとんど考えられないのだが… 基準ソート実行後は，VBで基準カードの切り替えを行っているが，それほど致命的な操作とは思えない．戻り値の参照番号は176だ．障害は部分図⇒全体図の切り替えで起こるので，どこかで何かしらの齟齬が発生しているものと思われる．基準ソートを実施していなければ，この切り替えは問題なく通る．

何かパラメータが落ちているのだろうか？このエラーは初回限りで，別の操作を行ったあとの，基準ソート→ 部分図⇒全体図では（操作を反復しても），起きない．⇒ChangeBaseRefnumの出口でやっていた操作（Z.BaseRefnum，Z.BasePartial，Z.BaseDispAllの更新）をUpDatingの前に実行するようにして解決した．

TOPOLOGY::GetRecordを包括的に使うように修正した．

1. 修正した関数：
2. CARDTABLE::GetCardBaseRecord
3. FAMILYTREE::GetRecord
4. TOPOLOGY::UpdateRecordFunc
5. TOPOLOGY::GetActiveRecord　⇒　廃止
6. PARTIALNAME::GetPartialRecord　⇒　廃止
7. FAMILYTREE::GetAllRecord　⇒　廃止

▲テーブル並び替えでは「現ソート列」を管理しているが，Undo/Redoしたとき，アプリに伝達されていない．