月: 2021年2月

ゼルコバの木の普及版として公開を予定しているZekova Tree Basic バージョンの実現可能性が高くなった．テクニカルな問題はほぼクリアできたような気がする．ZT BASIC はゼルコバの木標準版(Zelkova Tree Advanced)から以下の機能を外したものだ．

1. ゴミ箱（リサイクルシステム）
2. UNDO/REDO 機能
3. 抽象グラフ検証系（重婚クラスタ検定，端点共有ノード対の循環検査）
4. 完全参照リスト管理

記録ページやカード写真イメージなどは普及版でもサポートされる．一般の個人ユーザが作成する50～100人程度の比較的単純なツリー構造の系図であれば，上記のような高度の機能を用いなくても十分作成できるだろう．ゼルコバの木を使うと100人程度の系図なら一週間程度で完成してしまうし，一旦作成してしまうと大概のユーザはそこで飽きてしまうので，高価な専用ソフトを購入しても宝の持ち腐れになってしまう．ゼルコバの木普及版の予価は2千円くらいを予定しているが，このくらいなら捨てる気持ちで支出できるのではないだろうか？

データ保存機能を持たないビューアはこれまで通り無償配布してゆきたいが，そうなるとどのバージョンのビューアを公開するかという問題が出てくる．ZT Advancedのビューアが無償で使えるということになると，普及版（ZT Basic）で作成した系図を高機能版のビューアで見るという使い方ができるようになり，誰も標準版を買う人がいなくなってしまうのではないか？普及版でビューアを出すならもちろんそういう問題は発生しないが，それも少しせこいような気もする… 場合によっては，ビューアの配布もユーザ会会員限定とすることも考えられる…

普及版では「部分図」という機能も不用かもしれない．部分図を止めるにはVB側で関係するコマンドを「不能」状態にするだけでも済むが，「部分図機能」に関わるモジュールをブロックとして切り出しておくことはシステム構成上意味がある．普及版から余分な機能を削ぎ落とすとしたら，①ファイル：追加読み込み，②一覧表のインポート/エクスポート，③親族図：軸線図法，④親族図：純血統図，⑤テーマの選択/登録なども対象になる可能性はある．というか，③はグラフ検証系を使っているので，もともと普及版には含まれていないと思う．

ともかく，完成させないことには始まらない．

▲カード写真を削除したとき，系図画面が更新されていない

▲「7」キーで「HOME」キーを代用するときの問題

▲軟体動物3.zelを閉じて，ZTシステム構成図7.ZELを開こうとして，freeblock::_releaseall_で停止．軟体動物3.zelではカード合併などの操作を行っている．テストバージョンは，UNDOサポート，ゴミ箱未サポート．軟体動物3.zelを開いて，閉じるだけで再現する．nodule：operator deleteでPHASE≦CHAOTICSTATEの場合はすべて削除としてある程度処理できるようになったが，totalblockが10個まで減少したところで，「**mptr** が 0xDDDDDDDD」という例外が発生した．

▲軟体動物3.zelを使ってカード合併のテスト中，RetrieveGhostで「すでに廃棄中のノード対」というエラーが出た．UNDO/REDO中には発生しない．マキガイとニマイガイを合体し，カタツムリとイカとタコを合体させて，カード数全20枚のところ，17枚になっている．

▲UNDOシステムを搭載していないZT BASIC版で源氏物語全系譜6.1.ZELの全体図を#235 常陸介の前の北の方で開き，浮舟の母の配偶者欄で「常陸介」→「7777常陸介」のように変更して「登録」すると，系統並び替え中TOPOLOGY::MakeActiveListでエラーが発生する．treeview->validcardとActiveList->countのカウントが一致していない．「7777常陸介」という新しいカードが生成されているので，有効なカード数は318から1増えて319になっているはずだが，ActiveList->countは318のままになっている．treeview->validcardはSetKinshipから得ているが，TOPOLOGY::validcardnumとも同期している．validcardnumはTOPOLOGY::HideNameboxでカウントされている．

ActiveListはTOPOLOGY::MakeActiveListで生成されているが，ここではPDB()->lookup->tableを使ってカードにアクセスしている．lookup->countが318のままになっている．CARDTABLE::makelinkでは以前はMakingLookUpを実行していたが，＠2018-02-1に 廃止された．同様に廃止された箇所が2箇所ある．MakingLookUpはルックアップテーブルを1から作り直す関数で，カードテーブルへのリンクの挿入と削除に際しては実行される必要がある．UNDOBASE：UndoProcessとCommandEndではつねにMakingLookUpが実行される．

MakingLookUpでテーブルの作り直しをしているのなら，個別にメンテナンスするより，系統並び替えで一度だけ更新するというのが早いのではないか？そうすれば，1箇所だけで済むようになるはずだ．それでもよいとは思われるが，現状を追認して，CARDTABLEとMARGTABLEのmakelink，FAMILYTREE::callSendCardで復活させることにする．削除の場合も必要になると思われるが，CARDTABLE：deletelinkの末尾で実行しているdecmaxrecnでMakingLookUpを実行するようにしたら，却ってエラーが出るようになってしまった．

これはVB側で出しているエラーだ．UpdateMaxCardはステータスバーを更新するための関数で，Z.RecordCountとZ.ActiveCountを比較している．Z.ActiveCountはおそらくActiveListのカウントに対応するものと思われるが，更新されていないため319になっている．Z.RecordCountはmaxRecordCountで取得された値で，lookupテーブルのカウントが入っている．MakingLookUpを実行しないようにすると，エラーは発生しないが，ステータスバーのカード数は319/319のまま更新されていない．つまり，誤った数字が表示されている．

問題は2つある．①MakingLookUpの実行後，Z.RecordCountとZ.ActiveCountで不一致が生じる，②系統並び替えを実行してActiveCountが更新されてもUpdateMaxCardが実行されない（ステータスバーが更新されない）⇒lookupテーブルはActiveListや部分図リスト構築のために使われているので，系統並び替えで一度だけ更新するというのでよいのではないか？まず，この修正を入れてみたい．バックアップを取ってからやることにしよう．

▲同上サンプルで常陸介を含む十数点のカードを選択→ 常陸介を削除で被参照カウントの残留が発生した．参照カウントが4残留している．参照はすべてMARGBOX[22]で「所属系列の先祖ノード人名リンクへの参照」が入っている．常陸介を単独削除しても同様事象が発生する．CARDLINK::DisposeではTRIBEBOX::CleanSansyoで先祖ノードからの参照をクリーンアップしているはずなのだが… これらの結婚枠はおそらくなんらかの事情で系列移籍が実行されたものではないかと思われる．所属系列の先祖と結婚枠が保持する先祖リンクが一致しない．

MARGBOX::CheckMargBoxChangedでこのような先祖リンクは積極的に解除するようにした．また，TRIBEBOX::CheckTribeでは「結婚リンクの先祖不在」を無視するようにした．実際，大半の結婚枠の先祖リンクは空になっている．⇒「7777常陸介」のカードが追加されたとき，一覧表が更新されていない．やはり，「系統並び替えで一度だけ更新」というのはダメのようだ．コマンド実行に対応するVB側の動作は「コマンド処理」のスコープで実行されなくてはならない．系統並び替えはそれと非同期に実行されるものなので，タイミング的に遅れてしまう．

元の論理に戻して，CARDTABLE::deletelinkとMARGTABLE：deletelinkでそれぞれMakingLookUpを実行するようにした．「UpdateMaxCard 不正なカード数」エラーが発生する件に関しては，maxcount < Z.ActiveCount に付け加えて Z.mSpanTreeNode() = 0 を見るようにした．これでエラーは回避できるようになった．

カード合併時には記録ページのマージが実行される．UNDOをサポートしていないシステムでこの辺りがどのような動作になっているのかが気になるところだ．⇒UNDOがサポートされていないシステムでは削除されたオブジェクトが復活するということはあり得ないから，特に何の問題も起きないと考えられる．2021年2月27日 のログではUNDOの問題が起きているが，この版の素性が問題だ．

UNDOをテストしているのだから，UNDOは実装されていたはずだが，ゴミ箱は外してあったのではないだろうか？多分，DEFINEUNDOSYSTEMだけがオンになっていたはずだ．ゴミ箱がなくても基本的にUNDOは動作する．Shadow付きのオブジェクトは削除されないからだ．しかし，写真や記録ページのようなfreeblockオブジェクトは削除されているはずだ．だとすれば明らかにUNDO/REDOで不具合が起きても不思議はない．まず，反例を確保する必要がある．

逆にZT Basicでは写真や記録ページをサポートしないという仕様も考えられるのだが… それも少しわびしい気持ちがする…

DEFINEUNDOSYSTEMをオン，それ以外のZT BASICでサポートされない（ゴミ箱を含む）機能をすべてオフにした版で軟体動物3.zelの動作を見てみたが，やはりUNDO/REDOはできない．ゴミ箱がある場合には，freeblockオブジェクトはゴミ箱に残っているので，それを参照するオブジェクトが復活した場合にも問題なく動作するが，メモリから完全にパージされてしまえばそれもできなくなる．しかし，ゴミ箱に入っているオブジェクトはリサイクルに回る可能性があるから，運が悪ければ同じようなエラーが起きる可能性はあると考えなくてはならない．

従って，UNDOをサポートしている場合には，ゴミ箱のあるなしに関わらず，freeblockオブジェクトをパージしないようにする必要があると考えられる．ゴミ箱に入らない場合にはフロート状態のオブジェクトとしてNリングに連結されるはずだ．freeblockオブジェクトにはカード記録ページやカード写真イメージの他に，データベースの作業域その他に用いるバッファ類やタイトル情報などがある．

多分タイトル情報はUNDOの対象になっていないはずだから，保護しなくてはならないfreeblockオブジェクトはMM_NOTEPAGEとMM_CARDIMAGEだけではないかと思われる．まず，これらのオブジェクトをパージしないという仕掛けを作ってみよう．⇒うまく行ったようだ．下図は，ニマイガイとマキガイをカード合併した図だ．

ニマイガイの下にマキガイの類が混載状態になっている．記録ページも両方のページを合体したものになっている．この動作はゴミ箱のあるなしに関わりなく，どちらでも動作するものになっている．これで一昨日出ていたバグは解決しているのではないかと思う．ま，まずい．UNDO/REDOの動作は確認したつもりだが，UNDOで戻ろうとしてエラーになった．ニマイガイの方はUNDOで戻ると記録ページも復元されているが，マキガイの方は写真も記録も消えてしまう．オブジェクト本体は残っているので，その限りではUNDOにはなっているが…

ビットマップはやや難しいところがあるので，記録ページのRTFの方を追いかけてみよう．⇒CARDLINK.CARDBASE.bitmapinfoとnotepageは空になっている．.cBitmapには値は残っているがパージされた状態になっている．まず，ゴミ箱付きのときの動作を確認してみよう．UNDOはうまく行ったが，REDOがおかしい．処理の途中でバックアップタイマーの割り込みが入って，作業域のためのメモリ要求が出されて記録ページが使われそうになっている．

このオブジェクトのsnumは131だが，NODULE.sizeが179603240というとんでもない数字になっている．その他の部分は概ねまともなので，どこかで書き込みが発生している可能性がある．というか，ここで例外が発生しているので，このアドレス自体すでにパージされている可能性がある．再起動して，バックアップタイマーを止め，ファイルをクローズしようとしてTRASHCAN::throwCanで停止した．

delete wasteで例外が発生している．NODULE.sizeは215179560という値になっている．このオブジェクトのsnumは232だ．⇒クリーンビルドで作り直したら動作するようになった．しかし，2回目のUNDOでまた引っかかった．freeblock::_delmem_でdelete mblockを実行しようとして例外が発生した．やはり，sizeに大きな数が書き込まれている．CARDBASEのデストラクタではcBitmapをdeleteし，bitmapinfoとnotepageをfreeblock::_delmem_している．

これでは写真や記録を復元することなどできないのではないだろうか？むしろ，これまで動いていたとすればその方が不思議という感じもする… 古いバージョンでは~CARDBASEでビットマップの破棄などをやっていなかったのではないだろうか？⇒~CARDBASEを無動作で抜けるようにして動作するようになった．

▲源氏物語全系譜6.1.ZELの全体図を#5 紫の上（若紫）で開いて，NAMEBOX::IsPossibleBTWLeftHand Sc=884 左手本人が不可視で停止した．障害ノードは #15496 明石中宮(1)で消去された仮ノード．ゼロ復帰しないとしたらどのような動作になるのか確認しておこう．⇒「右手配偶者カードリンク不一致」でゼロ復帰している．右手結婚枠はMARGBOX #1098：#1225 明石中宮(0)＋#1277 今上(0)→#1234 春宮(0)で，左手本人と右手本人が同一というシチュエーションだ．「左手本人が不可視」の検査を検査ルーチンの末尾に置いてみよう．

▲同上サンプルを#235 常陸介の前の北の方で開いてTRIBEBOX：hasPhysicalConnectionで停止した．(primenod->bigamist != realnode)というエラーが起きている．障害が起きているのは系列枠：snum=1544 primetype=3:婚姻関係 senzo=#424 一院 ＠10で，優先仮ノードはNAMEBOX #1382 浮舟の母(0)．優先実ノードはNAMEBOX #1732 常陸介(1)だ．浮舟の母(0)はBTW右手配偶者，常陸介(1)はBTW左手本人だが，primenod->bigamistには浮舟の母(1)が入っている．これはかなりおかしい．

確かにMARGBOX #1150：#1777 浮舟の母(1)＋#1778 常陸介(2)→#1398 蔵人右近将監(0)というBTWは成立している．逆に常陸介(1)が左手本人となるBTWは見当たらない．いや，#1778 常陸介(2)が右手配偶者となるBTWは発生している．このとき，#1732 常陸介(1)は左手本人になっている．とすれば，間違っているのはむしろ浮舟の母(0)がBTW右手配偶者ということになるのではないだろうか？いや，このBTWも存在している．#1382 浮舟の母(0)が右手配偶者，#1777 浮舟の母(1)が左手本人だ．このときの右手枠はMARGBOX #1082：#1270 八宮(0)＋#1382 浮舟の母(0)→#1291 浮舟(0)だ．

この結婚枠は後から，もう一度BTWになっている．どこかで解除されているのだろうか？浮舟の母(1)はMARGBOX #1150：#1777 浮舟の母(1)＋#1778 常陸介(2)→#1398 蔵人右近将監(0)のときには右手本人になっている．つまり，浮舟の母(1)は左手本人だが，右手本人でもある．何が問題となっているのだろう？右手本人と左手本人は複数のBTWに関係し得るが，右手配偶者の関わるBTWは一つしかないと考えられる．実際，浮舟の母(0)が右手配偶者となる結婚は#1082：#1270 八宮(0)＋#1382 浮舟の母(0)であり，常陸介とは直接関わりはない．

優先仮ノードの浮舟の母(0)は右手配偶者で一院系列，その左手本人である浮舟の母(1)は大臣（橋姫）系列で同時に右手本人，その右手配偶者の常陸介(2)の左手本人が優先実ノードの常陸介(1)で，所属系列は常陸介の前の北の方だ．浮舟の母(0)のbigamistつまり左手本人は浮舟の母(1)，浮舟の母(1)の右手配偶者の常陸介(2)のbigamistが優先実ノードの常陸介(1)になる．系列接続種別は婚姻関係となっているが，現行ルールではこのようなルーズな接続を認めている．ただし，それを正当化するのは難しい．今の場合で言えば

• 優先仮ノードがBTW右手配偶者で，その左手本人が優先実ノードでない場合でも，もし，その左手本人が同時に右手本人であるとすれば，
• その右手配偶者の左手本人が系列優先実ノードであれば正当と言える

のような感じになる．右手配偶者が同時に左手本人ないし，右手本人となる場合はあるだろうか？右手配偶者は原則として消去されているはずであり，逆に左手本人ないし右手本人は可視でなくてはならないと考えられるから，右手配偶者・左手本人ないし右手配偶者・右手本人ということはあり得ないと考えてよいはずだ．従って，優先仮ノードが右手配偶者で，その左手本人が優先実ノードでない場合には，左手本人が同時に右手本人である可能性を考えるのは妥当であるように思われる．

優先仮ノードが右手配偶者で優先実ノードが右手配偶者というケースはあり得るだろうか？一般には優先仮ノードは不可視，優先実ノード可視がノーマルな状態と考えられるので，実ノードが右手配偶者となるケースは除外してよいように思われる．従って，上の例外規則を適用すればある程度まではカバーできるのではないかと思われる．多少ややこしいが，実装してみよう．⇒動作している．

▲上記サンプルの画面で浮舟の母のカード画面上の子ども氏名欄で浮舟をダブルクリックしてTOPOLOGY::MakeActiveListのエラーが出た．(treeview->validcard != ActiveList->count)というエラーだ．validcard=319に対し，ActiveList->count=318になっている．氏名欄のダブルクリックで系統並び替えが発生するというのもおかしい．⇒再現しないが，ダブルクリックで新規カードを発行した後，UNDOで戻ると同じエラーが出る．浮舟の母の配偶者氏名欄に「7777常陸介」というのが入っているので，どこかで誤操作した可能性がある．

確かに，浮舟の母の配偶者氏名欄を「7777常陸介」のように書き換えて「登録」すると似たような事象が起きる．この後，UNDOしても元の状態には戻らない．これはUNDOの不備に依るものと思われるが，カウント不一致と合わせて別の機会に調べることにする．⇒この操作を行った後，ファイルを一旦閉じてもう一度開こうとしてハングする．freeblock::_releaseall_で失敗しているようだ．これはUNDOの不良と関係あるように思われる．⇒この版（ZT BASIC）ではUNDOをサポートしていないのにUNDOボタンが作動するというのがそもそも問題だ．

▲源氏物語全系譜6.1.ZELの直系親族図を#3 桐壷の更衣で開いて，「無効カードの仮ノード取り出し」エラーが起きた．⇒TRIBEBOX：GetAlternativePrimeNodeで無効カードを弾いていない．⇒対処した．

▲同上Ｚ木家系図を#5 紫の上（若紫）で開いて，出口検査のTRIBELIST::CheckTribeListで，TRIBEBOX::CheckTribeのエラーが発生した．結婚リンク無効/結婚リンクの先祖不在が発生している．10系列でこのようなエラーが発生している．⇒GetAlternativePrimeNodeで無効結婚リンクを弾いていない．⇒対処した．

源氏物語全系譜6.1.ZELの完全木テストが完了した．Basicエディションを開発機上でテストした．

この後は舞台をVAIO2に移してテストすることにする．Mouse Without BordersではLAN上の別のマシーンにドラッグ＆ドロップでファイルをコピーできる．これはすごい！他のマシンのデスクトップ上にドラッグするとMouseWithoutBordersという名前のフォルダを作ってそこに放り込んでくれる．…残念ながら，フォルダごとコピーすることはできない．「ZELKOVA 2021-02-26-1 – Folder is not supported, zip it first!」ZIPで圧縮しないとダメだと言われてしまった．⇒それでも，ZIPして解凍の方がLAN上(WiFi)でファイル転送より速い．最近の修正をフィックスしておこう．

1. 系列のSPOUSESENZO属性を廃止する＠20210224　25箇所
2. 仮修正 1箇所，#if 0 5箇所，#if 1 3箇所

上記の「7777常陸介」という問題を調べておこう．最初に「カード登録」で(treeview->validcard != ActiveList->count)のエラーが発生するが，その後のUNDOの問題を先に見ておこう．VB側ではZ.mUndoStatusの値を読み取ってそれを表示しているだけだ．mZelkova::mUndoStatusではCallGetUndoStatで状態を取り出している．⇒CallGetUndoStatでUNDO未サポートの場合は，引数のUNDOSTAT *undoの内容をゼロクリアして返すようにした．

以前，Ctrl+ZでUNDOが誤動作していたので，チェックしておこう．Ctrl+Zが押されると，CardUndoRedoが引数FALSEで呼び出される．Ctrl+Yが押されるとCardUndoRedoが引数TRUEで呼び出される．この関数では状態に関わりなくZ.mUndoRedoを呼び出しているが，状態を判定してから実行するように改めておこう．⇒対処した．併せて，UNDOSTATの定数を整備した．

▲上記サンプルでUNDO/REDOの操作を実行していて，freeblock：_delmem_で例外が発生した．freeblock *mblockの値がおかしい．REDOを実行中で，delete unode->addressで削除操作を実行しようとしたところだ．unode->addressに入っているオブジェクトは正常であるように見える．障害は~CARDLINK→ ~CARDBASEで起きている．記録ページを解放しようとしているところだ．

削除しようとしているカードは@176の常陸介でこの人名リンクのcardbase.notepageの内容がおかしいようだ．カード合併などもやっているので，その影響があるかもしれない．オリジナルのZELファイルでは常陸介の記録ページは白紙になっている．というか，UNDOシステムはゴミ箱が整備されていないと正しく動作しないのではないだろうか？カードの削除や追加などは一応動作しているようではあるが…

freeblockにはShadowというのがないのでストレートに削除されている可能性がある．この問題は別途調べることにしたいが，再現できるだろうか？以下の手順を試してみたが，再現できなかった．

1. 浮舟の母の配偶者欄で7777常陸介を登録→ 7777常陸介の新規カード
2. 浮舟の母の配偶者欄で7777常陸介→常陸介→登録→ 常陸介新規カード
3. 常陸介の新規カードとオリジナルの常陸介をカード合併
4. 常陸介と7777常陸介をカード合併
5. UNDO→UNDO→UNDO→UNDO→REDO→…

7777常陸介というカードが発生した原因は数字キーの7をHOMEのつもりで押していたためだ．テキストボックスにフォーカスがない場合には「7」キーでHOMEキーを代用できるのだが… 間違い易いかもしれない… この辺りも少し調べる必要がある．(treeview->validcard != ActiveList->count)のエラーが起きるのはUNDOシステムを実装していない場合に限られるようだ．

VAIO2でZTシステム構成図7.ZELの完全木テストが完了している．

このサンプルは開発環境では7.1.ZELの名前になっているので，リネームしておこう．ZTシステム構成図7.ZELをVAIO2にコピーしてテスト開始したところ，早速エラーが出た．

▲ZTシステム構成図7.ZEL 親族図:すべてのカード 基準ノード=#11 extraslot2を開いて，TRIBEBOX::DecidePrimaryNodeで停止した．系列優先仮ノードが空になっている．

源氏物語6.1.zelの完全木テストが完了している．実行環境は開発機，エディションはZT Basic．

この後のテストはVAIOで実行することにして，ZT Advanced（標準版）に戻ることにしよう．最近の修正をフィックスしてから始めることにする．

1. GENELIST：BASELISTを廃止する＠20210224　5箇所
2. GENELIST：domainを廃止する＠20210224　10箇所
3. 暫定 1箇所，#if 0 8箇所，#if 1 2箇所

どうも，やり損なってしまったようだ．TRIBEBOX::SetPotentialでエラーが出るようになった．このエラーは確認されているが，現在の環境では起きていないはずだ．もう一度作り直すしかない．「現状でフィックス」しているのだから，変化しているとすればどこかでやり損なっていると見るしかない．⇒原因はわかった．MARGBOX::getFloorとNAMEBOX::getFloorだ．#if 1でグラフ検証系オンの動作を実行するようになっていたのを修正で復元している．⇒元の論理の方が正しい．

ZT Basicは一応動くようになっているので，ZT Advancedのテストに掛かろう．源氏物語全系譜6.1.ZELの全体図を#1 光源氏で開くと，ShiftDirectAbsoluteで(card->getnodegene() – nbox->getFloor())というエラーが出ているが，エラーを無視して描画は可能なので，一旦置いて，ZTシステム構成図7.1.ZELで出ているバグのシューティングを急ぐことにする．⇒おかしい．ZTシステム構成図7.1.ZELが開けなくなってしまった．nodule::setNringでエラーが出ている．考え辛い．⇒リサイクルシステムに動作不良があるようだ．DEFINETRASHCANを一旦止めて動作するようになった．この障害は後で見ることにする．

▲標準版：ZTシステム構成図7.1.ZELの全体図を#24 UNDOCHAINでソートしてadjustGenerationRangeで停止．(tribelist->ZentaiMin != baselist->MinGeneration)が起きている．⇒このエラーはすでに解消しているが，系統並び替えの出口で垂直スプリットが検出される．

確かに物理世代13でスプリットになっているようだ．どうもあちこち具合が悪い．リリース版の動作もおかしい．サンプルを開いてスプリットになるのは仕方ないとしても，その後のファイルが開けない．新規ファイルさえオープンできない．強制的に新規ファイルを開いた後，CSVをインポートしようとしてハングしてしまう．お手上げだ．UNDOシステムのエラーまで出ている．ZT Basicでは源氏物語6.1.zelの完全木を通しているはずだが，VAIO2でエラーが出ているので，先にこちらを見ることにする．開発環境でも再現できる．

▲源氏物語全系譜6.1.ZELの全体図を#5 紫の上（若紫）で開いて，TRIBEBOX::originateで停止する． (getcritical(SPOUSESENZO)) エラーだ．HORIZONTALORDERフェーズのHorizontalArangement→ MoveRectRightHorizontallyで起きている．処理はすでにMainExperimentに入っている．SPOUSESENZOというのは，「BTW左手本人が系列先祖でかつ系列優先ノードの特殊BTWに関わる系列と左手本人およびその結婚枠」ということを意味する．つまり，「BTW左手本人が系列先祖でかつ系列優先ノード」であるような特殊な系列だ．

前回テストと今回の動作が異なるのは，前回のテストではMARGBOX：IsPrimeboxOrNotがつねにFALSEを返すような設定になっていたためと思われる．障害の起きている系列はTRIBEBOX #1612 先祖=#1321 源典侍(0)[29] 優先=#1321 源典侍(0)→#1749 光源氏(3) →主系列#1548:一院で，先祖ノードでかつ系列優先ノードのげ(0)がBTW左手本人になっている．BTW左手本人は可視ノードだから，このような条件が成立したからと言って特に不都合はないように思われる．しかし，その後のTRIBELIST::CheckAllBondedTribeでループカウントオーバーが発生してSUWになる．なぜだろう？

TRIBEBOX::CheckDirectSubTribeで「接触系列を親参照していない」という不良が起きて，「直属系列接続不良」という状態になっている．系列枠のbondageが空になっている．SPOUSESENZOはBONDEDTRIBE | MAGARIHOSEIとともに，IsBondedTribeの中に入っているのでbondageは主系列を指していなくてはならない．checkIfBondedTribeが空を返しているためだ．この関数ではIfContactParentBlockで上位系列との接触を検査している．

SPOUSESENZO属性を完全に廃止することにする．⇒バックアップに戻って作り直した．源氏物語6.1を開発環境でもう一度テストしてみる．エディションはZT Basicだ．

▲源氏物語全系譜6.1.ZELの全体図を#70 浮舟で開いて，NAMEBOX：ChangeTribeRealnodeで停止．「優先仮ノードが配偶者で逆婚姻関係でない接続」というエラーが起きている．#81 弘徽殿女御でも起きる．NAMEBOX::DoublyBlessedOneで「系列優先実ノードが右手配偶者の場合右手本人に切り替える」という措置を行っているところだ．DecideTribeTypeはPRIME_BTWLEFTを返している．これは「BTW左接続関係：両手に花左手本人→右手本人」だから正しい．ここではDecideTribeTypeの値をsetprimetypeするだけでよいのではないか？

ただし，今の場合，配偶者が左手本人になっているが，これでよいのだろうか？「右手配偶者が左手本人で停止＠20210108」というオプションもあるが，そのノードが可視である限りは配偶者が左手本人となることは可能なのではないだろうか？今の場合，系列優先仮ノードはNAMEBOX #1820 薫(3)で可視の配偶者，BTWの相手方はNAMEBOX #1294 女二宮（今上の）(0)だ．薫(3)の系列はTRIBEBOX #1602 先祖=#1443 小宰相の君(0)で，女二宮（今上の）(0)は一院系列だ．

この図面には薫は2箇所に登場する．浮舟の配偶者，および小宰相の君の配偶者だが，このレイアウトにはやや疑問がある．

薫は一院系列に女三宮の子どもとしてのポジションがあるのに，なぜ小宰相の君の配偶者などになっているのか？⇒理由はわかった．「基準ノードの配偶者の外部婚を排斥」というオプションが効いているからだ．これは「基準ノードの配偶者の外部婚は配偶者の配偶者側で展開する」ための例外規則で，基準ノードの配偶者の外部婚を基準ノードから遠ざけるための方策だ．このルールが妥当なものであるかどうかはもう少し見なくてはならない．⇒このオプションを外したら，薫のカードは3枚になったが，もう少し自然な図柄になった．

女二宮＋薫はBTWでカード消去できるはずだが，なぜそうなっていないのかは，後で見ることにする．以下の2つの障害の原因も「基準ノードの配偶者の外部婚を排斥」にあるようだ．

▲同上サンプルの#100 源典侍でNAMEBOX::IsPossibleBTWLeftHandで「右手配偶者が左手本人」というエラーが起きている．⇒このオプションは「左手本人が右手配偶者で停止＠20210108」に改名した．現行では「停止する」だけでBTW不成立としているが，BTW成立という動作も可能だ．その方が多重カード削減の効果はありそうだ．

▲同上サンプルの#221 源氏宮の母でCARDLINK::getnameboxのエラーが出た．配偶者不在でGP例外が起きている．

複数の障害が発生しているが，まずBASIC版で起きている不具合から見てゆくことにしよう．

▲BASIC版：源氏6.1.zelの全体図を#9 冷泉院で開いて，TRIBEBOX：SetPotentialで停止．(primary->getFloor() != pot)が起きている．このエラーはTribeRelocation出口で実行されるHeapTribeBoxesで起きている．障害が起きているのはTRIBEBOX #1540 先祖=#1231 一院(0)[1] 優先=#1628 冷泉院(1) 始系列で，基準ノードの物理世代番号5に対し，系統ポテンシャル値は4になっている．⇒基準ノードの相対世代番号（listdata.Generation）が1になっている．どこかでシフトされているのではないか？⇒いや，それ以前の問題だ．

TRIBELIST::GoDownStreamで基準ノードの冷泉院が冷泉院の御息所の配偶者として展開されている．GoDownStreamが縦型探索になっているということにも関わりはあるが，それより問題は，MARGBOX：IsPrimeboxOrNotの動作を「IsPrimeboxOrNotを有効化」オフで止めているという点にある．この一点だけでも，このオプションが不可欠であることは分かる．関連するオプションとして，「系列接続に関わる結婚の優先展開」や「基準ノードの配偶者の外部婚を排斥」もオンに戻しておこう．DEBUGオプションの「右手配偶者が左手本人で停止しない＠20210108」もオンとしておくのが安全だろう．⇒逆論理にしてオンに設定し，デフォルトオンのVERIFYに移した．

これでエラーは解消したが，グラフ検証系オフのときには，基準ノード/優先ノードの相対世代番号をゼロに正規化するという処理が入るはずなので，その辺りの動作を確認しておく必要がある．どこかで系列優先仮ノードが冷泉院(0)から(1)に切り替わっている．冷泉院の仮ノードは4つ出ている．

1. #1230 冷泉院(0) 先祖=一院 関係=配偶者
2. #1628 冷泉院(1) 先祖=一院 関係=配偶者
3. #1629 冷泉院(2) 先祖=一院 関係=実子
4. #1648 冷泉院(3) 先祖=一院 関係=養子

MakeUpTreeでは実子の(2)が基準ノードとして選択されているが，その後，SelectBaseBoxで配偶者の(0)に切り替わっている．この選択は誤っている．配偶者(0)はBTWが成立して不可視となり，再度SelectBaseBoxが呼び出されて(1)に切り替わる．このノードでSetPotentialのエラーが発生する．⇒このエラーを取るのはかなり難しい．SelectBaseBoxで可視で非配偶者の仮ノードがすでに選択されていない場合には再選択しないように修正してエラーは解消した．これで一応解決したということにしておこう．

▲ZT BASICで源氏物語全系譜6.1.ZELの全体図を#3 桐壷の更衣で開いて，TRIBEBOX::adjustGenerationRangeで停止した．(tribelist()->ZentaiMax != baselist->MaxGeneration)エラーが起きている．NormalizeRelativeGeneration→ SetTribeMaxGeneでTRIBELIST：ZentaiMinとZentaiMaxは更新しているが，baselist->MinGenerationとMaxGenerationとは同期していない．

このエラーが起きているのは，TRIBELIST::buildgenelist 世代枠リスト構築済みフラグが立っているためだ．SetTribeMaxGeneでUpdateGeneListを実行しようとすると，今度はdomain不在エラーが発生する．おそらく，domainはBUILDGENELISTフェーズでBuildGeneListを実行することで設定されているものと思われるが，baselistの生成時に設定するべきではないのだろうか？

GENELISTは2つリンクを持っているが，どちらもべた参照だ．あまり芳しくない設計だが… 特に世代枠リストの中に基本世代枠リストへのリンクを持つというのは不適当だ．まず，これを廃止できるかどうかを見てみよう．⇒簡単に廃止できた．基本世代枠リストの所在を尋ねるのなら，その所有者に尋ねるのが順当だ．domainも廃止してしまおう．その代わりにDomain関数を使えばよい．Domainは『参照』を返す関数になっているが，書き込み不要なのでリンクを返すだけでよい．GENELIST::InitializeGeneListも丸ごと廃止できる．

SetTribeMaxGeneでUpdateGeneListを実行するようにしているが，エラーが起きる．MinGeneration，MaxGenerationはすでに設定されているが，まだ世代枠が生成されていないため，動作不良が起きる．⇒この関数の中で調整することも不可能ではないが，世代枠リストはGoDownStreamとMakeUpTreeが完了した後にBUILDGENELISTで別途構成するようになっているので，buildgenelistフラグが立つのを待つというのでよいのではないか？⇒対処した．

昨日の修正を一旦白紙に戻してバックアップから出直すことにする．TRIBEBOX::setPotentialが最初に掛かってくるのは，TribeRelocationのAFTERMARGSAMEGENEで実行されるCheckTribeVerticalPositionだ．グラフ検証系が作動しているときにはSAMEGENEMARRIAGEで重婚クラスタ図が生成され，絶対世代番号が確定している．それと同等のことをグラフ検証系なしでやるとすれば，各ノードが保持している相対世代番号Generationを正規化するということではないだろうか？

TRIBELIST::NormalizeRelativeGenerationという関数を作って，TribeRelocationの冒頭で実行するようにした．この関数では「優先仮ノードの世代番号をゼロになるように系列内世代番号をシフト」して，「系列世代枠リストの最小/最大世代番号を更新」する．これで，「ZTシステム構成図7.1.ZELの全体図を#33 baselist 基本世代枠でソートして，TRIBEBOX::SetPotentialで停止」という問題は解決した．

▲ZTシステム構成図7.1.ZELの全体図を#24 UNDOCHAINでソートして，TRIBEBOX::InsertRingで停止した．世代枠不在が起きている．NormalizeRelativeGeneration実行後，StackTribeGeneを実施しているループの中で起きている．NormalizeRelativeGenerationの中で何らかの手当てをする必要がある．#57 BASETABLE，#58 ARRAY，#82 SIMPLEGRAPHなどでも発生する．

障害ノードはMARGBOX #690：#795 longtable(0)＋#755 RecordList(0)→で，世代番号は[1]．所属系列はTRIBEBOX #913 先祖=#795 longtable(0)だ．系列世代枠リストのMinGeneration=-1, MaxGeneration=0で要素数は2．この関数はStackTribeGeneの冒頭MakeGringから呼び出されているが，その直後に実行されるGenerationBoundaryの中でsetPotentialを実行しているので，呼び出しが早過ぎる．また，GenerationBoundaryの中でもMakeGringを実行しているので，ここで実行する必要はないと考えられる．⇒対処した．

▲同上サンプルの直系血族図を#15 selectedcardでソートして，GENELIST::GetGeneBoxで停止した．引数の物理世代番号が負になっている．AFTERMARGSAMEGENEフェーズのTribeGhostNameで起きている．NAMEBOX::getPairlistは引数のindex=0で呼び出されているが，対象人名枠のNAMEBOX #719 treeview(0)の物理世代番号が-1になっている．所属は始系列のTRIBEBOX #905 先祖=#716 coupling(0)[1] 優先=#730 selectedcard(0)．

最古世代先祖ノードはNAMEBOX #716 coupling(0)で物理世代番号は-3になっている．最古世代先祖は始系列に属している．この関数が呼び出されるまで，一度もTRIBEBOX::setPotentialが呼び出されていない．⇒NormalizeRelativeGenerationの中ですべての系列の系統ポテンシャルを設定するようにした．

▲同上サンプルの直系親族図を#2 kakeizuでソートしてGenerationBoundaryで停止した．#202 NODULEでも起きる．また，Ｚ木家系図 基準ノード=#2 kakeizu，．#202 NODULEでも起きている．障害ノードはTRIBEBOX #907 先祖=#771 COUPLING(0)で，(!getGeneBox(minGeneration) || !getGeneBox(maxGeneration))という理由で停止している．minGeneration=-1, maxGeneration=0．

この2つの値はTRIBEBOXのプロパティで系列世代枠リストのMinGenerationとMaxGenerationに相当するものと思われるが，NormalizeRelativeGenerationの中では設定されていない．これらは，TRIBEBOX::setMinGene，setMaxGeneで設定されている．⇒NormalizeRelativeGenerationの中で更新するようにした．

ZTシステム構成図7.1.ZELの完全木テストが完了した．

悪くない数字だ．最近の修正をフックスしておこう．

1. MoveLowerMargTreeではTYW枠は移動しない＠20210215　1箇所
2. PAIRBOX：setSectionを廃止する＠20210218　7箇所
3. NAMEBOX：shiftedonceを廃止する＠20210218　5箇所
4. TRIBEBOX：brokenを廃止する＠20210218　11箇所
5. Boject：nobori，kudari，unequalを廃止＠20210218　8箇所
6. checkBrotherOrderで微細な移動を実行する＠20210219→ 廃止
7. KeitoMin，KeitoMaxを廃止する＠20210220　11箇所
8. 仮修正 6箇所，OBSOLETE ２箇所

この後のテストはVAIO2で行うことにする．ここで標準版をビルドして別アプリ用にリリースしておこう．

▲標準版：ZTシステム構成図7.1.ZELの全体図を#24 UNDOCHAINでソートしてTRIBEBOX::adjustGenerationRangeで停止．(tribelist->ZentaiMin != baselist->MinGeneration)が起きている．

▲標準版：TRIBEBOX::SetPotentialで(primary->getFloor() != start->getPotential()) が発生する．

▲BASIC版：源氏6.1.zelの全体図を#9 冷泉院でソートして，TRIBEBOX::SetPotentialで停止．(primary->getFloor() != pot)が起きている．

▲ZTシステム構成図7.1.ZELの全体図を#33 baselist 基本世代枠でソートして，TRIBEBOX::SetPotentialで停止．基準ノードの物理世代番号と系統ポテンシャル値が一致しないというエラーが起きている．障害が起きているのは，始系列のTRIBEBOX #905 先祖=#716 coupling(0)[1] 優先=#748 baselist基本世代枠(0)で，系統ポテンシャル値は4，基準ノードの物理世代番号は3になっている．AFTERMARGSAMEGENEフェーズ「重婚グラフ検定の事後処理」の中でCheckTribeVerticalPositionを実行しているところだ．最古世代先祖ノードは始系列に属する #716 coupling(0)，つまり，始系列は系統最古系列でもある．

基準ノード世代=-1 先祖ノード世代=-4で確かに世代差は3だ．つまり，基準ノードの物理世代番号3というのは数字的には正しい．そもそも，基準ノード世代=-1というのがおかしい．この値はNAMEBOX::listdata.Generationに格納された値で，系列内の相対世代番号を表す数字だが，基準となるのは「系列優先ノード」であり，始系列の場合は基準ノードに該当するものであるのだから，つねにゼロでなくてはならないと考えられる．かなりややこしい問題がある．

基準ノードのbaselistから先祖ノードへの経路は少なくとも2つある．距離（世代差）3の経路と距離4の経路だ．上流検定ではより小さい数値が適用されるので，先祖ノードの世代値は-4となり，下流検定で基準ノードの世代値に-1が設定されることになる．これをいじると，今度は世代差が出てきて世代計算の根底が崩れてしまうようになるので，この状態で収めることを考えよう．

▲ZTシステム構成図7.1.ZELの全体図を#24 UNDOCHAINで開いて，TREEVIEW::InvestigateVSplitsの垂直スプリットエラーが発生する．⇒物理世代1～4でスプリットとされるが，画面で見た限りでは起きていないように見える．TREEVIEW::InvestigateVSplitsでダンプしてみると，mingene=0 maxgene=12 maxgene-mingene=12で描画要素はNAMEBOX #903 nodule(0)のindex=0を除き，index=6～12の間に分布している．実際の画面出力は8世代分しかないので，どこかで4世代分の齟齬が発生している．indexの値はgetFloorで得た物理世代番号ーmingeneだが，mingene=0なので実質物理世代番号で見ていることになる．つまり，物理世代番号が間違っていると推定される．

これは結局系列ポテンシャル値が不正ということになるので，それを設定している場所を調べてみよう．AFTERMARGSAMEGENEフェーズのCheckTribeVerticalPositionの中でGetPrimaryGapに従って設定されている．これは優先実ノードと仮ノードの相対的な世代差によって調整するものなので，始系列のPotential値が正しいということが前提となっている．TRIBEBOX::setpotentialにはシグネイチャの異なる3種があるので，　①callSetpotential，②Setpotential，③setpotentiaのようにリネームして識別するようにした．

callSetpotential→Setpotential→setpotentia

のような関係がある．callSetpotentialは現在の系列優先実仮ノードを引数にSetpotentialを呼び出し，SetpotentialはGetPotentialで得た値を引数にsetpotentiaを実行する．callSetpotentialは19箇所，Setpotentialは3箇所，setpotentialも3箇所から参照されている．始系列のPotential値を設定しているsetPotentialを見てみよう．

この系図には2つの系統がある．①#905 先祖=#739 UNDOCHAIN(0)系統，②#957 先祖=#903 nodule(0)系統．nodule(0)系統のポテンシャル値は一貫してゼロだが，UNDOCHAINのポテンシャルは0, 2, 5, 8, … のような変動を繰り返している．どうも，TRIBELIST：SetTribeMaxGeneにはかなり問題がありそうだ．

SetTribeMaxGeneを全面的に書き換えて，上記のような変動は解消した．現行では系列の世代枠リストは伸張の方向にしか変化しないようになっている．系統ポテンシャルに関係するのは，KeitoMaxだけだ．まず，KeitoMin，KeitoMaxのアクセス関数を作っておこう．SetTribeMaxGeneではKeitoMin，KeitoMaxを無条件で更新している．従って，硬直しているのはTRIBEBOX::minGenerationと推定される．

TRIBEBOX::minGenerationの書き換え関数setMinGeneは以下の3箇所から呼び出されている．①GoDownStream(void) (TRIBELIST)，②InsertRing(MARGBOX * mbox) (TRIBEBOX)，③adjustGenerationRange(int min, int max) (TRIBEBOX)，④clean(void) (TRIBEBOX)．④は初期化しているだけなので無関係．①は先祖ノードの世代を直接格納しているので問題ない．②では系列の世代枠が持つ結婚枠リングに結婚枠を登録する際に系列世代範囲が拡大した場合のみ更新している．

③adjustGenerationRangeでは(PHASE < BUILDGENELIST)の場合は無条件で書き換えを実施しているが，フェーズがBUILDGENELIST以上ではUpdateGeneListを実行した結果を転記している．UpdateGeneListでは世代枠リストが上下に伸張する方向でしか書き換えを実施していない．世代範囲が縮小した場合には空になった世代枠を削除して最小/最大世代番号を更新すればよいというだけだから，修正はそれほど難しくないと思われるが，現状のままでもそれほど不都合はないとも考えられる．問題は使われていない世代枠が存在する状態をスプリットと誤認する点にあると考えられるので，まず，これに対処することにしよう．

TREEVIEW::InvestigateVSplitsでは最初にmingeneとmaxgeneを現物オブジェクトから取り出している．この中でnodule(0)が唯一物理世代番号0となっているため，これに引きずられて0～12というレンジになってしまっている．これを避けるためにはどうしても最古世代系列を世代枠リストの先頭に配置しなくてはならない．このようなことになってしまうのは，世代計算で物理世代番号を使っているためと考えられる．当初は系統内でのみ通用する常用世代番号を使っていたはずだが，「重婚クラスタ検定」の導入により「確定世代番号」が適用できるようになったため，物理世代番号で処理するようになったものと思われる．物理世代番号を使うようになったもう一つの理由がある．ノード対を管理している基本世代枠リストが物理世代番号で管理されているためだ．

系統最古世代ないし，系統最古世代先祖ノードが確定できれば現行論理をあまり変えずに何とか対処できるのではないか？いや，どちらにしても世代枠リストで前詰めしないことにはどうにもならないのではないか？⇒画面上は問題なく描画できているのだから，問題をスプリット検定の問題として限定すべきではないか？考えられる方策としては検定を系統単位に分解することが考えられる．

TRIBELIST：HeapTribeBoxesで系統ポテンシャル値を再設定している．ここで系統最古世代先祖ノードの物理世代番号がゼロとなるように系統ポテンシャルを設定することで解決した．ただし，TRIBEBOX：setPotentialでKeitoMinと設定値が一致しないというエラーが出る．⇒「系統最古世代先祖ノードの物理世代番号がゼロ」というのが系統ポテンシャルの本来の定義なので，TRIBEBOX::SetPotentialをその趣旨で書き換えてみよう．⇒問題なさそうだ．

KeitoMinという値は，系統ポテンシャルを決定するときしか使われていないので廃止できるのではないか？というのは，系列世代枠リストは系列内の世代のみを扱い，基本世代枠リストは系統より広域な全域世代枠を扱っているからだ．一度バックアップを取ってから試してみることにしよう．⇒うまくいったようだ．

▲ZTシステム構成図7.1.ZELの全体図を#33 baselist 基本世代枠でソートして，TRIBEBOX::SetPotentialで停止した．基準ノードの物理世代番号と系統ポテンシャル値が一致しないというエラーだ．

▲源氏物語全系譜6.1.ZELの直系血族図 #318 右大弁（桐壷）で三極検定レッドラインオーバーが起きた．これはかなり信じ難い動作だ．右大弁（桐壷）は親なく子なく妻もなしなので，直系血族図には本人カード1枚しか残らないはずだ．それがエラーになるとは何かが「狂って」いる．REDLINE値がゼロになっている．現在この変数には「結婚数」が設定されている．⇒1よりも小さい値にならないよう修正した．

▲同上の傍系親族図を#5 紫の上（若紫）で開いて，TRIBEBOX：StackTribeGeneで停止した．completeの状態にある系列枠の検査でCheckMaximalSegment不合格になっている．この検査では「インター系列シンメトリ婚の場合は他系列での移動が配置に影響する場合がある」ため除外されている．障害が起きているのは，TRIBEBOX #1548 先祖=#1231 一院(0)[6] 優先=#1673 朱雀院(1)→#1347 源氏宮(0)で，主系列は主系列#1540:先帝だ．

StackTribeGeneではsetcompleteでCheckMaximalSegmentの検査を通している．セグメントは3つに分離している．①#1231 一院(0)とその結婚枠#1055：#1231 一院(0)＋→#1648 桐壷院(1)，②#1685 八宮の母女御(1)，③それ以外だ．八宮の母女御は何も特別な属性を持っていないが，たとえば，BTW解除などのことが起きているのではないか？⇒そういう状況ではないが，結婚点不一致が起きている可能性がある．⇒八宮の母女御の子ども枠はTYWになっているため結婚点一致できない．承香殿女御 （桐壷院の）→四宮 （桐壷院の）もTYWになっている．麗景殿女御 （桐壷院の）まではセグメント[4]になっている．また，②つのTYW枠も[4]になっている．

八宮の母女御だけが[6]という理由が分からない．⇒TRIBELIST::CheckMargBoxChangedの中で何らかの変異が起きている．おそらく，微細な調整で無視されているようなものだろう．

MARGBOX::checkBrotherOrderで移動量-1の移動が実行されている．この移動は誤差の範囲なので戻り値では返されていない．微細な移動は実行しないか，ないし実行して結果を報告するかの2択しかない．「微細な移動は実行しない」というのがもっとも確実だが，おそらく描画はやや精度を欠くものになる可能性は避けられない．実行した場合には最悪処理が発散ないし循環してしまう可能性がある．とりあえず，実行するという方向で修正してみよう．⇒少なくともこの反例に関してはこの修正で収まった．これでしばらく様子を見ることにしよう．

八宮の母女御の子ども枠はTWY解除されて直下に収まっている．承香殿女御のTYWは残っている．

ZT BASICで源氏物語全系譜6.1.ZELの完全木テストが通った．

この続きはVAIO2でやることにしよう．⇒早速エラーが出た．ZTシステム構成図7.ZELの全体図：#24 UNDOCHAINで垂直スプリットが発生している．ただし，開発環境では再現しない．サンプルは同じZTシステム構成図7.ZELだが，VAIOにあるのはカード数が1少ない．それだけでここまでの差が出るのかどうか？開発機では別のエラーが出た．

▲ZTシステム構成図7.ZELの法定親族図：#7 topologyでMPLCループレッドラインオーバーが発生した．⇒昨日の修正を戻して解消した．やはり，「checkBrotherOrderで微細な移動を実行する」というのは無理がある．以下のように仕様変更することにした．

1. checkBrotherOrderで計算誤差範囲の移動が発生した場合：
   移動は実行するが，crushはインクリメントしない
2. 移動を実行した場合には，対象系列をincompleteとする

NAMEBOX::originateでは変位が計算誤差を超える場合には，CancelStackを実行して系列枠をincompleteにしている．これをつねにCancelStackを実行するようにした場合には収束しなくなる可能性が出てくるので現状のままとする．この意味ではcheckBrotherOrderでも微細な移動はすべて無視するものとし，StackTribeGeneではCheckMaximalSegmentで停止しないようにするというのが一番合理的であるような気もする．⇒そのように対処した．

VAIOのZTシステム構成図7.zelを7.1.zelにリネームして開発機にコピーした．このサンプルを開くと開発機でもエラーを再現できる．

▲ZTシステム構成図7.1.ZELの全体図を#24 UNDOCHAINで開いて，TREEVIEW::InvestigateVSplitsの垂直スプリットエラーが発生する．しかし，実際にはスプリットは発生していないように見えるので，事実誤認が疑われる．

PAIRBOXの関数setSectionと変数sectionを廃止した．これらの値はダイナミックに変化するので値がつねに正当であることを保証できない．

▲ZTシステム構成図7の全体図を#92 Bobjectで開いて，NAMEBOX：makePairBoxで(common && common->CheckSamePoint())で停止した．⇒これはエラーではない．まだ端点共有していないためsamepointがCOMMON_NOCOMMONになっているというだけだ．⇒commonが端点共有束でない場合を検査から除外した．

ZT BASICによるZTシステム構成図7.ZELの完全木テストが完了した．前回より若干遅くなっている．

使用していない変数などを削除した．①PAIRBOX：setSectionを廃止，②NAMEBOX：shiftedonceを廃止，③TRIBEBOX：brokenを廃止，④Boject：nobori，kudari，unequalを廃止など．

▲源氏物語全系譜6.1.ZELの全体図を#123 左大臣の女御で開いて，三極検定ループカウントオーバーが発生した．障害はTRIBEBOX #1542 先祖=#1231 一院(0)[2] 優先=#1754 冷泉院(4)→#1230 冷泉院(0)で起きている．⇒三極検定レッドラインオーバーが発生した場合には，「レッドラインでZTYW/TYW婚を１個づつ停止しながら続行する＠20210218」ようにした．ZTYW婚は当初14個あったものが，12個まで削減されるとループから脱出できた．ただし，TribeRelocationのSYMMETRICGEOMETRYフェーズでCheckZeroPositionにより5個削減され，最終的には7個だけが生き延びている．

▲同上サンプルの直系血族図 #318 右大弁（桐壷）で三極検定レッドラインオーバーが起きた．