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

▲BUG20-12-20 00-37-44.ZELを開いて,TRIBEBOX:decidePrimaryNodeで系列優先ノード決定不能が起きる.障害が起きているのは[系列枠]: #921 先祖=#405 ※3で優先ノード候補は#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 系図木構築:Yリストへの繋ぎ込み
  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 系図木構築:Yリストへの繋ぎ込み

のようになる.(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に入って,※3系列に移動している.先帝系列は系列枠リスト上では※3系列より先にあるのに,明石中宮の人名リンクが先帝系列で展開されないという理由が分からない.このサンプルには系列が89個含まれているが,最初の7つまで表示すると,

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

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

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA