▲源氏物語全系譜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リストから切り出した後，長い尻尾の末尾に繋ぎ変えている．

紅梅(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を実行するようにした．

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

▲源氏物語全系譜6.1.ZELの直系親族図を#57 女三宮でソートして，TRIBELIST::ShiftDirectAbsolute→ NAMEBOX：TailSheddingで停止．TailSheddingはトカゲの尻尾切り(tail shedding)のように長い尻尾を切り詰める操作だ．仮ノードと実ノードの世代差をD，長い尻尾の長さをLとしてdiff = L-Dだけ短縮されるが，diffが負の場合は操作できないためエラーになる．ShiftDirectAbsoluteではカードを絶対世代番号で指定された位置にシフトして重婚同類検定の結果を図面に反映させようとしているが，重婚同類循環が発生している場合には絶対世代番号を一意に決定することができないため，矛盾が生じているものと考えられる．

従来仕様では重婚同類循環が検出された場合にはShiftDirectAbsoluteを実行しないようになっていたのだが，可能な限り適用するというのが現在の方針だ．，まず，diffが負のときには無動作で抜けるように修正してみよう．⇒停止しないで描画できるようになった．このような事象は光源氏(2)と朱雀院(1)で起きている．TailSheddingでは差分がゼロのときには「LDRノード対の世代差がゼロになったときは仮ノード消去に転換する」という処理が組み込まれている．

また，TOPOLOGY::CheckShiftedPairBoxでは差分が負の場合はノード対を破棄するという処理を実行しているので，この論理をTailShedding本体に組み入れてみよう．⇒出力はかなり変わった．光源氏(0)と朱雀院(0)の頭に入っていた連結線が消え，桐壷の更衣→光源氏，弘徽殿大后→朱雀院が直結するようになった．

図面的にはこの方がわかり易い．修正前の図面を出してみよう．

コンポーネントは同一で，それらが水平シフトしているだけの違いだが，（修正後の方が）変に込み入ったところがないのがよいと思う．

▲同上サンプルの傍系親族図を#6 玉鬘でソートしてTRIBEBOX：SetMinorTribeで停止した．系列優先実ノードと優先仮ノードの実ノードが異なるというエラーだ．⇒NAMEBOX：DoublyBlessedOneでOnDoublyBlessedOneである区間を延長して，ChangeTribeRealnodeを実行しているブロックを含むようにした．また，これと付随して，hasPhysicalConnectionでこれまで優先仮ノードが(PRIMGHOST | ELDERWIFE))属性を持つ場合はつねに物理コネクション成立としていたのを，「実ノード不一致」と「実ノード属性不正」では不成立とした．

▲同上サンプルの傍系親族図を#8 夕霧でソートしてMARGBOX：GetUpperNodeで停止した．MakePairListClean実行中，CheckPassingPoint→ NoCommonGoodSon→ GetUpperNodeで起きている．障害が起きているのはMARGBOX #2396：#2438 弘徽殿女御(3)＋→#1704 弘徽殿女御(1)で，TOOYOUNGWIFE｜MOTHERLESS属性とHASNOMARGLINKクリティカル属性を持っている．

HASNOMARGLINKは「結婚リンクに接続していない結婚枠」の意味で，#2438 弘徽殿女御(3)に接続している．しかし，この結婚枠の上流には弘徽殿女御(3)は出てこない．このパスは#1324 致仕太政大臣(0)まで続いているが，弘徽殿女御(3)はその経路上に現れない．

この結婚枠の上にはMARGBOX #2348：#2541 紅梅(2)＋→#1328 紅梅(0)があり，その上のノードはNAMEBOX #2541 紅梅(2)だ．MARGBOX #2348もMARGBOX #2396とまったく同じ属性を持っているのでTYW枠と考えられる．紅梅(2)はダミーノードでその上にMARGBOX #2435：#1700 柏木(2)＋→#2541 紅梅(2)があり，その上がNAMEBOX #2347 紅梅(1) でEXTRACTBOX｜ELDERWIFEになる．#2438 弘徽殿女御(3)の長い尻尾をDumpLongTail で見ると，

NAMEBOX::DumpLongTail >>>>>>>>>> #2438 弘徽殿女御(3)
   1  dum#=1 #1700 柏木(2)
   1  dum#=2 #2347 紅梅(1)
   2  dum#=2 #2541 紅梅(2)
   1  dum#=3 #2395 弘徽殿女御(2)
   2  dum#=3 #2438 弘徽殿女御(3)
NAMEBOX::DumpDummyChain >>>>>>>>>>>
   1  thread　#1700 柏木(2) #2347 紅梅(1) #2395 弘徽殿女御(2)
   2  #2435 [結婚枠]：[4] #2541 紅梅(2) #2438 弘徽殿女御(3)
NAMEBOX::DumpLongTail <<<<<<<<<<<<

のような3本のスレッドからなるLDR束になっている．#2541 紅梅(2) と#2438 弘徽殿女御(3)は一つのダミー枠に入っているので，その下位のMARGBOX #2396が上位の#2541 紅梅(2)を参照しているというのはノーマルなのではないだろうか？#2438 弘徽殿女御(3)はDUMMYBOX｜BUNDLEDSTRINGという属性を持っている．この結婚枠のownerは弘徽殿女御(0)だ．

障害はNAMEBOX::TailSheddingで発生している．NAMEBOX #2347 紅梅(1)の長い尻尾の始末を付ける段で，同じLDR束に入っている#2438 弘徽殿女御(3)が影響を受けているものと見られる．処理開始前の状態は下記のようになっている．

NAMEBOX::DumpLongTail NAMEBOX::TailShedding >>>>>>>>>> #2347 紅梅(1)
   1  dum#=1 #1700 柏木(2)
   1  dum#=2 #2347 紅梅(1)
   1  dum#=3 #2395 弘徽殿女御(2)
   2  dum#=3 #2438 弘徽殿女御(3)
NAMEBOX::DumpDummyChain NAMEBOX::TailShedding >>>>>
   1  thread　#1700 柏木(2) #2347 紅梅(1) #2395 弘徽殿女御(2)
   2  #2435 [結婚枠]：[4] #2438 弘徽殿女御(3)
NAMEBOX::DumpLongTail NAMEBOX::TailShedding <<<<<

TailShedding実施後は下記のようになっている．

NAMEBOX::DumpLongTail NAMEBOX::TailShedding >>>>> #2347 紅梅(1)
   1  dum#=1 #1700 柏木(2)
   1  dum#=2 #2347 紅梅(1)
   2  dum#=2 #2541 紅梅(2)
   1  dum#=3 #2395 弘徽殿女御(2)
   2  dum#=3 #2438 弘徽殿女御(3)
NAMEBOX::DumpDummyChain NAMEBOX::TailShedding >>>>>>
   1  thread　#1700 柏木(2) #2347 紅梅(1) #2395 弘徽殿女御(2)
   2  #2435 [結婚枠]：[4] #2541 紅梅(2) #2438 弘徽殿女御(3)

結局，紅梅の長い尻尾が1伸びて，#2435のダミー枠に#2541 紅梅(2)が追加されたということになる．この煽りで，MARGBOX #2396が紅梅(2)に直結するようになってしまったのだろう．それでは，紅梅のTYW枠はどこに接続しているのだろう？紅梅のTYW枠#2348：#2541 紅梅(2)＋→#1328 紅梅(0)は紅梅(2)を直接参照している．これに対し，弘徽殿女御のTYW枠は「紅梅のTYW枠#2348」を参照している．明らかにこれは誤っていると考えられる．

TailShedding では処理を開始する前に対象スレッドのTYW枠を一旦外して安全な場所に移動した後，スレッドの伸縮を実施して，その後またスレッドの末尾につなぎ戻す操作を行っている．このとき，弘徽殿のTYW枠を共連れにしているような気がする．⇒TailShedding に入ってきたときの紅梅のTYW枠の位置がおかしい．最初から#2438 弘徽殿女御(3) と弘徽殿のTYW枠#2396の間に入っている．CutBranch(false)では下流系を連れて出るので，弘徽殿のTYW枠も一緒に移動してしまう．

最初の構図では確かにGetUpperNodeでは弘徽殿女御(3)をキャッチできるのだが，その後紅梅(2)が入って，紅梅のTYW枠がそれに連結されるため，弘徽殿女御(3)に到達できなくなってしまう．この不良はNAMEBOX #2347 紅梅(1)のTailShedding で起きている．入口では，

NAMEBOX::DumpLongTail NAMEBOX::TailShedding >>>>> #2347 紅梅(1)
   1  dum#=1 #2347 紅梅(1)
   2  dum#=1 #2434 紅梅(2)
   1  dum#=2 #2395 弘徽殿女御(2)
   2  dum#=2 #2438 弘徽殿女御(3)
NAMEBOX::DumpDummyChain NAMEBOX::TailShedding >>>>>
   1  thread　#2347 紅梅(1) #2395 弘徽殿女御(2)
   2  #2435 [結婚枠]：[5] #2434 紅梅(2) #2438 弘徽殿女御(3)

のようになっているが，出口では

NAMEBOX::DumpLongTail NAMEBOX::TailShedding >>>>> #2347 紅梅(1)
   1  dum#=1 #2347 紅梅(1)
   1  dum#=2 #2395 弘徽殿女御(2)
   2  dum#=2 #2438 弘徽殿女御(3)
NAMEBOX::DumpDummyChain NAMEBOX::TailShedding >>>>
   1  thread　#2347 紅梅(1) #2395 弘徽殿女御(2)
   2  #2435 [結婚枠]：[5] #2438 弘徽殿女御(3)

のように変化している．このとき，紅梅のTYW枠#2348のownerは弘徽殿女御(3)に変わり，Yリストもそのように変化している．これは明らかに誤りと思われる．

▲源氏物語全系譜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のコンストラクタでチェックすることにする．

上図には「長い尻尾」が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）が実行されるので，おそらく致命的な瑕疵にはなっていないのではないかと思われる．問題は解決した．桐壷院は結局，抽出枠で収まっているようだ．

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

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

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

基準ノードの子どもを仮ノード消去するというのはよくないが，左大臣の女御＋冷泉院の結婚が始系列で展開されているとすれば，そもそも仮ノード消去するようなことにはならないはずなのだが… まして，このノードが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つも使っている．どんな用途で使っているのかをまず調べてみよう．

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

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

昨日の続信

kamui さま ＞早速の返信ありがとうございました。 「正式版はいつ出るのか？」という疑問をお持ちの方が多数おられますので，不躾ながら返信を「公開」させて頂きました．m(__)m ＞是非、今年度中のリリースをお願いします。 ご寛恕いただきありがとうございます．時間が速いので…ロコモティブシンドロームに追い抜かれなければよいのですが… ＞リリースしていただければ新しいパソコンも買えます。 最速のパソコンというのを使ってみたいですね！（わたしが使っているのはキャンペーンの特価品ばかりです）最近パッケージ全体をリビルドすることが多いので，痛感しています．これまでは時間・空間コストの節約（ケチること）を最大の課題としてきましたが（Windows 96で走るゼルコバの木クラシックなどというのはその最たるもの），そんなことを言っている場合ではないような気もしています．（アメリカ人の太っ腹な資源浪費に負けてしまいます）ゼルコバの木を動かすには超速マシーンが必要という時代が来るかもしれません… ＞「システムの完全なグラスボックス化にあります」　これいいですね スリムアップというのは一種の断捨離のようなもので，システム全体のクリーンアップ（大掃除）を目指しています．AIが人間の知能を超える「シンギュラリティ」の日が近いということが盛んに言われていますが，その前にニューロネットのブラックボックスと（我々の）グラスボックスが融合する日が来なくてはならないだろうと思っています（笑）． A.B.

▲源氏物語全系譜6.1.ZELの全体図を#81 弘徽殿女御で開いて，TRIBEBOX::hasPhysicalConnectionで停止する．系列優先仮ノードの属性がREALGHOSTのとき，実ノードが可視という理由だ．⇒おかしい．停止しなくなってしまった．TRIBEBOX::hasPhysicalConnectionのラッパ関数HasPhysicalConnectionを作っただけで，特に有意な修正は行っていないつもりなのだが…

障害が起きているのはTRIBEBOX #1569 先祖=#1258 一院(0)[2]で優先仮ノードはNAMEBOX #1255 秋好中宮(0)，優先実ノードは#1766 冷泉院(1)，主系列TRIBEBOX #1567 先祖=#1375 摂政太政大臣(0)[1] 優先=#1329 弘徽殿女御(0) 始系列にBTW右接続関係で接続している．障害はSetMinorTribe→ DoesMajorTribePathExist→ hasPhysicalConnectionで検出されている．

秋吉中宮(0)はREALGHOSTだが，同時に両手に花の右手結婚枠本人仮ノードでもある．こういうことは起こり得ることだ．⇒今度は動作するようになった… ⇒「実ノードが可視」のチェックは「実ノードが仮ノードを参照している場合」に限定するようにした．

▲同上サンプルを#98 夕顔でソートしてhasPhysicalConnectionで停止した．仮ノードがBTWRIGHTSPOUSEのとき，実ノードがDOUBLYBLESSED属性を持たないというエラー．障害は#1569 一院系列，優先仮ノードは#1762 冷泉院(1)，優先実ノードは#1257 冷泉院(0)．冷泉院(1)はBTWRIGHTSPOUSE（両手に花の右手結婚枠配偶者仮ノード），冷泉院(0)は三位中将系列でREALGHOSTだが，BTW属性は持っていない．系列接続種別はBTW右接続関係になっているが，その相手方ではない．しかし，どこかで最終解決を得ている模様だ．

出力では冷泉院(0)と(1)がBTWRIGHTSPOUSE，(2)がDOUBLYBLESSEDで収まっている．にも関わらず，「実仮ノード本人で系列種別が」というエラーメッセージが継続して出ている．これは冷泉院(2)が被参照実ノード属性を持っているためだ．この参照は冷泉院(3)→(2)の参照で，冷泉院(3)はLDRだ．系列種別がDecideTribeTypeと一致している場合は警告を表示しないようにした．

▲同上サンプルを#118 伊予介でソートしてhasPhysicalConnectionで停止した．障害系列は#1573 一院系列で優先仮ノードは#1763 光源氏(2)，実ノードは#1760 空蝉(1)．どちらもDOUBLYBLESSED｜RIGHTHUSBANDの属性を持っている．系列接続種別はBTW左接続関係になっているが，hasPhysicalConnectionはPRIME_BTWRIGHTを求めている．しかし，DecideTribeTypeはPRIME_BTWLEFTを返している．なぜか？この2つのノードは相反する属性を持っている．なぜこういう状態になっているのか調べる必要がある．

少なくとも空蝉はDOUBLYBLESSEDとRIGHTHUSBANDの両側になり得る．伊予介との関係と光源氏との関係があるからだ．光源氏はDOUBLYBLESSEDだけのように見えるがどこかで解消しているのかもしれない．いずれにせよ，優先仮ノードがDOUBLYBLESSEDとRIGHTHUSBANDの両方を持っている場合，接続種別をどちらか一方に決めつけることはできない．どのように判定すればよいのか？DecideTribeTypeがどのように判定しているのかを見てみよう．

DecideTribeTypeでは実際に仮ノードの結婚チェーンを検査して一致するものがあればPRIME_BTWRIGHTを返しているが，そうでなければPRIME_BTWLEFTを同様の方法で検査している．DecideTribeTypeの検査は厳密で信頼できると考えられるので，むしろこの結果と一致しているか否かで判断するのがよいと思われる．

▲同上サンプルの直系血族図を#7 秋好中宮でソートして，TRIBEBOX：checkTribeVerticalPositionで停止した．TribeRelocationの出口近く，FOLDINGCHANNELSフェーズでFoldingChannelsを実行中のエラーだ．(PHASE > AFTERMARGSAMEGENE && !NOMULTICARD && senzo->IsValidNameBox() && !sameGeneCycles && !TRIBES && senzo->getFloor() != ancestor->getnodegene()) という条件で停止している．多重が存在しない状態で，先祖ノードの物理世代番号と絶対世代番号が一致しないというエラーだ．⇒エラーを無視して描画は可能．

この図面には一院系列，大臣（葵）系列，※３系列の3つの系列が含まれている．障害が起きているのはTRIBEBOX #1569 先祖=#1367 大臣（葵）(0)[2] 優先=#1577 六条御息所(2)→#1575 六条御息所(1)だ．「多重はない」としながら，六条御息所で多重になっている．絶対世代番号というのは，重婚同類検定で決定される数値だが，おそらくこのときには大臣（葵）の直下の六条御息所を光源氏の隣のカードと同世代位置に配置するという設計だったのに違いない．それが実現されていないのは，明らかにShiftDirectAbsoluteとAdjustTribeGenerationを（暫定的に）止めているための帰結だ．これを復活させて下図を得た．

産湯を捨てるつもりで赤子を流してしまうところだった（汗）．

▲同上サンプルの全体図を#120 八宮の母女御でソートしてNAMEBOX：getmargboxで停止した．TribeRelocation→ MakePairListClean→ CompleteTribeBoxを実行しているところだ．(getY() && PHASE > GODOWNSTREAM && !disposing && getrelation() != REL_ROOTS && !hidden())という理由で停止している．この行には「結婚枠不在」というコメントが付いている．

getmargboxは人名枠の属する結婚枠を返す呼び出し頻度の高い汎用ルーチンだ．障害ノードは#3424 桐壷院(3)で一院系列に属する．関係は実子だが，TYW婚への参照を持っている．この参照リンクには「LDRチェーン末尾に接続するTYW結婚枠を上位人名枠から参照」というコメントが付いている．障害が起きているシチュエーションは，SolveMargboxCollisionで結婚枠の衝突が検出され，MARGBOX：TYW2ExtractBoxで関係するTYW婚を抽出枠に転換する処理が実施されているところだ．このエラーはかなり難しい．

このノードはMakeExtractBoxで生成されたときから結婚リンクを持っていない．ShiftDirectAbsoluteの中で生成されているので，この部分のロジックをオリジナルの重婚同類が存在するときには実行しないという論理に戻しておくことにする．この部分はあとで見直すことにしたい．

▲同上サンプルの直系親族図を#125 髭黒で開いて，NAMEBOX：MakeExtractBoxで停止した．oya->getmarglinkで空が返っている．これは上記の問題の原因とも言える箇所で，この値が空になっていると，上記のようなエラーが生じる可能性がある．#144 真木柱でも起きる．#125 髭黒の場合を見てみよう．⇒重婚同類は存在しないため，ShiftDirectAbsoluteが実行され，その中でエラーが発生している．

NAMEBOX::MakeExtractBoxでは，「対象ノードを親枠から一段シフトする」処理を実行している．MakeExtractBoxはCardShiftDirectから呼び出されてカードの一段シフトを実行している．CardShiftDirectは「結婚枠からこのノードとその下流系を抽出して結婚枠に格納し，このノードの位置にはEXTRACTDUMMYダミーノードを置く．抽出された部分結婚枠はダミーノードの下に配置する．抽出部分結婚枠はダミーノードのNAMEsDUMMYに接続する．」を実行している．今の場合はシフト量は2段で，ループの2回目でエラーが発生している．MARGBOX：getmarglinkには以下のような説明が付いている．

「LDR結婚枠の親ノードは結婚枠なのでgetmarglinkでは空が返る．抽出枠/TYW枠の親ノードは人名リンクなので空が返る＠2018-01-23 ZTYW枠の結婚リンクを求める手続きを追加した＠20180110」

kamui氏からメールが入っていたので返信した．

kamui さま いつもお世話になっております． ＞コロナの中、憂鬱な日が続いています。久しぶりにテント村に行きましたら「源氏物語全系譜6.1.ZELの法定親族図 #1 －－－－事象が発生している」などの記述が有りましたので、Ｗｉｎｄｏｗｓの最新バージョンへのインストールが可能になったのではないかと思いメールを出しました。 思い出して頂きありがとうございます．当方の開発機のOSバージョンは1909ですが，インストールできています．この後，2004，20H2というのが出ているようですが，まだ試していません． ＞正式版のダウンロード可能になるのはいつ頃ですか？ 本年度（2021年）中にはリリースしたいと考えています．仕掛りのバージョンは描画などにかなりの不具合があり，仮リリースもできない状態になっています．Alphabet（Google）傘下のDeepMindはアミノ酸配列からタンパク質の３D構造を予測するAlphaFoldと呼ばれるAIで目覚ましい成果を挙げていますね！「タンパク質３D構造予測問題」と「家系図作図問題」のどちらが難しいか？は言うまでもありませんが，我々のシステムもいよいよガラパゴス化（独自進化？）してきたことを率直に認めるしかありません． G島でこのまま朽ち果てるのか，何か新しい成果を携えてカムバックできるのか？これが事実上最後の機会になると考えられるので，描画上の不具合などは一時棚上げして，システムのスリムアップを進めているところです．ニューラルネットの最大の弱点はそれが内部構造の見えないブラックボックスであるという点にありますが，我々の目標はそれと真逆の，システムの完全なグラスボックス化にあります．（ガラス箱とガラパゴスって音が似ているような？笑） 2021/01/17 硝子箱島にて 馬場 英治

▲源氏物語全系譜6.1.ZELの全体図を#1 光源氏で開いて「重婚同類グラフ検定異世代多重カウントオーバー」でループが停止しない．⇒系列枠：snum=1619 primetype=3:婚姻関係 senzo=#788 右大臣 （明石）で「実ノード不一致」が発生している．ループのボトムでブレークするようになっているが，EstablishMajorTribeChainでそれ以前にgoto TRYAGAINを実行している．⇒対処した．

この図面では系列が64個あり，そのうち一院系列の系統に含まれるものが，31個ある．この系統グラフは4つの連結成分に分離している．①始系列（一院系列）を含む28系列のグループと，②衛門督（箒木）系列，③伊予介系列，④右大臣（明石）系列だ．前回の法定親族図のときは，衛門督系列と伊予介系列は一つの成分になっていたので比較的簡単に解けたが，今回はかなり難しそうだ．

④右大臣（明石）系列の優先ノードは髭黒(2)で実ノード候補は玉鬘(0)と髭黒(3)だ．当初は髭黒(2)→ 玉鬘(0)という接合になっているが，EstablishMajorTribeChainで付け替えを試みようとして失敗している．髭黒の仮ノードは4つある．#1373(0)は一院系列で配偶者，#1804(1)は先帝系列の配偶者，#1841(2)は右大臣（明石）系列の実子，#3662(3)は右大臣系列のLDR．当初は髭黒(2)はTYW婚で外部に出ていて，髭黒(3)→(2)というノード対で連結されている．

この構成では髭黒(2)→ 玉鬘(0)という接合は難しい．EstablishMajorTribeChainの中で代替案を探す時点でこのノード対をRetrieveGhostで削除したところ髭黒(3)のノード自体が削除されてしまった．これはTWY婚の本人ノードが元の位置に戻るというノーマルな動作だが，そのまま続行できないので一旦EstablishMajorTribeChainから離脱してリトライするようにして解決した．かなり迂遠な解になってしまうが，今のところこれしかない．これで一応④右大臣（明石）系列の問題は解決したと考えてよいと思う．

しかし，伊予介系列と衛門督系列の孤立は続いている．前回サンプルでは空蝉が衛門督系列と伊予介系列の接点となり，軒端の荻が伊予介系列と一院系列を繋いでいたのだが，今回の図面では伊予介系列には空蝉の席がなく，軒端の荻は蔵人の少将という配偶者を持つという構図になっている．いや，少なくとも伊予介と衛門督は伊予介を媒介として接合できるはずだ．⇒確かにそれは可能と思われるが，現行アルゴリズムではそのような動作にはならない．

現行論理ではトップダウンで始系列を基準とし，始系列の連結成分中のノードとの接合しか探していないからだ．もし，伊予介系列が始系列と連結できれば初めて衛門督→伊予介が対象に入ってくる．軒端の荻は結婚を持っているが，BTWを使えば接合できるはずだ．なぜそれが出てこないのだろう？⇒すでに優先=#1827 軒端の荻(1)→#1353 軒端の荻(0)で設定されているからだ．EstablishMajorTribeChainでは既存の設定では物理コネクションを確立できないと見て，最初から除外している．

放置状態であればループの中でBTWを成立させてもよいと思われるのだが，なぜそうならないのか？⇒NAMEBOX::DoublyBlessedOneの冒頭，IfBTWPossibleで弾かれている．これは，軒端の荻が基準ノードである光源氏の配偶者であるためだ．「基準ノードの配偶者の配偶者を左手本人とするBTWを不可とする」というルールが＠20190130に制定されている．これには例外があって，「基準ノードの配偶者が単親婚を持っている場合には左手本人とする」となっている．

「左手本人仮ノードが単親婚を持つ場合にはつねにBTWを構成する」という非常に強い条件があるが，これと同様に「左手本人仮ノードが系列優先ノードの場合はつねにBTWを構成する」という条件を付け加えてもよいのではないだろうか？⇒これで問題は解決した．軒端の荻と空蝉はいずれもBTW左手本人として光源氏と接合している．伊予介のカードがダブってしまうのはどうにも避けられないが，この図面には重婚同類循環が3つもあるので仕方ないだろう．

▲同上サンプルの#3 桐壷の更衣でNAMEBOX::TailSheddingのエラーが出た．TailSheddingの引数のdiffが負値になっている．diffには実ノードと仮ノードの世代差が入っている．diffが負になると調整ができないのでエラーになる．⇒ShiftDirectAbsoluteとAdjustTribeGenerationを止めるとこのエラーは消える．この2つの関数は多重が存在する場合には実行しないというのが本来の仕様でそれを暫定的に一度だけ実行するようにしているのだが，その妥当性を含めてこの辺りを精査する必要がある．

この処理を作動するように変更したのは，光源氏の法定親族図で三位中将系列の主系列参照チェーンが切れるというところからだ．この処理を停止すると今度はTRIBEBOX::adjustGenerationRangeで「先祖ノードが系列世代範囲を逸脱」というエラーが出るようになる．この関数は16回呼び出されているが，実行しなくても描画には影響しない．

光源氏の法定親族図では一度も呼び出されていない．三位中将のチェーン切れという問題も生じていない．全体図では一度呼び出されるだけだ．呼び出し16回というのは桐壷の更衣の全体図に限られている．系列ポテンシャルの設定はSetMinorTribeで実行しているので，ほとんど不要になっているのではないかと思われる．ただし，この関数は10箇所から呼び出されているので，よく使われている関数だ．

主系列参照チェーンが途切れている，というより，系列間物理コネクションが切れている系列の発生に対処するために，TOPOLOGY：MakeLinearEdgeListという一度は廃棄された関数を掘り起こして改造を試みているところだ．主系列への参照設定をTRIBEBOX::setMajor関数に集中し，この関数の中で物理コネクションの検査を行い，グラフには物理的に接続している場合にのみ枝を追加するようにした．

この結果，AFTERMARGSAMEGENEフェーズでは，TRIBEBOX #1589 先祖=#1361 衛門督（箒木）(0)[13] 優先=#1702 空蝉(1)→#1351 空蝉(0) →主系列#1567:一院とTRIBEBOX #1627 先祖=#1355 三位中将(0)[18] 優先=#1711 夕顔(2)→#1674 夕顔(1) →主系列#1567:一院の2つの系列の物理コネクションが切れていることが判明した．

このうち，後者は事後に接続を回復しているが，前者は最後まで切断状態が継続している．AFTERMARGSAMEGENEのループは多重カードが存在する間はループするようになっているが，STOPCARDSHIFTが立っているために一度で抜けてしまっている．まず，これを見ておこう．重婚同類循環が存在する場合にはSTOPCARDSHIFTを立てるようになっている．STOPCARDSHIFTが立っていると，ループを一度で抜けてしまうだけでなく，以下の2行も実行されないようになっている．

ShiftDirectAbsolute(topology->tajugraph1->complist);
AdjustTribeGeneration();

この2行を実行すると三位中将系列の切断は解消するので，暫定的にこの制限を緩和しておこう．これで次の段階に進む準備が整った．⇒TribeTreeGraphのノード数が4，枝数も4しかない．⇒現行では「物理コネクション」がなくても主系列を設定できるようなルーズな仕様になっているためだ．しかし，これは必要な措置なのでこれに従うしかない．グラフの枝を主系列設定時に生成するのではなく，検査時にまとめて処理することにしよう．作り直して検査用の新しい関数を作った．

TRIBEBOX::EstablishMajorTribeChainという関数は＠20190204に廃止されているが，この名前をTRIBELISTの関数として復活させることにする．いや，グラフオブジェクトはTOPOLOGYの所有なのでやはりTOPOLOGYのメンバーとしておいた方が無難だ．⇒一応動作するようになったが，いろいろと問題がある．

上記の出力は望んでいたものだが，やや変則的な動作になっている．EstablishMajorTribeChainでは連結成分に分解された衛門督系列を連結するための解として伊予介＋空蝉の結婚を見つけ出しているのだが，もう一度ループを通すと，今度は三位中将系列で非連結が発生するようになってしまう．上の図はループに戻らずにそのまま描画まで進んだ場合の図面だ．⇒余分な処理を外すことによって動作するようになった．

1. AFTERMARGSAMEGENEのループで，ShiftDirectAbsoluteとAdjustTribeGenerationは一回だけ実行するようにした
2. TRIBEBOX::AlternateTribeRealNodeを廃止した
3. DONTSORTTRIBEを廃止した
4. sameGeneCyclesでもSTOPCARDSHIFTをオンにしないようにした

源氏物語全系譜6.1.ZELの法定親族図 #1 光源氏で以下の図のように衛門督系列と伊予介系列が孤立してしまうという事象が発生している．

伊予介系列は当初は軒端の荻を優先ノードとして始系列の一院系列に繋がっているが，上図では先祖ノードの伊予介を優先ノードとして衛門督系列の従系列に変わっている．衛門督の優先ノードは空蝉で一院系列の従系列になっているが，空蝉(1)が結婚を持っているため消去できないので物理的なコネクションを確立することができない状態だ．

これを解決する最善策は，衛門督系列を逆に伊予介系列の従系列とし，伊予介系列では軒端の荻を優先ノードに立てて一院系列につなぐという構図だが，現行論理ではそこまでのことはできない．軒端の荻は上図では一院系列の軒端の荻(0)とは世代差がある．これは，空蝉と軒端の荻がどちらも光源氏の配偶者であり，同世代に並ぶことを求められているためだ．しかし，衛門督を伊予介の従系列にすれば軒端の荻の世代を調整することも可能となる．

ともかく，現状で「主従系列間の物理コネクションが確立されていない状態」が検出できるようにする必要がある．「系列間の物理コネクション」を以下のように定義してみよう．

1. 系列間物理コネクションには，①（LDRを含む）消去された仮ノードによる連結と，②BTWによる連結の2種がある（それしかない）
2. 系列優先仮ノードと実ノードは仮ノードがLDRの場合を除き，同世代でなくてはならない
3. 通常の場合，仮ノードは不可視，実ノードは可視である　BTWによる連結では仮ノードが可視となる場合がある　逆婚姻関係では実ノードが不可視，仮ノードが可視となる
4. 通常仮ノードと実ノードは同一カードを参照しているが，場合によっては別の（配偶者）カードを参照することもある

TRIBEBOX::IsConnectedとその下位関数DoesMajorTribePathExistは本来上記の検査を実施することを目的としているのだが，かなり甘いものになっている．DoesMajorTribePathExistでは検査の重複を避けるために始系列参照パスフラグ（majortribepath）というのを置いているが，あまり当てにならないので廃止した方がよいと思う．

TRIBEBOX::hasPhysicalConnectionという検査関数を作ってDoesMajorTribePathExistから呼び出すようにしてみた．この結果，衛門督系列では系列間の物理コネクションが完全に失われているということがわかった．さて，それではどうすればよいのか？一つの考え方としては，衛門督系列の空蝉(1)が結婚を持っているのに系列優先ノードになること自体を誤りとするという立場があり得る．この場合は衛門督は別の優先ノードを探さなくてはならないので，空蝉(1)の結婚から伊予介の従系列になっている可能性がある．

これはこれで一つの解決とは思われるが，結婚を持っているノードは系列優先ノードになれないという縛りは少しきつ過ぎるような気がする．系列優先ノードがそれしかない場合，相手のある結婚なら相手方に渡すという方策もあり得るが，単身婚の子どもがいる場合にはそれもできない．単身婚の子どもがいる場合でも，複数の親がいればそちらに渡すことも可能であるかもしれないが…

逆に言えば，単身婚の子どもがいてかつ親が一組しかない場合には優先ノードにはなれないということだろうか？いや，そんなはずはないはずだ．現行では逆婚姻関係というのも認められているのだから，従系列に本人ノードを残すという結合形態もあり得るのではないか？

グラフ理論的にこの問題を解くことを考えてみよう．まず，「すべての系列はなんらかの方法で（少なくとも1つの）他系列との物理的なコネクションを持つ」としよう．また，「従系列→主系列という方向は任意に変更可能」であるとしてみよう．この2つの仮定が成立するとすれば，以下の手順でつねに連結な有向木を得ることができる．

1. すべての系列につき，任意の物理コネクションを確立する
2. 系列を頂点とし系列間の物理コネクションを枝とするグラフGを生成する
3. グラフGが連結ならば，→5に進む
4. グラフGを連結成分に分解し，連結成分間の物理コネクションを確立する→グラフGが連結になるまでこれを繰り返す
5. グラフGの枝に始系列からの向き付けを与え，有向木に転換する

ステップ2で生成されるグラフGが連結であるか否かが問題だ．もし，このグラフが連結であれば，そのグラフ上の任意の頂点を根点とする全域木が存在することは証明されているから，それを有向木に転換するのは難しくない．仮に，グラフGが連結でなかったとしても，それを連結成分に分解し，連結成分間の任意の物理コネクションを確立することは可能と考えられるから，この方法は確実に成立すると言ってよいだろう．

具体的な事例で考えれば，今の場合はステップ4で衛門督＋伊予介系列とそれ以外の系列という2つの連結成分に分解されるはずだ．この中で2つの成分を連結できる要素は軒端の荻しかないということになるはずだから，衛門督系列→伊予介系列に向き付けを変更した上で，軒端の荻の物理コネクションを確立するための操作を実施するということになるのではないだろうか？かなり厄介そうではあるが，これができればグラフが非連結になるという事象は根絶されることになるはずだ．抜本的な解決策としてはこれしかないような気がする．

「結婚を持っているノードは系列優先ノードになれないという制約」の妥当性を見るために，空蝉＋伊予介の結婚を解消し，その代わりに空蝉に単身婚の子どもを与えて描画してみた．

上図で衛門督系列の優先ノードはこれまで通り空蝉だが，問題なく接続している．従って，結婚を持っているノードは系列優先ノードにはなれないというのは正しくない．伊予介＋空蝉の結婚の描画が難しいのは，世代的な矛盾（重婚同類循環）があるためと考えられる．

TRIBELIST::SortTribeListにはかつては「系列木の枝グラフをトラバースして線形枝リストを生成し系列枠の全順序を決定する」という処理が入っていたのだが，＠20180821 辺りで廃止されている．⇒コードは残っている．TOPOLOGY::MakeLinearEdgeListだ．TribeTreeGraph，copygraph，tempgraphの3つの枝グラフを使っている．TribeTreeGraphはTRIBEBOX::setMajortribeで主系列を設定するタイミングで従系列→主系列の枝を追加している．

既存論理の瑕疵を発見した．BTWを構成するときには，事前にNAMEBOX::IfBTWPossibleで予備検定を行い，実施可能と判断してから実行に移るようになっているが，この関数の中ではBTWの当事者ノードが同世代であることをチェックしているにも関わらず，伊予介と空蝉のケースではそれから漏れていた．系列間のBTWが生じるとそれを使って系列接続関係が再構成され，系列ポテンシャルを調整して実仮ノードの世代を一致させるための系列シフトが実行される．伊予介系列は本来軒端の荻の仮ノード消去で一院系列に接合していたものが破棄されて衛門督系列に従属するように変化しているのはこのためだ．

BTW当事者の世代一致が無視されているのは，「左手本人仮ノードが単親婚を持つ場合にはつねにBTWを構成する」という理由による．この場合には無条件でBTW成立と判断しているが，明らかにやり過ぎと考えるしかない．「当事者の世代一致」という条件を「左手本人仮ノードが単親婚を持つ場合」よりも前方に配置してこのような誤動作を防止するようにした．これにより，孤立しているのは衛門督系列だけになった．

現状ではこの系列は有効な系列優先ノードを持たない状態なので，グラフを使った系列連結検定の対象となり，結合相手として系列順位では下位に当たる伊予介系列を見出すことができるだろう．そうすれば，この図面には非連結の部分がなくなり，図面として完成する．多分これがもっとも合理的な解法ではないかと思う．

昨日もネカフェに出かけて，Visual Studio Installer Projectのための拡張機能をダウンロードしてきたのだが，まだ足りないものがある．MFCのパッケージが不足している．ネットには一応繋がっているので，インハウスで試してみよう．1.009MBあるのでおそらくダメなのではないかと思われるが… 30KB/秒くらいのスピードしか出ない．ときどき0KBまで落ちる… それでも2%まで進んだ．まぁ，望みは薄いがやらせておくことにしよう．さて，昨日の障害に戻ることにしよう．

「系列タイプ決定不能」という問題が起きているが，それ以前に，伊予介系列の優先ノードである軒端の荻がなんの属性も持っていないというのが問題だ．これは「IsPrimeboxOrNotを有効化」オプションのON/OFFとは関わりない事象だ．まず，これを追求する必要がある．軒端の荻の仮ノードは一度も操作された形跡がない．これはかなりまずいのではないか？⇒TRIBEBOX::GetMajorTribeChainという関数があるので，この関数でチェックできなくてはならないと思うのだが…

＠20190204に廃止されたTRIBEBOX::EstablishMajorTribeChainという関数があるので復活させてみたが，効果はなかった．おそらく最大の問題は軒端の荻(0)と(1)の世代が異なるという点にあるのではないかと思う．TribeRelocationの20.AFTERMARGSAMEGENE　重婚同類グラフの後処理で以下を実施している．

1. CheckTribeVerticalPosition　系列枠内ノードの垂直位置調整
2. AlternateTribeRealNode　系列優先仮ノードと実ノードで世代差を調整
3. TribeGhostName　系列枠の範囲内で消去可能な仮ノードを消去する
4. BetweenTwoWomen　系列枠の範囲内で両手に花を構成する

ここで調整されるべきだろう．AlternateTribeRealNodeで伊予介系列の検査を実施した時点では実仮ノードの世代は一致している．衛門督 （箒木）の主系列を伊予介系列に設定する時点で系列シフトが発生しているのではないかと推定される．⇒衛門督の優先ノードは空蝉で主系列は一院．おそらく伊予介の多重を解消するためにカードシフトを実行したのではないかと推定される．伊予介のBTWが設定され，系列シフトが起きている．伊予介のBTWによって衛門督の優先ノードであった空蝉(1)が可視となり，逆に空蝉(1)→(0)のコネクションが切れてしまっている．

伊予介のBTWの結果，伊予介系列は優先#1366 伊予介(0)→#1702 空蝉(1) →主系列#1589:衛門督（箒木）という変則的な接続に変化している．これらの操作のどこに問題があると言えるのだろう？空蝉は一貫して衛門督系列の優先ノードだが，軒端の荻と同様，一度も仮ノード消去されたことがない．問題点を挙げてみよう．

1. 空蝉も軒端の荻も仮ノード消去を受けていない　空蝉(1)が消去できないのは結婚を持っているため
2. AFTERMARGSAMEGENEフェーズでは，TribeGhostNameで仮ノード消去を実施しているが，ここでは対象を系列枠内に限定している
3. 従って，仮ノード消去による系列接続ではMakeUpTreeでその処理が実施されなくてはならない
4. 現行ではBTWの優先度はとても高くなっていて，①関係するノード対の破棄，②姉妹婚の破棄，③シンメトリ婚の破棄，④ゴールデンカップルの破棄，⑤ZTYW婚の破棄が求められる
5. 系列間BTWで系列シフトが発生している
6. 系列間の物理的なコネクションが存在することを検証する仕組みが備わっていない　つまり，始系列までの参照パスが検証されていない
7. 現行でも系列接続関係をダイナミックに更新する仕組みは備わってはいるが，ある範囲をカバーする弥縫策に留まっているように思われる

空蝉(1)が消去できないのは結婚を持っているためだ．軒端の荻はEraseGhostをパスしているが，実際には消去されていない．EraseGhost→ MakeGhostNodeでは可視/不可視の調整をしているだけだ．EraseGhostは仮ノード消去の予備検査でEraseGhostNodeの中から呼び出されている．

▲源氏物語全系譜6.1.ZELの法定親族図を基準ノード=#74 薫で開いて，NAMEBOX::DoublyBlessedOne→ MARGBOX::CheckLongTailからNAMEBOX::makeLongTailを実行して，結婚枠の右枝が結婚枠を親参照していないというエラーになる．この不良はNAMEBOX：BundleStringの中で発生している．この関数は「LDR束線分移動後束芯を一致させる」ためのもので，問題のノード#21950 浮舟(2)はLDRだ．#21929 中姫君(1)と#21950 浮舟(2)が束ねられている．LDR束に束ねられた線分はすべて先頭LDRを親参照するようになっている．これはLDR束全体が一体化したものとして操作される必要があるためだ．

つまり，このノードは結婚枠に含まれる描画要素ではあるが，実態はすでに外部にあると考えなくてはならない．従って，これはエラーではなくノーマルな状態として扱われるべきだろう．これを判定する基準は，「そのノードがLDR束線分に属し，LDR束先頭線分が別の結婚枠を参照している場合」ということになる． しかし，MARGBOX：CheckMarchainで「右枝ノードが結婚枠を親参照していない」という不良が検出されるときには，このノードはすでにLDRではなく，通常の「消去された仮ノード」に戻ってしまっている．

LDRでなくなったとき，ないし，LDR束から離脱した時点で親参照の付け替えがなされなくてはならないと考えられる．LDR束線分属性はBUNDLEDSTRING，LDR属性はELDERWIFEだが，BUNDLEDSTRINGの解除の方が先行するものと思われるので，その時点を特定してみよう．NAMEBOX::PairBoxGeneChangeで実仮世代差ゼロとなり，NAMEBOX::TailSheddingを受ける時点でリセットされている．BUNDLEDSTRINGをリセットしている場所は7箇所ある．個別対応するのも難しいので，resetghostbitsの中で一括処理するようにしてみよう．⇒対処した．

源氏の完全木テストが完了した．

フルスペック版の36分39秒に比べるとかなり遅い．完全参照リスト管理を外せばそこそこの数字が出る．

▲「IsPrimeboxOrNotを有効化」オプションをONにしたバージョンで源氏物語全系譜6.1.ZELの法定親族図を開いて，TRIBEBOX：DecideTribeで「系列タイプ決定不能」が発生する．障害系列はTRIBEBOX #1566 先祖=#1339 伊予介(0)[16] 優先=#1799 軒端の荻(1)→#1449 蔵人の少将（夕顔）(0)で主系列は#1634:蔵人の少将（夕顔）だ．しかし，これはあまり上等な選択とは言えない．蔵人の少将には親も子もなく，軒端の荻との結婚があるだけだ．この不良は「基準ノードの配偶者の外部婚を排斥」オプションをOFFにすれば解消する．しかし，情況は思っていたよりずっと深刻だ．

衛門督 （箒木）系列と伊予介系列は位置的にはほぼ接触しているが，始系列につながる連結線をまったく持っていない．これはかなりまずい事態だ．それでも非連結=0となっているのはなぜだろう？どうも根底から見直しが必要となるような形勢になってきた．連結/非連結は「始系列に至る実仮優先ノード経路が存在する場合を連結，そうでない場合を非連結とする」と定義されている．

リサイクルシステム，UNDOシステム，グラフ検証系を止めたZTベーシックの動作をチェックしているところだが，アプリ終了でnodl_floatのエラーが出ている．今回は「完全参照リスト管理」を搭載した状態でチェックしているところが前回と異なる点だ．参照リストは親オブジェクトが削除されても存続するという仕様になっていることがこの不良の原因と考えられる．~NODULEを修正して，ゴミ箱が未サポートのときには，増設スロットを含むすべてのスロットの下位オブジェクトを削除するようにしてこのエラーは解消したが，こんどは，CallSetCouplingPtrでCOUPLINGを削除した後，rootnodeをクリアするところで無限ループするようになってしまった．

rootnodeにはnullpointオブジェクトが入っている．このオブジェクトは地べたに置かれた根付きのオブジェクトだ．newで生成されたものではないという属性NOTAUTODELETEを持っているため削除できない．このオブジェクトのアドレスを格納しているrootnodeは昨日nodl_floatを修正して，すでに親ノードが死亡しているときには書き込みを行わないとしたため，空にできない状態になっている．ゴミ箱を使っていないときにはオブジェクトの削除＝メモリからのパージを意味するから，死亡しているオブジェクトへの書き込みにはリスクがあるが，今の場合書き込むのはオブジェクトではなくリンクを格納しているアンカーなのでその場合だけは例外として処理されなくてはならない．⇒対処した．

これでrootnodeは始末できたが，こんどは_getblock_で「フリーメモリゼロ」というダンプが出るようになった．Nリングに残留オブジェクトが大量発生している．すべてfreeblockオブジェクトだ．なぜだろう？freeblockはCOUPLING：EraseFamilyTreeでfreeblock：ReleaseFreeBlockを使って完全に解放しているはずなのだが…

_getblock_では(!totalblock || !topblock)のとき，「フリーメモリゼロ」というエラーを返している．どうもまた何かメモリ管理に関する齟齬が発生しているようだ．⇒カウントの問題ではない．nodl_floatでIsAliveでないときは処理しないとしているためだ．⇒いや，違う．親ノードがIsAliveでないときは書き込みしない，ただし，対象ノードがNOTAUTODELETEであるときは，無条件で書き込むように修正した．これで「フリーメモリゼロ」も解消し，rootnodeも始末できた．

▲源氏物語全系譜6.1.ZELの傍系血族図 基準ノード=#51 若宮（匂宮の）でPAIRBOX::RepairCommonEndPointのエラーが出た．端点共有で始点不一致というエラーがPAIRBOX:#42220：#21900 明石の上(1)→#12444(0)と#42320：#22054 源氏宮(1)→#12988(0)で起きている．⇒これは起こり得るエラーだろう．この端点共有には3つのノード対が関係している．①明石の上，②源氏宮，③承香殿女御だが，元々は①承香殿女御，②源氏宮のようになっていた．明石の上と承香殿の始点の誤差は許容範囲内，承香殿と源氏宮の誤差も許容範囲内だが，明石の上と源氏宮では許容範囲を超えてしまう．

端点共有リストをノード対区間の大きさでソートしてやればおそらくこのようなエラーは（ある程度まで）回避できるのではないかと思われるが，必ずしも確実なものではない．許容範囲を倍にしてやればエラー自体は（ある程度）回避できるかもしれない… こちらの方が簡単だが，むしろ傷が深くなる可能性もある．基準となる始点座標を「固定」しない限りこのような変動は避けられない．

とりあえず，ソートしてみることにする．MoveSamePointではSwapBundledPairを実行しているが，この関数を「最大区間の付け替えを実施」するだけでなく，ソートまで実行するようにすればよい．この関数はPAIRBOX::MoveSamePoint，PAIRLIST::RepairPairBox，NAMEBOX::makePairBoxで使われている．⇒対処した．⇒最終的には上の3つのノード対の端点共有は崩れて分解してしまう．

▲同上サンプルの法定親族図を#74 薫でソートしてMARGBOX：CheckMarchainで停止した．結婚チェーン不整合が起きている．NAMEBOX::BuildMarChain→ CheckMarchainで不良が検出されている．NAMEBOX:#11679 八宮(0)の結婚チェーンで，要素は2つ．MARGBOX:#10223：#11679 八宮(0)＋→#11951 大姫君(0)とMARGBOX:#8623：#11679 八宮(0)＋#13583 浮舟の母(0)→ だ．前者は可視，後者は不可視でBTWの右手結婚枠．

「右枝ノードが結婚枠を親参照していない」というエラーが起きている．障害ノードはMARGBOX:#8623でYRにはNAMEBOX:#21950 浮舟(2)が入っている．浮舟(2)はこの結婚枠の最初の子どもなので当然結婚枠を親参照しているべきところだが… どこかで外れてしまっているのだろうか？⇒どうも最初から失敗しているようだ．