系列優先ノードの切り替えはEstablishMajorTribeChainの専管とする

源氏物語全系譜6.1.ZELの直系親族図を#125 髭黒で開いてNAMEBOX:MakeExtractBoxで停止する.oya->getmarglinkで空が返っている.getmarglinkは結婚枠の属する結婚リンクを求める関数だ.このチェックポイントは「全体図を#120 八宮の母女御でソートしてgetmargboxで停止するという障害の原因を突き止めるために暫定的に挿入したものだ.getmarglinkが空を返すというのはノーマルな動作だが,どのようなケースでそれが起きているのかを確認しておきたい.

抽出対象ノードはNAMEBOX #1593 蛍兵部卿宮(1)でMakeExtractBoxはNAMEBOX::CardShiftDirectの下位関数で,結婚枠内のノードとその下流系を抽出してその下にぶら下げる「長い尻尾」を構成するときに,その一段分の操作を実施する関数だ.この関数の主語は処理対象となる人名枠でoyaというのは,そのノードを格納している結婚枠であり,「親元結婚枠」である場合と,「抽出枠」である場合の2通りがある.今の場合はすでに1段目の処理は完了しているので,「抽出枠」だ.

この結婚枠はEXTRACTDUMMY|EXTRACTBOX|MOTHERLESSという属性を持っているので,「多重カード削減のためシフトされた抽出結婚枠」であることは間違いない.通常,結婚枠は結婚リンクに直接接続しているため,結婚リンクと一対一に対応しているが,抽出枠やTYW枠などは余分に追加された描画要素なので,変則的なトポロジーになっている.今の場合NAMEBOX #1839 蛍兵部卿宮(2)のNAMEsDUMMYスロットに接続している.蛍兵部卿宮(2)はEXTRACTDUMMYという属性を持っているので,「親元結婚枠」に残された代用ノードと思われる.

いずれにしても,親枠が結婚リンクを持たない場合があるということがわかった.しかし,これはかなり変則的な状態と考えられるので,このような状態を属性として保持しておくことにしよう.人名枠や結婚枠にはクリティカル属性というのがあるので,ここで設定することにする.HASNOMARGLINKという属性を新設し,NAMEBOXの場合にはsetmarglinkでセット/リセットするようにした.MARGBOXの場合は接続なので,MARGBOXのコンストラクタでチェックすることにする.

image

上図には「長い尻尾」が3本出現しているが,これは玉鬘と致仕太政大臣の親子関係から強制されるレイアウトだ.長い尻尾を使うことで玉鬘が多重となることを回避している.「全体図を#120 八宮の母女御でソートしてgetmargboxで停止」という元の問題に戻ってみよう.現行では重婚同類が存在するときにはShiftDirectAbsoluteを実行しないとしているので,停止しないようになっているが,ShiftDirectAbsoluteを実行するという論理に戻してみる.

NAMEBOX::getmargboxの出口検査で結婚枠不在で停止する.障害ノードはNAMEBOX #3416 桐壷院(2)で,クリティカル属性HASNOMARGLINKを持っている.NAMEBOX::TYW2ExtractBoxの主語は#1767 桐壷院(1)でTOOYOUNGWIFE属性を持ち,HASNOMARGLINKはオンになっている.桐壷院(1)の長い尻尾をDumpDummyChainで見ると,

1  thread        #3416 桐壷院(2) #3450 前春宮(1)
2  #3417 [結婚枠]:[2] #3424 桐壷院(3) #3452 前春宮(2)

のようなLDR束になっている.桐壷院(2)は親枠内のLDR,(3)はダミーノード,この下にTYW枠

MARGBOX #3425:#3424 桐壷院(3)+→#1767 桐壷院(1)

が配置されている.TYW2ExtractBoxではTYWチェーン先頭のLDRを固定ノードに切り替えてLDR束から外すだけで人名ノードの接続関係は変化していないはずだから,桐壷院(2)→ (3)→ (1)という順序も変化していないはずだ.このうち,HASNOMARGLINKは真ん中の(3)だけで,(2)と(1)は同じMARGLINK:#72 pnum=1 refnum=1 夫=CARDLINK:#424 @10一院[0] 妻=空 子=CARDLINK:#408 @2桐壷院[3]を参照している.さて,どこに問題があるのだろう?

NAMEBOX::resetghostbitsでは,「LDR束線分から離脱したときは,親参照を元の親の結婚枠に戻す@20210113」として,oya = getmargboxでoyaが空でなければ親参照を設定している.この処理は長い尻尾に属するすべてのノードを対象に実行されている.従って,中間にMARGLINKを持たないノードが出現するのは避けられないように思われるのだが… ⇒getmargboxではそれに備えた仕組みを備えている.つまり,対象ノードがダミーノードなどmarglinkを持たないオブジェクトの場合にはYリストを上昇して上位結婚枠を探すようになっている.

一般に系図木を階層的に見ると,人名枠と結婚枠がサンドイッチのように交互に層をなすようになっているから,本来なら必ず結婚枠を見つけることができなくてはならない.それができないのは,このノードがダミーノードとしてのEXTRACTDUMMY属性を失っているからだ.どこでそれがリセットされたかが問題だ.

このダミーチェーンは最初抽出枠チェーンとして生成された後,同じShiftDirectAbsoluteの中でExtractBox2TYWによってTYWに転換されている.このとき一度EXTRACTDUMMY属性をリセットされ,代わりにDUMMYBOX属性を与えられている.その後,SolveMargboxCollisionでTYW2ExtractBoxが実行され,resetghostbits(DUMMYBOX)でリセットされると同時に親参照付け替えのためにgetmargboxが呼び出されている.NAMEBOX::TYW2ExtractBoxではその直後にsetghostbits(EXTRACTDUMMY)が実行されるので,おそらく致命的な瑕疵にはなっていないのではないかと思われる.問題は解決した.桐壷院は結局,抽出枠で収まっているようだ.

image

重婚同類のときShiftDirectAbsoluteを実行することによる弊害というのがまだ残っている可能性もあるが,現在の構成で進めることにしよう.

同上サンプルの全体図を#191 左大臣(真木柱)でソートしてTRIBEBOX::SetMinorTribeで停止した.優先ノードが消去された仮ノードのとき,優先仮ノードの実ノードと系列の参照する実ノードが一致しないというエラーだ.障害が起きているのはTRIBEBOX #1569 先祖=#1258 一院(0)で,優先仮ノードはNAMEBOX #3476 冷泉院(5),実ノードはNAMEBOX #1371 左大臣の女御(0)だ.冷泉院(5)はLDRで関係は養子,左大臣の女御(0)は実子でいずれも本人ノードだ.BTW関係は成立していない.接続種別は婚姻関係になっている.

最終出力では左大臣の女御はBTWのRIGHTHUSBAND(右手結婚枠本人仮ノード)になっている.左大臣の女御は基準ノード左大臣 (真木柱)の子どもで,左大臣の女御+冷泉院には子どもがいないため,始系列にはこの2つのノードしか含まれない.

image

基準ノードの子どもを仮ノード消去するというのはよくないが,左大臣の女御+冷泉院の結婚が始系列で展開されているとすれば,そもそも仮ノード消去するようなことにはならないはずなのだが… まして,このノードがLDRというのは考えられない.どういう操作をするとそういうことになるのか?⇒いや,勘違いしていた.一院系列の冷泉院から左大臣系列への参照なのだから,そのようなことはあり得るかもしれない…

冷泉院(5)がLDR参照しているのは,同じ一院系列内の冷泉院(3)だ.このようなことはあり得るだろうか?冷泉院の仮ノードは5つあり,可視のものだけでも3個ある.ただし,うち一つはLDRなのでリアルに可視と言えば2つになる.これは避けられないだろう.最終的には一院系列は優先=#1766 冷泉院(3)→#1371 左大臣の女御(0)で収まっている.これはBTW左接続関係だ.「系列実ノードが一致しない」というエラーはDoublyBlessedOne→ ChangeRealRefferenceの過程で起きている.

この関数は,右手配偶者が実ノード参照されているとき,「右手配偶者が実ノードのときは左手本人に付け替える」ために実施されるもので,安定した状態とは言えない状況なので,OnEstablishMajorTribeChainの場合を除外しているように,除外してよいのではないかと思う.BTW処理中はOnDoublyBlessedOneが立っているので,これを見ることにしよう.⇒このエラーは回避できたが,別のエラーが残っている.

SetMinorTribe→ DoesMajorTribePathExistでhasPhysicalConnectionが呼び出され,(!realnode->getghostbits(REALGHOST))で停止するというエラーだ.⇒「ChangeRealRefferenceで系列優先ノードの切り替えは実施しない@20210119」ということにした.系列優先ノードの切り替えはEstablishMajorTribeChainの専管事項とし,BTWやTribeGhostNameは系列優先ノードの切り替えには関わらないというのがわかり易いと思う.

▲同上サンプルの直系親族図を#57 女三宮でソートして,NAMEBOX:TailSheddingで停止した.TRIBELIST::ShiftDirectAbsoluteで起きている.重婚同類が存在するので,オリジナル版ではパスされていたコードだ.ShiftDirectAbsoluteは重婚同類検定で決定した絶対世代番号に基づく垂直再配置なので,多重が入ってくると混乱が生じることは明らかだが,多重が存在する場合には重婚同類検定の結果がまったく使えないというのもおもしろくない話だ.

この辺りはもう少し改善の余地があると思われるので,追求してみたい.そのためには,重婚同類検定(以下多重検定)でどんなことをやっているのかを調べてみなくてはならない.多重検定ではグラフを3つも使っている.どんな用途で使っているのかをまず調べてみよう.

エラーを無視して続行で描画まで進むことはできる.多少不自然なところはあるが,何とかこなしているようだ.

image

重婚同類が3で多重が10発生している.うち1件は基準ノード自身の多重だ.系列は4系列でほとんどすべての領域を占める始系列の一院系列と,それに埋め込まれた二条太政大臣系列,※3系列,先帝系列からなる.後の3つはいずれも構成メンバー3~4の小さな系列だ.障害が起きているのはNAMEBOX #1927 光源氏(2)で,仮ノードと実ノードの世代差が-1になっている.

コメントを残す

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

CAPTCHA