ダミー枠チェーン上の結婚枠直列検査

源氏物語全系譜6.1.ZELの傍系親族図を#8 夕霧で開いて,MARGBOX:GetUpperNodeで停止する.TYW枠 #2396:#2438 弘徽殿女御(3)+→#1704 弘徽殿女御(1)の直上に親ノードの#2438 弘徽殿女御(3)が存在しないという状態になっている.これは,#2347 紅梅(1)でTailSheddingを実行したとき,紅梅のTYW枠#2348:#2541 紅梅(2)+→#1328 紅梅(0)を一旦取り外す操作に弘徽殿女御のスレッドを巻き込んでしまっているためと推定される.

TailSheddingでは,長い尻尾の末尾に接続するTYW枠を対象に取り出しを実施しているが,このケースのように複数のTWY枠が接続していることを想定していない.⇒いや,スレッド自体は区別されている.長い尻尾は独自のldrchainによって独立したチェーンを構成しているから,取り出そうとしているTYW枠自体は間違っていない.youngwife->CutBranch(false)の操作で誤っているのではないだろうか?⇒いや,CutBranchではまだ誤操作されていない.その次のyoungwife->Disconnectではないか?いや,ここでも問題は生じていない.むしろ,TYW枠をつなぎ戻すところでやり損なっているのではないだろうか?MakeLongTailが元凶であるように思われる.

NAMEBOX::MakeLongTail→ makeLongTailは「LDR束代表ノードが所有するLDR束のデータ整合性をチェックする」という関数だ.makeLongTailの中で不良が検出されている.不良スレッド thread=NAMEBOX #2395 弘徽殿女御(2) この処理ではMakeLongTailの戻り値はチェックされていないが,現在の不具合と関係がある可能性はある.⇒暫定的にエラーで停止するようにしておいたが,このエラーは座標に関するもので現在の問題とは直接関わっていないような気がする.問題はMakeLongTailではTYW枠の存在がほとんど無視されているように思われる点だ.不良はmakeLongTail→ CheckDummyBox→ CheckDummyBoxSerialで起きている.

この関数は「代表LDRノードのダミー枠チェーン上のすべてのダミー枠につきダミー枠直列を検査」している.ダミー枠直列というのは,結婚枠がYリスト上で直列に並んでしまう事象を指すものと思われる.これは拡張子ども枠などの場合に起こり得る現象だ.「ダミー枠直列」として,NAMEBOX #2347 紅梅(1) のスレッドで,MARGBOX #2435:#2347 紅梅(1)+→#2438 弘徽殿女御(3)とMARGBOX #2348:#2347 紅梅(1)+→#1328 紅梅(0)が直列であることが検出され,その結婚枠がTYW枠である場合には,それをYリストから切り出した後,長い尻尾の末尾に繋ぎ変えている.

image

紅梅(1)はLDR束の代表ノードでdummyboxにはMARGBOX #2435:#2347 紅梅(1)+→#2438 弘徽殿女御(3)が入っている.このダミー枠にはNAMEBOX #2438 弘徽殿女御(3)しか入っていない.従って,紅梅(1)の長い尻尾終端は弘徽殿女御(3)ということになり,TYW枠MARGBOX #2348:#2347 紅梅(1)+→#1328 紅梅(0)はこのノードの後ろに挿入されるため,#2396 MARGBOX→ #2348MARGBOX→ #2436 NAMEBOXという並びになってしまう.

MARGBOX #2435とMARGBOX #2348が直列になるというのは確かにおかしいが,今の場合#2348は紅梅(1)に直結されなくてはならないはずだ.しかし,TYW枠というのはダミー枠には勘定されないから,MARGBOX #2348の居場所がないということになる.これは想定外の構図なのだろうか?紅梅(2)が削除される前の状態をもう一度チェックしてみよう.最初の図式では紅梅(2)と弘徽殿女御(3)はともに終端ノードなのでその先にTYWをぶら下げても矛盾は生じないが,親元結婚枠内のLDRに直結するTYW枠の場合,ダミー枠と直列構造になることは避けられない.問題はこのときの移動先が間違っているということではないだろうか?ダミーノードはldrchainでリンクされているが,LDRからダミーノードへのリンクがかなりあいまいになっているような気がする.

LDR→ TYW枠はtooyoungで参照できるが,LDR→ダミーノードへの参照が存在しない.これは世代差ゼロのTYW枠,つまり,ZTYW枠とはまた別の話だ.⇒いや,少し誤解している.LDRもldrchainを使っている.TYW枠を持つLDRのldrchainが空であるということは,そのノードが長い尻尾の末尾であることを示している.このノードが代表ノードであるときには,ダミー枠直列というのはノーマルと考えてよいはずだ.⇒CheckDummyBoxSerialで直列枠がTYW枠のときは,GetTYWElderでELDERWIFEを取り出し,longtailの末尾を取り出すようにした.

同上サンプルの傍系親族図を#151 左大臣の姫君でソートして,NAMEBOX::makePairBoxで停止した.NOCOMMON属性未設定がPAIRBOX #2049:#2046 玉鬘(2)→#1254(0)で起きている.対象ノードはNAMEBOX #1596 秋好中宮(1).このエラーを補正するにはPAIRBOX::CheckNoCommonEndPointを実行しなくてはならないが,CheckNoCommonEndPointはNAMEBOX::makePairBoxでノード対生成時に一度チェックされる他は,PAIRLIST::RepairPairBoxが回ってこないと補正されない.従って,秋好中宮(1)のノード対生成時にこの事実が判明していないのは避けられない.

いや,端点共有があるときは,SwapBundledPairが実行されている.この中で検査していないということは考え辛い.⇒SwapBundledPairの中でノード対のNOCOMMONPAIR属性をチェックするのではなく,直接CheckNoCommonEndPointを実行するようにした.

同上サンプルの法定親族図を#104 藤壷の宮でソートして,PAIRBOX:RepairCommonEndPointで停止した.端点一致でsamepointゼロエラーが,PAIRBOX #2072:#2067 弘徽殿女御(2)→#1329(0)で起きている.対象ノード対はPAIRBOX #2072:#2067 弘徽殿女御(2)→#1329(0).このノード対は「端点一致でsamepointゼロ」という理由でRepairCommonEndPointを実行しているのに,状態が変化していない.

RepairPairBoxでチャンネルの付け替えが実施され,チャンネル0→2に移動している.このあと,MoveSamePointでチャンネル0への移動が実施されるが,この関数の中で「最大区間でないnocommonを別チャンネルに移動」が発生し,PAIRBOX #2028:#2025 玉鬘(2)→#1254(0)が別チャンネルに移動している.このとき,弘徽殿女御のノード対も一緒に移動しているものと見られる.

MoveSamePointでSwapBundledPairを実行するまではsamepointは値を持っているが,最大区間が逆転しているため切り離されて元の状態に戻っている.これは,端点共有と認定しているところで間違っていると考えられる.少なくとも共有端点ノード対がNOCOMMONであるか否か,もし,NOCOMMONならノード対の区間と比較する必要がある.

PAIRBOX::searchCommonPairが誤認定していると見るべきではないか?⇒Bobject::getCommonPairTypeではNOCOMMONPAIRクリティカル属性を見るのではなく,直接CheckNoCommonEndPointを実行するようにした.また,getCommonPairTypeの呼び出し側では,実ノードのNoCommonGoodSonを実行するか,ないしCheckNoCommonEndPointを実行するようにした.

image

▲同上サンプルのZ木家系図 基準ノード=#74 薫の出口検査でTREEVIEW::InvestigateVSplits 垂直スプリット発生

コメントを残す

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

CAPTCHA