2019-03-09

午後3時半起床,曇り.朝食は油揚げ入り卵うどん.昨日は業スーで買い出ししてきたので卵や牛乳など「高栄養食品」がふんだんにある.百合が180円という特価で売っていたので,この部屋には似合わないかもと思いながら買ってきた.大輪でもしかしたら「蘭」と呼ぶべきなのかもしれないが,百合と蘭の違いが分からない.今日は散歩の帰りにダイソーに回って歯磨きなどを購入.ともかく朝食を食べてからウォーキングという流れだけは確立できたように思われるが,スマホのアクセス時間は短縮されていない.

今日もまたYoutubeで長いクリップを見てしまった.英語教材は通常は5分~15分,ウォーキングに出るときはそれらを何本かまとめて30分~1時間くらいのストリームに仕立てているのでほぼコントロールできているのではないかと思われるのだが,やはり曲者は「長時間ビデオ」ではないだろうか?今日は長いビデオは1本しか見ていないはずだが,トータルでは10時間くらいになってしまっている.長いビデオは「後で見る」ことにして今後は週末にまとめて見ることにしよう.まぁ,過ぎてしまった時間は取り戻せないのでともかく仕事に入ろう.

サンプルは依然として反例2019-02-26\BUG19-01-27 06-56-47.NONだ.この図面はエラーは出ていないが,いろいろおかしいところがある.一番問題なのは重婚同類グラフが循環していないのに非連結系列が発生しているという点だ.非連結系列は8つある.このうちCU系列だけはPRIME_MARITALタイプだが,それ以外はすべてPRIME_PARENTタイプだ.ただし,優先仮ノードと実ノードが同名になっているのはDN系列だけでそれ以外はすべて別ノードと接合している.これはかなり疑問だ.[系列枠]: #521 odr=6 HM=0 先祖=#223 AL(0)[6] 優先=#736 AJ(1)→#203 AB(0) →主系列#509:AIのケースを見てみよう.

AJは親を一組しか持たないのでPRIME_PARENTは明らかに誤っているように思われる.しかし,結婚も一つしか持っていない.配偶者はABだ.ABもAJとの結婚しか持っていないが,この結婚はABの預かりとなっている.従って,AJは仮ノード消去されなくてはならないのだがそうなっていない.理由を探ってみよう.仮ノード消去はNAMEBOX::EraseGhostNameで処理されているが,この関数では本人ノード→本人ノードのケースしか処理されていない.いや,それは間違いだ.NAMEBOX::IsPossibleRealnodeで実ノード側が弾かれている.理由は

!hidden() && getvisible() && (getmarglink() || getrelation() == REL_ROOTS) && !empty && !getghostbits(DUMMYBOX|EXTRACTDUMMY)

でないためだ.このノードは不可視になっている.かなり疑問だ.どこで不可視になっているのかSWOで探索してみることにしよう.いや,この関係は先行してBTWで処理されているようだ.確かにBTWを先行させるような論理変更が実施されている.AJ(0)はDOUBLYBLESSED|BTWRIGHTSPOUSE属性を持っているが,(1)はBTW属性を何も持っていない.これはかなりおかしい.AJもABも結婚を一つしか持っていないのだから,AJ(0)が左手本人かつ右手配偶者となることはあり得ないと考えられる.

現行では配偶者が左手本人となることを認めているが,それには条件があったはずだ.このBTWはAJ(0)が左手本人となる構成で成立している.仮にそれで良いとしてもそうであるとすれば右手婚が誤っている.NAMEBOX::IfBTWPossibleでこのようなケースを弾くようにした.これで問題は解決したようだ.

image

非連結系列は解消し多重も発生していない.このバージョンを少し走らせてみよう.とりあえず,反例2019-02-26の4本は通った.反例2019-02-02の21本も通った.反例2019-01-28の19本も通った.反例2018-11-09にはまだ解けていないサンプルがある.どこかで無限ループしている.仮検定用サンプル\反例2018-11-09\BUG18-10-30 22-50-03.ZELと思われる.

▲仮検定用サンプル\反例2018-11-09\BUG18-10-30 22-50-03.ZELで無限ループが発生する.MPLCでレッドラインオーバーが起きている.天皇家の派生ファイルで基準ノードは@23 大山守皇子.どうもこのサンプルは相当加工が入っているようなので一旦無名化してから解析することにする.基準ノードのAWは結婚を1つしか持っていないが,その配偶者のNBが複数の結婚を持っていることが問題を複雑なものにしているように思われる.また,家内婚が5つも発生していることも撹乱要因になっている可能性がある.

SUWは可能だが図面はほとんど壊れていて,全体を見ることができない状態になっているが,TRIBEBOX::CheckMargBoxChangedでスラッシングが起きているようだ.障害はTribeRelocationのステージ【5.2】重婚同類グラフ検定の事後処理を行なうの出口で起きている.不良動作に関わる結婚枠は4つある.いや,もっともっと広範で複雑な動作になっている.最終的には大量の不可視結婚枠で「不可視ノード移動」が発生するようになる.

これを暫定的に止めると最終的に3つないし4つの結婚枠で「不可視枠を移動」ないし「結婚点を一致」が起こるようになる.「結婚点を一致」が起きているのは[結婚枠]:#543:#659 CD(0)+#1427 QY(0)→#4233 CS(2) だが,「不可視枠を移動」を暫定的に停止すると[結婚枠]:#4469:#1247 NL(0)+→#1249 NM(0)で「TYW枠の移動」が発生するようになる.「TYW枠の移動」を止めると今度は4つの結婚枠で「ゴールデンペア」が発生するようになる.

CRUSHCOUNTOVERした結婚枠をすべて排除すると描画まで進むことができるが,多重が5件発生する.これらの多重は世代的にかなり離れた位置で起きている.どうもかなり手に負えない状態になっているように思われる.図面はかなりの改変を受けているように思われるが,全体図を見ると骨格には変化がないようにも思われるので,おそらく改変があったとして局所的なものに留まるように思われる.従って,この図面はどうあっても仕上げられなくてはならない.仮修正する前にバックアップを取っておくべきだった…

今日のところはこれ以上手を付けずに明日に回すことにしよう.

コメントを残す

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

CAPTCHA