TRIBEBOX::decidePrimaryNodeで系列優先ノード決定不能が起きる

▲BUG20-12-20 00-37-44.ZELを開いて，TRIBEBOX：decidePrimaryNodeで系列優先ノード決定不能が起きる．障害が起きているのは[系列枠]: #921 先祖=#405 ※３で優先ノード候補は#338 ＠4明石中宮だが，TRIBEBOX::GetRealnodeで有効な実ノードが選択できないため，リジェクトされている．

かなり難しい問題だ．ある意味で現行方式が破綻していると言っても過言ではない．ZTは当初実親子関係しか扱っていなかったが，養親子関係が導入された後でも基本的な構成規則である「すべての人名はいずれかの系列に所属するという」という原則が踏襲されてきた．養親子関係をサポートするためにはこの原則を緩和するしかないのだが，原則それ自体の見直しが行われることがなかったため，不良が潜伏していつか露見するという宿命を負っていたのではないだろうか？

現行ではたとえば，CARDLINK::ancetryには所属系列の先祖ノードへの参照が格納されるようになっている．これは，つまり，ある系列に所属する人名は他の系列に所属することはできないことを暗に示している．実際には，養親子関係を含む系図を扱っている以上，運用的にそれをカバーしてきたものと思われるが，原理的に整合していないのでどこかで破綻することは避けられない．どこをどう改訂ないし改善すればよいのか？TOPOLOGY::topologicalSortをフェーズで区分すると，

1. TOPOLOGICALSORT　系統並び替え開始
2. CLEARTABL　テーブル初期化
3. EXTRACTPARTIAL　部分図ノードの抽出
4. SETBASECARD　基準ノード設定
5. KINSHIPDEGREE　予備検定（親等計算）
6. DECOMPOSITION　本検定（系列分解）
7. PHYLETICTREE　系列枠の生成と世代計算
8. GODOWNSTREAM　系図木生成と展開：グループﾟを設定
9. MAKEUPTREE　系図木構築：Ｙリストへの繋ぎ込み
10. SETSIBLINGS　拡張子ども枠の設定
11. SETRELATIVE　系図木相対領域計算中
12. BUILDGENELIST　基本/系列世代枠リストの生成
13. SOLVECOLLISION　系列内同世代結婚枠の衝突解消処理
14. BUILDCENTERLINE　血統軸線図の構築
15. TRIBERELOCATION　系列枠再配置
16. SAMEGENEMARRIAGE　重婚同類グラフを生成
17. AFTERMARGSAMEGENE　重婚同類グラフの後処理
18. SYMMETRICGEOMETRY　シンメトリ婚を展開する
19. MAINEXPERIMENT　系列間衝突回避処理
20. HORIZONTALORDER　先祖並び自動オフ時の系列水平配置
21. FOLDINGCHANNELS　チャンネル数自動のときのチャンネル整理
22. HEAPTRIBEBOX　系列枠包括領域集積
23. MAKEABSOLUTE　絶対座標系変換
24. SETTITLEBOX　系図外枠矩形領域を最終決定
25. DRAWSTAGE　系図木描画準備完了

のようになる．ただし，最後のDRAWSTAGEはCOUPLING：TopologicalSortで設定される．いま問題になっているところは（6）DECOMPOSITION　から（9）MAKEUPTREEまでの処理と考えられるので，そこだけを抽出すると，

1. DECOMPOSITION　本検定（系列分解）
2. PHYLETICTREE　系列枠の生成と世代計算
3. GODOWNSTREAM　系図木生成と展開：グループﾟを設定
4. MAKEUPTREE　系図木構築：Ｙリストへの繋ぎ込み

のようになる．（1）DECOMPOSITIONではすべてのノード（人名リンク）に先祖ノードを割り当てて，排他的な系列に分解する．（2）では系列枠オブジェクトを生成して，系列枠リストを構成する．（3）GODOWNSTREAMでは各系列の先祖ノードからの下流検定を実施して，人名枠オブジェクト（仮ノード）を生成し，系列の最小・最大世代番号を決定する，（4）MAKEUPTREEでは系図木（描画リスト）を生成し，すべての描画要素の初期化を行う．エラーが出ているのは（4）のMAKEUPTREEだ．

▲フェーズの整理を行っていて，エラーが出た．上のリストで18. SYMMETRICGEOMETRY シンメトリ婚を展開するを実行している場所は実際には，21. FOLDINGCHANNELS チャンネル数自動のときのチャンネル整理の直前に移動しているので，SYMMETRICGEOMETRYの値を変更したところ，フローはまったく変化していないも関わらず，エラーが出るようになった．COUPLING::TopologicalSortの出口検査で(SymmetryList && SymmetryList->len() != SYM) で停止している．

SYMMETRICGEOMETRYの値が変化したことより，TOPOLOGY：BuildSymmetryListの直前でPHASEにSYMMETRICGEOMETRYをセットしていることが障害の原因となっている．BuildSymmetryListの中でフェーズによって処理が分岐するようになっているのではないか？⇒いや，BuildSymmetryListの後でCheckMultiCardsを実行してもエラーにはならない．BuildSymmetryListでフェーズをセットしなければエラーは回避できるが，なぜこのようなエラーが出るのかについては追求する必要がある．⇒原因は大体つかめた．

3つパターンがある．①オリジナルパターン→エラーなし，②BuildSymmetryList値を変更のみ→エラーなし③SYMMETRICGEOMETRY値を変更，BuildSymmetryList前でフェーズ設定→エラー発生．エラーはTOPOLOGY::SymmetryListのカウントと系列枠にセットされたカウントの合計が一致しないというものだが，実際にはTOPOLOGY::SymmetryListのカウントゼロで系列枠のシンメトリ婚カウント1という状況だ．

①のオリジナルコードの場合には，BuildSymmetryListの実行時のフェーズがSYMMETRICGEOMETRYと異なるため，MARGBOX：getSymmetricLeftBoxで厳格な条件が要求されるためシンメトリ婚不成立となっている．また，②の場合は，BuildSymmetryList実行時のフェーズ番号がSYMMETRICGEOMETRYよりも小さくて無動作で抜けているのでやはりシンメトリ婚不成立となり，不一致は生じない．③の場合はBuildSymmetryListの実行時フェーズがSYMMETRICGEOMETRYと一致するため条件が緩和されて，シンメトリ婚が成立，おそらく後に破棄されたためカウント不一致になるのだろう．

構成規則が時と場合によって厳しくなったり緩和されたりするという仕様はかなり問題があるので統一した方がよいと考えるが，カウント不一致というのはまた別の問題なので，まず先にこちらをクリアしておこう．⇒対処した．⇒今度は系列枠のSymmetryCountの方が少なくなってしまった．Ancesry.zelを開いて不一致が発生する．SymmetryListというのはMARGBOXを要素とするリストだ．シンメトリ婚に設定されると，その結婚枠はSYMMETRICMARGという属性を持つようになる．

SYMMETRICMARGがセットされるのはBuildSymmetryListの中だけで，このときは系列枠のSymmetryCountも同時にインクリメントされている．また，この値がリセットされるのはMARGBOX：AbandonSymmetricの中だけで，今回の修正はこの関数に関わるものだ．SymmetryCountのデクリメントはresetghostbits（SYMMETRICMARG）で実行される．resetghostbitsを呼ばずに直接リストからパージして，SymmetryCountをデクリメントしている箇所もあったが，すべてresetghostbitsで操作するように修正した．

ただし，resetghostbitsの中の論理にもミスがあった．SymmetryList->Removeの戻り値を見てカウントダウンしていた．LIST::Removeは現在リスト長を返すような仕様になっている．Ancestry.zelでシンメトリが崩れているという現象は大分前から出ているが，落ち着いてから調べることにする．最初の問題に戻ろう．

▲MARGBOX：getSymmetricLeftBoxでSYMMETRICGEOMETRYのときに限ってシンメトリ婚成立の条件を緩和している

▲Ancestry.zelでシンメトリが崩れている

DECOMPOSITIONではまだ描画オブジェクトは生成されていないので，人名リンクベースで人名をグループ分けしたものを系列と称しているに過ぎない．PHYLETICTREEでは先祖ノードを頂点とする系列枠オブジェクトが具体的に生成される．次のGODOWNSTREAMでは先祖ノードの下流系を展開してメンバーとその配偶者の人名枠を生成し，その所属を決定する．最後のMAKEUPTREEでは系列優先ノードを（最終）決定し，系列の相互位置関係を確定する．

見た限りではどうも三番目のGODOWNSTREAMに問題があるように思われる．ここでは，所属系列の移動ということがかなり頻繁に起こっているため，どこかに盲点が発生しそうな感触がある．

NAMEBOX #339 明石中宮(0)はPHYLETICTREEフェーズで[系列枠]: #917 先祖=#509 先帝(0)に振り分けられているが，GODOWNSTREAMに入って，※３系列に移動している．先帝系列は系列枠リスト上では※３系列より先にあるのに，明石中宮の人名リンクが先帝系列で展開されないという理由が分からない．このサンプルには系列が89個含まれているが，最初の7つまで表示すると，

1. #915 先祖=#701 式部卿宮の北の方(0) 優先=式部卿宮の北の方 始系列 type=始系列
2. #917 先祖=#509 先帝(0) 優先=式部卿宮  type=婚姻関係
3. #919 先祖=#557 ※６(0) 優先=先帝の后宮  type=婚姻関係
4. #921 先祖=#405 ※３(0) 優先=明石中宮  type=親元関係
5. #923 先祖=#603 中務宮(0) 優先=明石の尼君  type=婚姻関係
6. #925 先祖=#637 右大臣（明石）(0) 優先=髭黒  type=婚姻関係
7. #927 先祖=#589 按察の大納言（若紫）(0) 優先=紫の上の母  type=婚姻関係

のようになっている．※３系列は順位からいくと4番目だ．