tamo2氏からホワイトオーク樽で三年の古酒「神の河」が届く

午前9時起床,晴れ.朝食は7分玄米食,大根の煮付け,おろし大根,大根と油揚げの味噌汁.今日はうどんの残が1個になったので久しぶりにご飯を炊いた.食事中にtamo2さんからのゆうパックが届いた.写真を撮ったのでグーグルドライブをインストールして開こうとしたのだが,うまくゆかない.Backup and Sync from Google というアプリはインストールされている.ウェブ上ではGoogleドライブが使えるのでこちらからダウンロードすることにしよう.

IMG_20190210_174014

喉が乾いていたのでお礼も言わないうちに蜜柑を一つ食べてしまった.外皮は固くて剝きづらかったが中身は驚くほど甘い.キャラメルの箱くらいの「ボンタン飴」が入っている.懐かしい.渋谷時代の仲間の一人ニーナが鹿児島出身だったので,この飴は昔もらって食べたことがある.「げたんは」という真っ黒で三角形の黒糖菓子.お茶を淹れて一つ摘んだが,二つ三つと全部食べてしまいそうになったので箱を閉じた.麦焼酎の古酒がある.「神の河」と書いて「カンノコ」と読むらしい.何気に神々しい雰囲気だ.

これは開けるしかないかな?今日は早寝して明日から真面目に仕事することにしよう.

基準ノードの配偶者が枠外に出てしまう問題

午前5時起床,晴れ.朝食は茹でうどんに納豆と大根おろし.BUG19-01-27 06-56-47.NONで基準ノードの配偶者が枠外に出てしまう問題を追いかけてみよう.「左手枠配偶者を左手本人とするBTW拡張@20190130」は「配偶者多重」を解消する奥の手だが裏目に出ている.基準ノードの配偶者の仮ノードは直近の一枚を除いてすべて消去されなくてはならない.例外はこのノードが単親婚を持っている場合だけだ.この場合,基準ノード直近の配偶者は上記の意味での「左手枠配偶者を左手本人とするBTW拡張」としなくてはならない.

AA(2)が「配偶者左手本人」になっているのは明らかに誤りだが,どうすればこれを防止できるか?配偶者の仮ノードは複数あり,そのうちのどのカードを「配偶者左手本人」に指名するか?が問題だ.同名ノードの中に基準ノードの直近配偶者がいる場合にはこれを最優先すべきであるのは当然だ.判定を容易に行うためには,「基準ノードの直近配偶者」という属性を保持させるのが分かり易いが,これは後付けで実施することにして,とりあえず検査関数を導入しておこう.

いや,それ以前の問題だ.IfBTWPossibleの入口でGetSegmentTopで弾かれている.これを暫定的に止めて走らせてみるとAA(0)はきっちり基準ノード直近に配置されている.CR(0)+AA(0)という結婚枠は2つある.この結婚枠はすでにZTYWになっている.配偶者AAのBTWが掛かってくるタイミングが遅過ぎる.ステージ【5.2】重婚同類グラフ検定の事後処理を行なうで処理されていなくてはならないのだが… TRIBEBOX::BetweenTwoWomenで配偶者を排除しているためだ.しかし,ここで処理すると図面が完全に壊れてしまう.

このフェーズでは従来通り配偶者は不可としておくしかないように思われる.ZTYWはメインループのステージ【7.2】MPLCで実行している.BTWに掛かるのはステージ【7.9】ですでに手遅れだ.しかし,これはGetSegmentTopの判定が悪いのではないだろうか?いや,それ以前の問題だ.NAMEBOX::FindDoublyBlessedOneで取り出している結婚枠に問題がある.ZTYWではなく「ZTYW本人を参照する仮ノードが存在する元の親枠」を取り上げている.この結婚枠はgetmargboxで取り出されているが,AA(2)にリンクされている結婚リンクの参照する結婚枠はこの親枠になっている.

getmargboxを補正する動作をFindDoublyBlessedOneに組み込んでIfBTWPossible→ GetSegmentTopはパスできるようになったが,HaveSingleFatherBoxが真を返している.HaveSingleFatherBoxでは子どものいる子ども枠を持っている場合には真を返している.

AFTERMARGSAMEGENEフェーズではBTWを仮ノード消去に先行

午前0時起床,曇り.夜中映画を流しっ放しで寝てしまったので,スマホのバッテリーが空になってしまった.充電を続けているが,50%を超えてもまだ起動できない.ルーターも3日間の上限10GBを超えているのでやけくそ遅くなっている.ルーチンではスマホで昨日のログをチェックしながらタブレットで校正という手順になっているのだが,スマホが使える状態まで回復していない.またメインPCがいつの間にかネットアクセス可能状態になっていた.

タブレットでログをチェックすることはできるが,「スマホのブラウザで最適化」という現行方針とマッチしない.やや大げさな言い方だが,スマホが使えないとほとんど失明したのと同じになってしまう.電気料金の請求書が入っていた.8千円を超えている.400Wのストーブを常時点灯しているだけで5千円!別にストーブを焚いているのだから,これでは掛かり過ぎだ.湯たんぽに戻るという訳にもゆかないが,できるだけ200Wでしのぐようにしなくてはならない.石油ストーブをもう少し長時間使って室温を一定に保った方が,まだ安くつくかも….

スマホは充電100%にならないと起動できないのだろうか?65%を超えているのにまだ起動できない状態だ.100%になっても切り替わらない.電源スイッチを長押しして入った!以下昨日の続き:

冷泉院への切り替えはTribeRelocationのステージ【5.2】重婚同類グラフ検定の事後処理を行なう,AFTERMARGSAMEGENEフェーズで発生する.ここでは以下のの4つの処理をシリアルに実行している.

  1. CheckTribeVerticalPosition
  2. AlternateTribeRealNode
  3. TribeGhostName
  4. BetweenTwoWomen

③を実行する段階ではまだBTWが構成されていないため,桐壷院の仮ノードは可視状態になっている.TribeGhostNameではそのノードがBTW転換可能か否かという判定は行っていないため,仮ノード消去できないと判断して優先ノードの切り替えが実施される.

基本的にはこの判断は間違ってはいないが,必ずしも適当であるとも言えない.特に冷泉院のカードはこのあと異世代多重状態に移行すことになるのでできれば避けるのが賢明な選択であるように思われる.③に先行して④を実行するように書き直してみよう.確かにこのような手順であればエラーなしに描画まで進むことができる.この部分の論理はこれでよいと思われるが,従来論理で発生するエラーを防止する方法があるかどうか?別途調べてみることにする.

この図面では多重は12件発生している.うち11件が不可避多重だ.この状況は従来論理でも改修後論理でも変わらない.従来論理でエラーが起きるのは系列優先ノードで異世代多重が起きているためと考えられる.いや,少し違うかもしれない.エラーが起きているのは明石中宮だ.明石中宮(1)→(2)のノード対で世代不一致が起きている.いや,違う.このノード対はすでに廃棄されている.どうもStillAliveという関数が誤動作しているように思われる.

NODULE::IsAliveという関数が間違っている.この関数ではonfinishしか見ていない.すでにDELETEDが立っているのだからIsAliveではないと判定されなくてはならないはずだ.この関数ではおそらくDELETEDが立っているのであればLIFEは空になっていると仮定しているのだろう.そのノードがShadowを持っている場合にはDELETEDがオンでもLIFEは空にならない場合がある.従って,IsAliveは修正されなくてはならない.

動作が少し変わったようだ.今度はPairBoxGeneChangeの中で死んでいる.⇒対処した.これでエラーは一切発生しなくなった.しかし,動作的には改修案の方がベターと思われるので,修正をフィックスしておこう.ここで一度バックアップを取っておこう.大体通りそうな雰囲気なのでリリース版を起こしてみる.

▲C:\Users\babalabo\Desktop\反例2019-02-02\BUG19-02-01 06-39-27.ZELを開いて非連結系列が発生する.この図面では重婚同類グラフが循環していると考えられるので,非連結となるのは避けられないのではないだろうか?おかしい.デバッグモードでは非連結になっていない.リリースモードでも起きていない.アプリのバージョンが古い.なぜだろう?どうもまずい.エラーなしでインストールできていたのだが,プログラムが差し替わっていない.アンインストール→ インストールで動作するようになった.

反例2019-02-02の21本は開けた.反例2019-01-28では7本中4本で障害が発生した.

▲反例2019-01-28\BUG19-01-27 06-56-47.ZELを開いてエラーが発生する.NAMEBOX::IsPossibleBTWLeftHandで (rightwife->IsLeftHandBox())により停止する.右手婚配偶者が左手本人というエラーだ.障害が起きているのは#201AA(0).これはおそらく「左手枠配偶者を左手本人とするBTW拡張@20190130」に依るものと思われる.いや,ちょっと違うのではないか?

この拡張で配偶者でも左手本人になれることになったが,左手本人と右手婚配偶者が同一ということはあり得ない.これは単純に却下でよいのではないか?ゼロ復帰するようにしてエラーは解消したが,多重が発生するようになった.このエラーを無視すれば多重は発生しない.AAの出現は4つある.

  1. (0) 配偶者 不可視 DOUBLYBLESSED|BTWRIGHTSPOUSE
  2. (1) 本人 不可視:消去された仮ノード
  3. (2) 配偶者 可視 被参照実ノード DOUBLYBLESSED
  4. (3) 配偶者 不可視 BTWRIGHTSPOUSE

AAは結婚を3つ持っている.すべて有配偶者で相手は,①CK,②CR,③FKだ.

image

CKは基準ノードでAAはその配偶者だが,CKのボックス内に入っていない.多重カードゼロというのはよいが,「基準ノードの配偶者は基準ノードに近接配置」という原則が崩れている.連結線の欠落もあるが,それはあとから見ることにしよう.AAは単親婚は持っていないので原則どこにでも配置できるはずなのだが… FKとの間には子どもはいないが,それ以外の二人との間にはいる.CRとの子どもは配偶者であるAAの預かり,CKとの子どもはCKの下にある.

図面的には多重ゼロとなっているので一応「解」と認められるが,なぜ基準ノードの枠外に出てしまっているのか?その理由を見ることにしよう.AAは本来ならBTWにならなくてはならないのだが,そうなっていないのはなぜか?基準ノードの配偶者AA(0)が不可視というのが問題だ.つまり,この結婚はBTW右手婚とすべきではない.

今夜はGYAO!で「逃亡者」と「ホワイトハウスダウン」の2本立て

午前7時半起床,晴れ.昨日は一日スマホで映画を見て暮らした.ヤフー系列のGYAOではかなりの最新作を無料配信している.「逃亡者」と「ホワイトハウスダウン」を見たが,どちらも予想していたのよりずっと面白かった.無料配信される期間はかなり短いが,ピックアップして選択するのに十分な程度の本数がある.もう一つ,時間を消費したのは「英会話のレッスン」プログラムだ.

映画を見る目的の一部には英語力の強化を狙うという意図があるが,スマホを使えばかなりのことができそうな感じがしていたので適当な教材を探していた.最強の教材として「おうちホームスティ」というのを見つけたが,これは受講料が20万円以上掛かるので到底手が出ない.Vannesaという米国女性がやっているYouTubeサイトがあったのでこれを使うことにした.Vannesaには有料のコースもあるが,200本以上のフリービデオがあるのでこれだけで間に合うと思う.

▲凍結2019-01-20\BUG19-01-12 04-20-39.ZELを開いてTRIBELIST::MakeUpTreeで「系列優先実ノード不在」が発生する.エラーを無視して描画は可能.障害は[系列枠]: #1046 odr=0 先祖=#812 蔵人の少将(夕顔)(0)[0] 優先=#1170 軒端の荻(2)で起きている.出力図面では軒端の荻の仮ノードは3つある.(0)は一院系列の配偶者ノードでBTW左手本人,(1)は伊予介系列の消去された仮ノード,(2)は蔵人の少将(夕顔で不可視のBTW右手配偶者になっている.

軒端の荻(1)がBTWの左手本人でかつ配偶者というところが変則的なところだ.これは軒端の荻が基準ノード光源氏の配偶者であるために起こっていることだが,一時的にであれ優先実ノード不在になる理由を調べてみよう.MakeUpTreeのステージ【2】系列優先仮ノードと優先実ノードを設定するでは①SetPrimeNodeの実行,②MakeUpTree,③EstablishMajorTribeChainを実行している.系列優先実仮ノードは①のSetPrimeNodeですでに設定されているのだが,③のEstablishMajorTribeChainで逆に不良動作しているように思われる.

この処理は少し余分なことをやり過ぎているように思われるので,GetMajorTribeChainまで縮退させてよいのではないだろうか?GetMajorTribeChain→ setMajortribeで実ノードが落ちている.setMajortribeで「2017-08-06 系列優先実ノード参照をリセットする」という修正が入っている.この修正の意味はよく分からないが,この関数で系列優先実ノードをリセットするというのはほとんど意味がないと思われるので暫定修正して動作するようになった.一応ここでバックアップを取っておこう.

▲反例2019-02-02\BUG19-01-28 08-11-48.ZELで隠蔽された系列優先実ノードが出現する.エラーは[系列枠]: #722 odr=0 先祖=#458 摂政太政大臣(0)[0] 優先=#288 玉鬘(0)で発生している.

TRIBELIST::MakeUpTribeのステージ【2】系列優先仮ノードと優先実ノードを設定するのループでTRIBEBOX::MakeUpTreeのあとで実行している検査とSetupPrimaryNodeをループの外に出して別ループで実行するようにしてこのエラーは解消したが,今度は別の位置でエラーが出るようになった.[系列枠]: #806 odr=0 先祖=#376 ※3(0)[0] 優先=#282 桐壷の更衣(0)の優先ノードは桐壷の更衣.桐壷院が基準ノード承香殿女御(朱雀院の)の配偶者であるため,桐壷院+桐壷の更衣の結婚は桐壷の更衣の系列で展開されている.

このため桐壷の更衣の仮ノードは1個しか存在しないので系列優先ノードを桐壷院に切り替える必要がある.エラーを無視して描画した場合には冷泉院に切り替わっているが,実仮ノードで世代差が発生している.この図面では重婚同類グラフが循環しているので異世代多重が発生することは避けられないが…

TRIBEBOX::decidePrimaryNodeで優先仮ノードを決定する時点で優先実ノードの存在を確認するようにした.このためにGetRealnode(NAMEBOX*)という関数を新設した.優先実仮ノードの対が得られないときはGetAlternativePrimeNodeが実行され,優先仮ノードの切り替えを実施する.これで桐壷の更衣から桐壷院に切り替えることができたが最終的には冷泉院に切り替わる.

系列優先実ノードが隠蔽リスト上にあるという問題

午前1時起床,晴れ.朝食は昔懐かし日清のチキンラーメン+ネギと卵.「単親婚を持つノードはつねにBTW左手本人となる」という原理の意味.「単親婚」とは配偶者のいない結婚のことだが配偶者も子どももいなければ「結婚」は成り立たないから「単親婚」には必ず子どもがいる.また,単親婚はつねに本人直下にあり第三者に譲ることはできないから,単親婚本人はどのような方法によっても「消去」できない.従ってそのノードに関わるそれ以外のすべての結婚はBTWによってこのノードに接合されなくてはならない.

N一族家系図に取り組み初めてすでに3ヶ月経過したが,途中に大きなブランクが生じたためまだ収束にはほど遠い状況で足踏みしている.方針はすでに決定しているのだから,粛々とバグを片付けてゆくしかない.凍結2019-01-20\BUG18-11-23 17-41-29.ZELというサンプルはすでにクリアしていたはずだがエラーが出ているのでチェックしておこう.

▲凍結2019-01-20\BUG18-11-23 17-41-29.ZELを開いてエラーが発生する.TRIBEBOX::GetRealnodeで[系列枠]: #159 odr=0 先祖=#114 AF(0)[0] 優先=AIの優先実ノードが隠蔽されている.このエラーはMakeUpTreeの中で起きている.エラーを無視して描画は可能.

image

系列AFの優先ノードAGの仮ノード(1)は(0)を参照しているが,TRIBEBOX::MakeUpTreeが実行されるまではすべてのノードは隠蔽リスト上にある.⇒かなり大きい修正を施してエラーは出なくなった.修正の方向は基本的に正しいと思われるので,バックアップを取ってから仮修正をフィクスすることにする.いや,もう少し進めてからでないと無理だ.

単親婚を持つノードはつねにBTWの左手本人となる

午前7時半起床,曇り.日清のチキンラーメン+生卵.「三角BTWの導入により配偶者多重を恒久的に解決する」という課題は実装をほぼ終えてある程度動作しているが,まだ抜けているところがある.N一族家系図をN氏でソートしたときN氏の配偶者3人のうち,UYが外に出てしまうという事象はUYが単親婚を持っている限り避けられない.単親婚の子ども枠を保持する場所がなくてはならないからだ.単親婚を持つ配偶者が外に出てしまうのは「仕様」だが,単親婚に配偶者を追加して有夫婚に変えることで回避できる.

この図面は多重ゼロとなっているのですでに「瑕疵のない図面」を実現できているが,単親婚を有夫婚に変えるところで多重が発生する.UYは単親婚の子ども2人を持っているが,2人の子どもはそれぞれ父親が異なる.仮に2人の子どもの父親が同じとすれば問題は生じない.また2人の子どもに別々の父親を登録した場合にも問題なく描画できる.問題は1人の子どもに父親を与え,もう1人を単親婚に残した場合だ.

このような状態でUYがN氏のボックスから出た状態になるのは避けられないとしても,UYのカードが3枚も出るという状況に陥るという点が問題だ.拡大して見てみよう.

image

多重になっているのはCRだ.CRの単親婚は基準ノードとBTW結合されているが,それ以外の2つの結婚は放置されている.この問題を片付けるためには,もっと強い規則が必要と思われる.つまり,「基準ノードに関わりがあるかによらず,単親婚を持つノードはつねにBTWの左手本人としなくてはならない」.言い換えれば,「本人ノードの配偶者の別の本人仮ノードが単親婚を持つ場合には,そのノードとBTWを組まなくてはならない」ということだろう.

NAMEBOX::IfBTWPossibleの冒頭で「左手本人仮ノードが単親婚を持つ場合にはつねにBTWを構成する@20190131」を判定するようにした.これは最高度の優先度を持つルールと言ってよい.多分これですべての問題は片付いたのではないかと思う.あとはBTW連結線の欠けている部分を補うだけだ.この連結線が描画できないのは,配偶者が左手本人になっているためだ.btwrightboxを「左手枠配偶者を左手本人とするBTW拡張@20190130」に対応修正することで問題なく描画できるようになった.

これで一件落着か?と思われたが,まだN一族2Xで多重が発生している.

image

単純に仮ノード消去できるような局面であるように見えるのだが… UnErasablecで「家内婚左手本人は消去不可」という理由で残されている.この制限を取り除けば問題なく描画できる.

image

本妻タケは佐藤家の実子で均との結婚しか持っていないが,均が婿養子であるため「家内婚」を構成している.従来論理ではこのような場合にはその家内婚がゴールド婚の場合のみ左手本人の消去を認めていた.これまでの論理では家内婚は右手本人預かりとなっていたためと考えられる.左手本人は独自の結婚を持つ可能性があり,そのような場合には仮ノード消去できない状態になると考えられるので妥当な規則と思われる.しかし,「家内婚は左手本人預かりとする@20190126」というオプションの元では事情は変化する.

NAMEBOX::IsMukoYoshiという関数は右手/左手に関わりなく家内婚当事者の場合は真を返している.実際,今のケースではタケ(0)は右手本人だ.一般に仮ノード消去の対象となる本人ノードは「空手」でなければ消去されないと考えられるのでこの制限はまったく不要と考えてよいと思われる.この問題は多分これで解決したものと思われるが,まだ完全には収束していない.本妻タケでソートすると,今度は後妻コウで多重が発生する.

と言っても多重カードは画面左上に隠蔽された状態で表示されている.かなりおかしな状態になっている.最初にMakeUpTreeのステージ【8】実ノード参照可能であるかどうかをチェックで系列優先実ノードが隠蔽状態になっているとして,停止する.障害が起きているのは[系列枠]: #581 odr=5 HM=0 先祖=#364 野原太郎(0)[5] 優先=#362 後妻コウ(0)→#617 後妻コウ(1) →主系列#509:佐藤家.つまり,「最初から悪い」状態になっているものと推定される.

image

妻コウの結婚は一つだけだ.均はタケと家内婚を組んでいるので,均+コウの結婚はBTWとなり,子どもはコウの預かりとなる.優先実ノードのコウ(1)は家内婚配偶者であるために隠蔽されているのだろう.この接続関係はPRIME_BTWRIGHT(BTW右接続関係:両手に花右手本人→左手本人)になっていると思われるが,調整されていないのではないだろうか?それ以前の問題として,TRIBEBOX::GetRealnodeという関数はかなりできが悪いので書き換えが必要だ.均が基準ノードの配偶者であるため,均+コウは配偶者の配偶者預かりとなって移転している.

CARDLINK::getProxyではつねに仮ノードを可視化して返していたが,隠蔽ノードは可視化しないようにした.これでMakeUpTreeのステージ【2】系列優先仮ノードと優先実ノードを設定するでSetupPrimaryNodeにより系列優先実ノードを設定しようとしたとき不可視ノードであるために停止するようになったが,MARGBOX::GetUpperNodeではSUWが発生するようになった.フローが変わってしまったようだ.CARDLINK::getProxyで隠蔽ノードは可視化しないようにするとフローが変化してしまう.この関数はかなり初期から使われているものなので現状のままとするしかなさそうだ.

CancelGoldenCoupleでゴールド婚をリセットしてもフラグが立ったままという現象があるので,まずこれを片付けておこう.障害が起きているノードは均(0)#210.結婚チェーンが空になっている.ただし,右枝には結婚枠が入っている.結婚チェーンが不良ということになる.どうもこのノードはTRIBEBOX::MakeUpTreeを通っていないようだ.このノードはHAVESAMEPARENT属性を持つ,つまり家内婚配偶者だ.

BTWの入口でCancelGoldenCoupleを実行しているが,この関数の主語は本人ノードであることを仮定している.今回のBTW拡張で配偶者が左手本人になる場合が発生しているのでそれに対処しなくてはならない.NAMEBOX::CancelGoldenCouple自体を両用可能であるように作り変えておくことにしよう.これでとりあえず障害は解消した.さて,問題はTRIBEBOX::SetupPrimaryNodeで系列優先実ノード候補が隠蔽されている場合の措置だ.隠蔽ノードが優先実ノードになる理由は以下の通りと考えられる.

  1. 系列分解時の野原系列の優先仮ノードはコウ(0),優先実ノードはコウ(1)になっている この時点ではコウ(1)は均(0)の配偶者
  2. 本人ポジションの均(0)は婿養子なので本妻タケ+均(4)は家内婚を構成する
  3. 本妻タケは基準ノードなのでその配偶者均の結婚は配偶者の配偶者,今の場合は後妻コウの場所で展開される
  4. 均+コウの結婚は野原系列で均(4)+コウ(0)のように展開される
  5. 均の多重カードを削減するためにBTWが実施され,均(4)はBTW右手婚配偶者として消去される
  6. 系列分解時の野原系列の優先実ノードコウ(1)は展開されなかったため,無処理で隠蔽リスト上に置かれたままになっている

この無処理ノードコウ(1)を代替する優先実ノードを決める論理は以下のようなものになると考えられる.

  1. 優先実ノードが隠蔽リスト上にあって,関係=未定であるとすればこのノードBが関係する結婚A+Bが展開されなかったことを意味すると推定される
  2. この未処理結婚リンクは実ノード候補Bの結婚リンクMから取り出すことができる また,この実ノードの属する系列Kも取り出すことができる
  3. 優先実ノードBはこの結婚枠では配偶者であったと推定されるが,結婚枠Mが配偶者側で展開されているため主客が逆転しているので,この結婚枠の現在の配偶者Aが求める代替優先実ノードになるものと推定される
  4. この推定に従いAの仮ノードを走査して所属系列がKであるようなノードがあれば,それが求める代替優先実ノードである

まず,これで一応の解になっているのではないかと思う.これ以上複雑な手順が必要になるか否かはいまのところ分からない.原理的にはこれで十分ではないかと思われるが,今のところまだ証明は得られていない.下図は均でソートしたもの.

image

これを本妻タケでソートすると下図のようになる.

image

まずまず,妥当なのではないかと思う.11月初旬に掛かった自家系図に関わる改修はほぼ完了したと見てよい.リリース版を起こして少し走らせてみよう.ダメだ.まだ大量の障害が残っている.検定2019-01-28には543本の障害サンプルが入っているが,ほとんど解けていない模様だ.終わった.

image

20本しか減っていない.どうもまだまだという感じだ.机上に反例が4本あるのでまず,これから掛かることにしよう.ダメだ.デバッグモードで再現できない.リリースモードではTRIBEBOX::Groupで停止する.Check文が残っていたためだ.

image

TRIBEBOX::SetupPrimaryNodeで代替実ノードの取得に失敗している.反例はBUG19-01-28 08-11-48.ZELで障害が起きているのは#457摂政太政大臣@127 系列.優先ノードは#288玉鬘(0)だが,結婚枠は配偶者を持っていない.「左手枠配偶者を左手本人とするBTW拡張@20190130」を止めてみよう.ダメだ.「家内婚は左手本人預かりとする@20190126」も止めてみる.「基準ノードの子ども枠はBTW不可とする@20190129」まで止めてみたが変わらない.