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」まで止めてみたが変わらない.

トライアングル関係BTWの導入で配偶者多重問題を解決する

午前0時起床,晴れ.朝食は薄切りトースト2枚,コロッケ小1個.現行のBTWの機構では解消できない「配偶者多重」を解決するために「三角BTW」という構成を導入する.これは現行の「対BTW」の左手本人となる資格を「左手枠配偶者」まで拡張するというものと言ってよい.BTWという仕組みは「同世代の結婚当事者は必ず接合できる」という原則を実現するための基礎であり,ゼルコバの木系図エンジンのもっとも主要なコンポーネントをなすものであるから,修正もかなり広範囲に及ぶことが予想される.

この修正は「左手枠配偶者を左手本人とするBTW拡張@20190130」というコンパイルオプションで実施することにする.NAMEBOX::DoublyBlessedOneは以下から呼び出されている.

  1. TRIBEBOX::BetweenTwoWomen TribeRelocaitonのステージ【5.2】重婚同類グラフ検定の事後処理を行なうで実行
  2. NAMEBOX::FindDoublyBlessedOne TOPOLOGY::ReduceMultiCard
  3. NAMEBOX::ConvertGhost2BTW GENEBOX::CheckInverseCycle
  4. PAIRLIST::VerifyPairBox GENELIST::CheckPairBoxCollision,
  5. TOPOLOGY::ReduceMultiCard TribeRelocationのステージ【7.9】仮ノード消去と両手に花を適用して多重カードを削減で実行

三角BTWは必ずしもこれらのすべてをカバーする必要はないと思われるので,ReduceMultiCard→FindDoublyBlessedOneでのみ対応することにしてみよう.YKはReduceMultiCardの中でIsVisibleCardでないという理由で弾かれている.IsVisibleCardは配偶者ノードを除外している.この関数はここでしか使われていない.このブロックではFindDoublyBlessedOneとEraseGhostNameを実行している.後者は本人ノードだけが対象だ.IsVisibleCardの代わりにIsValidNameBoxを使うようにした.この修正だけであとはまったく何も変更せずにBTWが成立した.

!実にすばらしい!多重は完全に解消した.

image

ただし,基準ノードの脇にはYKしか残っていない.基準ノードの3人の配偶者のうち,UYが外部に出てしまうのはある程度やむを得ないように思われる.というのはこのノードの外部婚は単親婚なのでこのノード以外には子ども枠を保持するノードがいないためだ.この点,YSは外部配偶者を持っているのだから,消去できてもよいはずなのだが親の存在が枷になっているようにも思われる.この図面は「合法的」であると考えられるので「基準ノードの子ども枠はBTW不可とする@20190129」を復活させてみよう.

image

これで基準ノードの配偶者はすべて近接位置に戻ってきたが,多重が2件発生した状態になっている.YKは多重にはなっていないが,BTW連結線が欠けている.この描線は未対応なのであとから見ることにしよう.多重カード2件のうち,有夫のYSのケースを追いかけてみる.要点を挙げてみよう.

  1. 基準ノードの配偶者の結婚は配偶者の配偶者の預かりとなっている
  2. 基準ノードの配偶者は親を持ち,そのポジションで配偶者の配偶者とBTW接合している このBTWは不可としなくてはならない
  3. 多重カードとは本人ポジションにあるカード数に他ならないから,配偶者の親の家にいる配偶者本人を消去しなくてはならない.
  4. 配偶者本人を消去できれば配偶者の配偶者ポジションカードの結婚は基準ノードの配偶者を左手本人とするBTWによって消去できる

項目2の禁止事項を実装してみよう.この項目は「基準ノードの配偶者は基準ノードの配偶者ポジションで左手本人となる場合を除き,BTWを組むことはできない」と翻訳される.⇒うまくいったようだ.

image

多重が1件残っているが,止むを得ないだろう.この配偶者は実家で単親婚を持っている.この子ども枠を保持するためには,このノードは実家に残るしかない.これを避けるためには単親婚を有夫婚に変えればよいというだけだから,回避策は存在する.多重を避けることを優先するか?ないし,明示的に外部婚配偶者氏名を記入することでそれを回避するかは,「当事者の自由」だ.多重の回避措置を取らない場合には最後の手段としてBTWを許可するということも考えられる.

この場合には結婚相手は遠いところに行ってしまうのだが,多重が発現するよりはマシかもしれない.例えば,渋沢栄一の場合で言うと,大内くにの場合がそうだ.くには2度結婚しているが相手の氏名が判明しているから,多分栄一から遠くないところに配置できると思う.従って,規則としては「もし,基準ノードの配偶者が外部に単親婚を持っている場合には左手本人となることを許す」とすべきだろう.⇒!できた!完装した!

これで「妻を寝取られた男の残念な家系図」問題は恒久的に解決したのではないかと思う.下図には多重は残っていない.N氏の三人の配偶者のうちの二人はボックス内に残り,もう一人は単親婚の子どもたちのために実家配置になっている.これでよいと思う.

image

試みにこの配偶者の単親婚に明示的な夫を与えてみよう.この母親には父親の異なる子どもが2人いる.そのうちの一人に父親を与えたところ,GetAlternativePrimeNodeで例外が発生した.→対処した.

どうもまだ,完全解には至っていないようだ.また,多重が発生してしまった.二人の子どもの父親が同じとすれば多重ゼロで解決する.母親が3つ結婚を持つ場合(うち一つは単親婚)に起きている多重が避けられないものであるのかどうか見ることにしよう.この多重は外部系列で起きている.

image

開発三種の神器の一つ「草薙のデバッグブレーク文」が復活した

午前0時半起床,晴れ.朝食は薄切りチーズトースト2枚,コロッケ小1個.「妻を寝取られた男の残念な家系図」をなんとかしなくてはならない.それが目下喫緊の課題だ.かなり難しい問題だがやるしかない.その前に一つ片付けておかなくてはならないことがある.例のSTOP文だ.STOP文は以下のようなマクロとして定義されている.

#define STOP { __asm int 3 }

これまではプログラム中の任意の箇所にこの「STOP」を挿入するだけで簡単にブレークできていたが,Visual Studio 2017 に移行してからはSTOPで止まることができなくなってしまった.いや,一回だけは停止するのだがそのタイミングでコードが書き換えられ,それ以降は止まらなくなる.仕方ないので「初回停止したときに手操作でブレークポイントを設定する」ということにしたが,これではやはり用に足りない.たとえば,

if (some condition) STOP;

という文があったとすると,この文全体にブレークポイントが掛かってしまうためブレーク文の意味がなくなってしまう.

if (some condition) {
  STOP;
}

とすれば条件が成立したときだけ止めるようにすることはできるだが,簡潔さに欠ける.マクロの中でSTOPマクロを使っているような場合などにはお手上げだ.このような状況で,一度は Visual Studio 2005 まで戻ってしまおうか?とさえ考えたのだが,それもあまりに退行的と思われたのでいろいろ試みた末,下記のような代替構文を考案した.

#define STOP { try { __asm { int 0} } catch (…) {} }

__asm int 0 というのはあきらかにイレギュラーなステートメントだが,余分なメッセージを出さずにブレークできるので __asm int 3 とほぼ等価な動作になる.ただし,これは「割り込み」ではなく「例外」なので例外ハンドラーでキャッチする.少なくとも外観的にはこれで完全に int 3を代替することができる.いや,完全に同じではない.STOPでブレークするときには下記のようなパネルすら表示されなかった.まぁ,この程度のことは仕方ない.中断/継続ボタンで動作を選択することができる.

image

「中断」すれば,ブレークした正確なソースコードの行番号が分かる.変数などを調べてからまた「続行」することができるし,「継続」でただちに続行することもできる.これでようやく Visual Studio 2005 で慣れ親しんだ開発環境に戻ることができた.この「STOP文」は馬場研究所の「三種の(プログラム開発用)神器のうちの一つ」とも言うべき大事な「資産」であり,これがなくては手も足も出ない.今後はこれを「草薙のデバッグブレーク文」と呼ぶことにしよう.

ざっくり修正して多少動くようになった.3段階の措置が必要となっている.

  1. MARGBOX::IsPrimeboxOrNotで「基準ノードの配偶者の配偶者で展開」に切り替える 基準ノードの配偶者の配偶者は「単身先祖配偶者」の立場から「本人ポジション」を得て外部系列先祖ノードとなる
  2. DecidePrimaryNode で外部系列の優先ノードを先祖ノードからその配偶者に切り替える decidePrimaryNode では優先ノードが決定できない場合にはTRIBEBOX::GetAlternativePrimeNode を呼び出して代替候補を探す
  3. これにより外部系列に属する「基準ノードの配偶者」は「配偶者ポジション」に配置されるが,多重カード状態を解消するためにはこのあとでBTWを組まなくてはならない.

ステップ2まで消化した段階では多少のエラーを無視して下図が出力される.

image

基準ノードは配偶者を3持っているが,うち2つは外部系列内で配偶者ポジションに配置されている.ここで「基準ノードの子ども枠はBTW不可とする」という制限を外すと基準ノードの配偶者は一人を残して外に出てしまう.この動作はかなり奇妙だ.確かに「基準ノードの子ども枠はBTW不可とする」という規則は「基準ノードの子ども枠はBTWの右枠としない」ことを意味するから,少なくとも外に出てゆく動作はそれに適ったものと言えるが,なぜ一つだけ残るのかその理由が分からない.これは「別の問題」ではあるが,まずこちらから見ることにする.

image||

いや,少し考え違いしていたかもしれない.この図面では基準ノードN氏の配偶者であるYKの出現は2つあるが,どちらも配偶者だ.少なくとも現行ではこのような構図をBTWによって解決することはできない.なぜか?「そうなっていないから」と言えばそれまでだが,BTWが成立するためには少なくとも2人の本人当事者が必要だ.これをA,BとすればAはBと結婚していることが前提となる.このような条件の元で配偶者ポジションのBを消去して多重解消するというのがBTWの仕組みだ.今の場合はA,Bという本人の他にCという配偶者が存在し,AとC,BとCが婚姻しているという構図になっている.

このような状況に対処するためには,BTWの構成を大幅に拡張しなくてはならない.また,それが実現できないといま追求している「残念な家系図」を改善することもできないだろう.というのは,上記したような補正によって発生する図式は明らかにA,B,Cの3つ巴の関係式になるからだ.現行のBTWは Between Two Women と言いながら実際に扱っているのは「遠隔の対関係」であり,三角関係にはなっていない.Cが本人ポジションを持っていれば,2つのBTWを組み合わせることで「両手に花」状態を演出することが可能だが,Cの出現がすべて配偶者ポジションになっている場合には適用不可能だ.

これまでは「多重カードがすべて配偶者ポジションのカードのみの場合には『不可避の多重』として無視する」というルールになっていたが,上記の三角関係BTWが実装されれば,このような「配偶者多重」の問題を解消することが可能になる.これは画期的な進歩であり,もしこれが実現できれば「重婚同類グラフで循環がなければ多重カードは発生しない」という原則を「例外なし」に確立することができる.つまり,系図作図上の最大の課題である「多重カードの極小化」の完全解ないし最適解を得ることができる.

事例では「配偶者多重」が起きているのはほとんど女性の場合に限定されていたので,これを「あちこちに男のいる多情な女が多重になるのはどうしようもない」と解釈して(割り切って)いたが,この判断には「性差に関するある種の偏見」つまり,「男性優位の見方」が影響していたように思われる.「残念な家系図」がクローズアップされたことでようやくこれが「節操のない女の問題」ではなく,一般的な三角関係問題の一部であることが認識されたと言える.

現行のBTWをアレンジするだけでこのような場合に対処することは可能だろうか?現行方式ではBTWの要素は以下に限定される.

  1. BTW左手本人
  2. BTW右手本人
  3. BTW右手枠

BTW左手本人とBTW右手本人はBTW連結線によって結合される.これをBTW対関係と呼ぶとすれば,BTW三角関係は以下の4要素からなると考えられる.

  1. BTW左手本人
  2. BTW右手本人
  3. BTW左手枠 配偶者存続枠
  4. BTW右手枠 配偶者抹消枠

BTW連結線はBTW右手本人とBTW左手枠配偶者を連結するものとなる.この操作によってはBTW左手枠はまったく改変を受けないと考えられるから,無視することができるとすれば,下記のようになる.

  1. BTW左手本人=BTW左手枠配偶者
  2. BTW右手本人
  3. BTW右手枠 配偶者抹消枠

これなら現行のBTW論理とほとんど相似形と言ってもよいトポロジーになりそうだ.BTWは通常BTW左手本人から発案されることになっているので,その資格を「BTW左手枠配偶者」まで拡張すれば何とかなりそうな感じだ.いずれにしてもかなり大掛かりな修正になることは間違いないので,まず,バックアップを取ってから始めるのが適当だ.

妻を奪われた残念な男がせめて家系図上で妻を取り戻すには

午前1時起床,晴れ.「家内婚は左手本人預かり」とは,MARGBOX::IsPrimeboxOrNotの動作の問題だ.この関数自体を廃止するという考え方もある.IsPrimeboxOrNotの主要論理はMARGBOX::IsPrimeboxの中で実施しているが,この関数は実際には「系列参照関係を変化させない」ように注意深くチューニングしてある.一方「家内婚は左手本人預かり」に関わる措置はIsPrimeboxに先行して実施されているため,系列参照関係を破壊するような動作になっている.

まず,これをIsPrimeboxの中に落とし込んでみよう.反例はN一族2.zelだ.このサンプルで家内婚の再配置ができなければ意味がない.⇒「家内婚は左手本人預かり」処理をIsPrimeboxに組み込み,さらに判定の優先順位を変更して「左手本人預かり」の動作になるようにしたが,再配置されていない.IsPrimeboxOrNotの冒頭でこの処理を実施するようにすれば予定したような動作になる.かなり奇妙だ.これはおそらく,IsPrimeboxの判定のあとで別途後処理をやっているためではないかと思われる.これはかなり問題の多い論理だ.IsPrimeboxの論理は最終的なものでなくてはならない.

この後処理は系列優先仮ノードに関わるものなので,IsPrimeboxの中で先行処理するようにした.これで一通り整理が付いたものと思われる.循環が発生するような反例で動作を確認してみよう.BUG19-01-21 08-52-58.ZELの場合は「左手本人預かり」で処理されたようだ.もう一つの反例を見てみよう.BUG18-10-07 17-11.ZELも解けた.このサンプルでは「左手本人預かり」は実施されていないはずだ.問題ないようだ.

これでこの件は一応一件落着としてよい.バックアップを取って仮修正を一掃しておこう.BUG19-01-21 08-52-58.ZELでは家内婚が検出され,系列優先ノードの付け替えが実施されている.これでよいのだろうか?このケースの場合 IsPrimeBoxではこの状況をかわすことができなかったと見られるが,たまたまうまく解決できたという見方もできる.このようなケースまで完全に排除する必要があるのか?さらなる研究課題として残る.

このサンプルではAFTERMARGSAMEGENEフェーズでも事後的に主系列が変化している.この付替えの理由は分からないが,家内婚の問題というより複数の親を持っていることに関わりがあるのではないかという気がする.家内婚の再配置を実施する前に系列優先ノードの付け替えが発生することを「事前予測」することは可能だろうか?かなり難しいように思われるが,そうした結果少なくとも循環が発生しないことを保証しなくてはならない.できるだろうか?これもまたかなり難易度の高い問題であるような気がする.

ともかく,一度リリース版を起こしてもう少し走らせてみることにしよう.⇒思った通りというか,またSUWが出た.まだこの論理は収束していないものと見られる.SUWを出したあと,ハングしている.⇒ダメだ!再現できない.反例サンプルは机上に生成されているが,開けてしまう.かなりまずい.15点サンプルで実質的にBUG19-01-21 08-52-58.ZELと同じではないかと思われる.⇒なぜだろう?BUG19-01-21 08-52-58.ZELが開けなくなっている.ただし,開発環境のデバッグモードでは問題なく開ける.

何かデバッグ用のコードによって障害を回避しているように思われる.どうもかなりまずい.開発環境ではリリースモードでも再現できない.リリース版を作り直してみた.またインストール前にアンインストールを実行した.もしかすると前回は管理者権限で起動していなかった可能性があるが,それが関係しているような気もする.今度は問題なく走っている.問題は解決している.

気になるのは頻繁に「垂線のゴミ」が散らばっていることだ.爪楊枝をばら撒いたような状況になっている.完了した.

image

どうも早いと思ったが,サンプルが2608本しか入っていない.どうしたのだろう?サイズは2.77GBあるが,確かに本数は2,675しかない.いや,FB1のオリジナルで見てもそんなものだ.記録で見ると2018-10-27で2,603本,所要時間54分12秒だ.ただし,2018-10-14には5,733本をテストしている.テストサンプルは4万7千本くらい,NONサンプルが1万4千本くらいあるが,障害サンプル集は5, 6千本というところだ.

障害サンプル集の所要時間は5時間以上掛かっていた時期もあるが,2018-10-14には5,733本のときでも2時間32分だ.今回は32分59秒なので倍速とまではいかないが,1.6倍速くらいにはなっている.これは主にCPUの能力差だろう.しかし,一番の問題は障害が457本も出ているという点だ.まず,これを見なくてはならない.どうもこれは「非連結」という問題であるように思われる.デバッグモードでは非連結で停止しないので,エラーの所在が分からないが,リリースモードではパネルが表示される.

▲検定2019-01-28\障害サンプル\BUG02-42 14-02-06.ZELを開いて,非連結系列が2件発生する.[系列枠]: #730 odr=8 HM=0 先祖=#518 常陸介(0)[8] 優先=#518 常陸介(0)→#955 常陸介(1) →主系列#702:右大臣(明石)と#738 odr=10 HM=0 先祖=#558 大臣(橋姫)(0)[10] 優先=#558 大臣(橋姫)(0)→#961 大臣(橋姫)(1) →主系列#702:右大臣(明石)だ.いずれも先祖ノードが多重カードになっている.これらは承香殿女御 (朱雀院の)と婚姻関係があるので,BTWで接続できるはずなのだが,成立していない.なぜだろう?

「基準ノードの子ども枠はBTW不可とする」というダンプが出ているので,これだろう.ここでBTWを組むと基準ノードの配偶者が外に出てしまうためだ.つまり,基準ノードの配偶者は必ず基準ノードの近辺に表示するという例外規則が効いているためだ.この現象はやはりN一族家系図の反省からもたらされたものだ.人の図面なら気にならないところが,自分の図面となるとそういう訳にはゆかなくなる.一般には「多重ゼロ・非連結系列ゼロ」という目標は至上命令だが,自分の系図となるとそれでは済まなくなる.

つまり,自分の配偶者が外に結婚を持っていてBTW接合によって自分とはわずか一本の連結線で接続するだけという状態を許容できない.これでは「妻を寝取られてしまった男の残念な家系図」をさらすことになってしまう!これはおそらくわたし個人の感情ではなく,普遍的に言えることではないかと考えられるので,N一族で出てきた「基準ノードの配偶者はBTW接合できない」という例外規則は確立されなくてはならないと考える.

ただし,このような場合であっても,配偶者の外部ポジションが配偶者である場合にはBTW接合によって基準ノードの近接距離に留まることは可能だから,そのような場合を除く必要がある.現在のサンプルはその事例にはならないが,多分N一族ではそのようなシチュエーションが起きていると考えられるので,チェックしてみよう.N氏の場合,配偶者を3人持っているが,そのいずれも外部に別の結婚を持っている.

これらの配偶者の外部婚は単身婚ではなく,有配偶者婚なので上記の条件を満たしている(正確にはうち一つは単身婚だが要すれば配偶者を追加できる).ただし,実際にはこれらの配偶者は外部婚では本人ポジションにあるので,もし上記のような補正を行うとしたら,まずそれら外部婚のポジションを変えなくてはならない.かなり難しい話になってきたような気がする.これに関係するノードはおそらくほとんどがその所属系列の優先ノードになっているはずであり,上記で述べていることから推測しても,単純にポジション変更を行うことは難しいように思われる.

ともかく,ポジションの入れ替えを「結婚枠の取り合い」と解釈して実装してみることにしよう.「基準ノードの子ども枠はBTW不可」とする条件には左右本人の距離も考慮されているが,ここでは距離の問題は無視して考えることにする.条件を挙げてみよう.

  1. 基準ノードの配偶者はつねに基準ノードの近接位置(同一ボックス内)に配置される
  2. 基準ノードの配偶者が外部に有配偶者婚を持っている場合には,その結婚は基準ノードの配偶者の配偶者側で展開される
  3. 基準ノードの結婚は項目2が成立するとき以外にはBTW接合することはできない 
  4. 別の言い方をすれば,基準ノードの配偶者が外部に有配偶者婚を持っている場合にはその結婚の本人ノードを右手本人とするBTWを組むことができる

結婚を夫と妻のどちらで展開するかを決める関数MARGBOX::IsPrimeboxOrNotに上記論理を組み込むのは難しくないが,案じた通りの不良が発生した.先祖ノード不在がTRIBEBOX::GetMajorTribChainで発生している.解決できるだろうか?

「家内婚は左手本人の預かり」という仕様変更が収束しない

午前2時半起床,晴れ.朝食は残りもののうどん.「WordPressへの投稿で xmlrpc.php 403 forbidden エラーが起きる」という問題が起きていたが,解決した.ウェブサーバーの WAF(Web Application Firewall) が効いていたためだ.ロリポップのユーザ専用ページにログインしてセキュリティ→ WAF設定 → ログ参照からシグネーチャを取り出し,WordPressのダッシュボード→ SiteGurd→ WAFチューイングサポート でシグネーチャを設定することで動作するようになった.

一つ問題がある.Open Live Writer のフォルダで全文検索が効かない.ファイルのタイトルに含まれない文字列は検索できない.前にも同様の事象は起きたことがあったが,どう対処したのか?忘れてしまった.Windows Live Writer はインストールされているので,リストアップされたファイルを開くことはできる.⇒エクスプローラの検索→ 詳細オプション→ インデックスが生成されていない場所→ ファイルコンテンツをチェック.これで全文検索ができるようになった.

今度はVSでビルドエラーが出るようになってしまった.管理者権限で起動し直してリビルドしてみる.⇒今度はエラーなしで完了した.タスクマネージャでマカフィーのインスタンスが無数に走っている.リアルタイムスキャンがオンになっていた.止めてから再起動してみたが,変化なしだ.アンインストールした方がよいのではないか?⇒アンインストールした.契約は有効で最初にインストールしたときのメールアカウントで再インストールすることができる.

作業に入る前に始業時バックアップを取っておこう.ipch がまだコピーされている.⇒「つねにフォールバック位置を使用」オプションが落ちていた.リリース版を起こして障害サンプル集のオープンテストを開始した.どうも見たところ,かなり描画上の問題が発生しているように見える.余分な垂線があちこちに出ている.描画上のタイミングの問題ならよいのだが,もしそうでないとしたらどこかで相当デグレードしていることになる.⇒画面がフリーズしてしまった.どこかでハングしている模様だ.

応答なしになっているのは,C:\Users\babalabo\Desktop\障害サンプル集\FB4反例\FB4検定2017-08-10\修復サンプル\太郎君の直系血族図.NONだが,このファイルはアイコンのダブルクリックで問題なく開ける.表示されているのはカード数20点のファイルで基準ノードAA,ズーム倍率100%にしては図面が大き過ぎる.

image

おかしい.VSが起動されなくなってしまった.管理者として起動でなければ開くことは可能だ.開発環境上でリリースモードでオープンテストを開始しただけで例外が発生している.デバッグモードでテストしてみよう.

▲障害サンプル集\FB2反例\FB2反例2018-10-07\BUG18-10-07 17-11.ZELを開いてTRIBEBOX::getPrimeNodeで(!oyalink && Ancestor != Primary)で停止した.障害が起きているのは[系列枠]: #2951 odr=0 先祖=#1882 初代蒲田  (名不詳)(0)[0] 優先=四女武部幸子.昨日導入したTRIBEBOX::GetAlternativePrimeNodeが実行されているので,昨日の修正に関係している可能性もある.

確かに「優先ノードの所属系列不一致」が起きているのは問題の系列だ.ということはGetAlternativePrimeNodeに不備があるという可能性が高い.つまり,11月8日頃の修正がまだ収束していないということだろう.まず,従来論理に戻してこの問題が解けていることを確認しておこう.⇒確かに問題なく描画できる.もう一度,なぜこの措置が必要になったのかを再確認しておこう.これはN一族家系図描画上の問題から来ている.

シンは配偶者を2人持ち,どちらにも子どもがあるが,最初の配偶者の子孫系が左配置されてしまうのを避けるというのがその理由だ.一般に結婚枠はゴールド婚の場合を除き配偶者の直下に配置するようになっているが,家内婚の場合には本人預かりとなり,本人直下に展開することになっている.家内婚の右手本人と左手本人は必ずしも隣接しているとは限らないため,先行ノードの位置で展開するのが流れとしては自然だ.

これを「名義的」には右手本人位置で展開し,「実質的」には左手本人位置に描画するということは可能だろうか?できないことはないようにも思われるが,かなりの修正が必要になってくるような気がする.このような図面ではできればユーザが任意選択できるようにするのがベストソリューションなのかもしれないが,それはまた明後日の話だ.

家内婚はいずれBTWとして処理されることになるのだから,その時点で決定してもよいのではないだろうか?BTW婚の場合には動的に結婚枠を系列を超えて移動するということをやっているはずだ.多分その方がよりスマートな解決になるのではないかという気がするがそれもまた後日ということにして,ここでは既定路線に従って「家内婚は左手本人の預かりとする」という方針で収束させることを考えてみよう.

またおかしくなってきた.WordPress で投稿エラーがぶり返し.その上Chromeの画面までおかしい.画像の右上をクリックすると「このアカウントを削除しますか」というメッセージが出る.

image

Chromeをアンインストールして再インストールで回復した.ただし,「データを保存してアンインストール」では状態が変わらなかったので,一旦「すべて削除」した.WordPressはもう一度シグネーチャを取り直して再設定で投稿できるようになった.

どうも「家内婚は左手本人の預かりとする」という仕様変更に対応するのはかなり難しそうだ.代替の優先ノードを見つければよいのだが条件が整わない.始系列は#2763 odr=0 先祖=#1198 大蔵名不詳(0)[0] 優先=大蔵名不詳.以下のような問題がある.

  1. TRIBELIST::MakeUpTreeで系列優先実ノード不在の非始系列が発生する
  2. TRIBEBOX::getPrimarynodeでは関数中で系列優先ノードが変化する場合があり,この関数を呼び出しているTRIBEBOX::GetRealnodeでフローの混乱が発生する
  3. TRIBEBOX::getPrimeNodeで(!oyalink && Ancestor != Primary)となる場合がある
  4. TRIBEBOX::GetAlternativePrimeNodeで主系列上に実ノードが存在しない場合がある
  5. TRIBEBOX::GetMajorTribeChainで主系列チェーンが途切れる場合があり,これを強制的に延長すると循環が発生する

このような事象を回避するためには主系列参照関係が確立している必要があるが,それを生成している時点では回避操作が成立しない.「家内婚は左手本人預かり」とする処理を組み込むと系列参照関係に影響が及び,それによって回復不能な参照関係の破綻が生じる.つまり,言い換えると系列参照関係木が構築できない状態になる

WordPress の投稿でまた php 403 forbidden エラー

午前3時起床,晴れ.朝食は雑炊の残りとサバ水煮缶.タブレットのディスク容量が逼迫してきたので,Windows.old を丸ごとメインマシンにコピーする深夜作業を仕掛けておいたのだが,止まっていた.タブレット側がスタンバイに入ってしまったためだろう.残り10%くらいだが,あと一時間くらいは掛かりそうだ.タブレットのドライブは32GBしかない.何か外部ストレージを増設するということも考えられるが,当面はメインマシンのEドライブをバックアップ用に使うことで間に合わせておこう.無線ドライブという選択肢もあるが,先送り.

仕掛りの反例サンプルの不具合の原因が2018-11-09に実施した「家内婚は左手本人預かりとする」という仕様変更にあることが分かったので,あとはそれに対処して系列優先ノードの付け替え処理を追加するだけだ.この時点ではまだYリストは生成されていないので,探索はすべてカードリンクベースで行わなくてはならない.まずはルーチンの始業時バックアップから始めよう.

Windowsoldのファイル転送は完了したが,サイズ・ファイル数などがかなり違う.原本が3.94GB,31,909本,3,607フォルダに対し複製は3.87GB,31,841本,3349フォルダでかなり少ない.完全にバックアップできていないということになるのだが,どうしたものだろう?実際問題としてバックアップからシステムを復元するというのは手続き的に難しいと思われるので,このまま進むことにしよう.通知画面で「削除」ボタンを押しただけでは自動的には削除されない.手動で削除しようとすると「このフォルダを変更するにはSYSTEMからアクセス許可を得る必要があります」となって先に進まない.

フォルダの移動はできた.Windows.old フォルダ全体を削除するではなく,その下の階層のフォルダを個別削除するようにしてある程度動き始めたが,ところどころ削除できないファイルが発生する.これらを「スキップ」してほぼ大きな部分を削除することができた.最終的にこのフォルダは完全に削除された.Cドライブの空領域は9.56GB.できれば,これをつねに10GB以上に維持したい…

TRIBEBOX::GetAlternativePrimeNodeという関数を新設して,系列優先仮ノードの切り替えを実施することにした.選別論理はほぼ動作するようになったのであとは結婚リンクを整えるだけになった.以下の2つを決定する必要がある.

  1. MARGLINK *Marglink 主系列に属する優先実ノードの親の結婚リンクへの参照
  2. MARGLINK *Oyalink 従系列に属する優先仮ノードの親の結婚リンクへの参照

!できた!

image

昨日の作図とは微妙に異なる点がある.どこが違うのか見てみよう.大きな相違点は昨日の図ではAB+ACがADの直下にあったのに対し,今日の図ではAE+ACの下に移動しているという点だ.これは結局,この結婚がどこで展開されるか?というところに相違点があると言える.並べて比較してみることにしよう.

image

左が今回の出力つまり「家内婚を左手本人預かり」とした図,右は従来通りの出力図面だ.相違点は左図ではAFの優先ノードがAGとなっているのに対し,右図ではAIになっているという点だ.この図面で「家内婚」と呼ばれているのはAB+AC→AAのことであり,この子ども枠は右図でも左図でも等しくAB+AC直下のゴールド婚になっているので,「右手本人預かり」であるか,「左手本人預かり」であるかは図面には影響していないように見えるのだが…

左右の相違は家内婚には直接関係せず,むしろ「系列分解」の方に影響しているように見える.実際,右図では左辺のノードはほとんどAF系列所属となっているのに,左図ではわずかにAF→ADを確保しているに過ぎない.なぜこのようなところに差異が現れるのだろう?系列分解というのは先行処理であり,一般には系列優先ノードを決定した時点で確定すると考えられるのだが…

この図面を複雑なものにしている要因としては,AB+ACという家内婚の存在だけでなく,ABとAIがともに複数の親を持っているという点にあると考えられる.ABが婿養子,AIも同様の事態が想定されるが,この程度の複雑さは世の中にはざらにある.この問題は一応これで最終解決したものと考えてよいと思われるが,2018-11-09の仕様変更の意味をもう一度考えておこう.

この問題はN一族家系図の補充・整理というフェーズで発生している.この作業はある意味でまだ未完結だ.実際「2018-11-08 N一族系図で問題が多発している」では終わりの方に16項目もの不具合ないし要対処項目がリストアップされている.ログは一旦ここで途切れて次に再開されるのは11月20日だが,このあとは例の「大量メール配信事件」に巻き込まれほとんど仕事になっていない.

現状どうなっているのか?このサンプルを開いてみよう.いや,その前に一度バックアップを取って仮修正をフィックスしておいた方がよい.仮修正は34行ある.かなり古いもの(去年の10月頃)が含まれている.

  1. 「先祖並び自動ではバランス配置方式と単方向移動方式を併用する@20181106」に含まれる→このオプションを現状でフィックス
  2. 「先祖並び自動で直属系列の場合を除く@20181021」に含まれる→このオプションを現状でフィックス
  3. TRIBEBOX::Approximation 出口検査のTRIBEBOX::Approximation ⇒ 現状でフィックス
  4. MakeBugReport GetOSDisplayStringの呼び出し ⇒ 保留
  5. TOPOLOGY::CheckPairList RETRYラベル ⇒ 現状でフィックス
  6. NAMEBOX::GetLeftContact 「長い尻尾の場合はLeftContactMargTreeを使わない@20181023」⇒ 現状でフィックス
  7. COUPLING::InitCoupling 冒頭でinitializeを実行 ⇒ 現状でフィックス
  8. NAMEBOX::setCritical 「異世代多重でチャンネルエラー」⇒ 復活
  9. TRIBEBOX::ChangeBelongingTribe 出口検査:優先仮ノード不在で停止 ⇒ 現状でフィックス
  10. TRIBEBOX::checktribesenzo コメント「@20190124 Yリスト未生成時には人名リンクを参照する」 ⇒ 現状でフィックス
  11. TRIBEBOX::checktribesenzo 先祖仮ノード不在時の措置 ⇒ 現状でフィックス
  12. CARDLINK::markupDownRoute checkmarkの廃止 ⇒ 現状でフィックス
  13. MARGBOX::IsPrimeboxOrNot 「家内婚は左手本人預かりとする@20181108」⇒ 現状でフィックス
  14. NAMEBOX::RetrieveGhost GetYoungerTail呼び出し ⇒ 現状でフィックス
  15. NAMEBOX::UnErasable 「家内婚左手本人は消去不可」⇒ 現状でフィックス
  16. TRIBEBOX::getPrimeNode 始系列で系列優先仮ノード不在は停止する ⇒ 現状でフィックス
  17. TRIBEBOX::getPrimeNode 優先ノードの所属系列不一致のときGetAlternativePrimeNodeを実行する ⇒ 現状でフィックス
  18. BUNSFILE::open 例外発生s時:パネルを出さない ⇒ 現状でフィックス
  19. COUPLING::SerializeHeader 「タイトル履歴サイズ不一致の場合はバッファを廃棄する@20181030」⇒ 現状でフィックス
  20. COUPLING::SerializeHeader 例外処理でエラー復帰する ⇒ 現状でフィックス
  21. MakeUnderwear GetOSDisplayString呼び出し ⇒ 保留
  22. NAMEBOX::getYoungerTail TYW婚不一致のときはつねに停止 ⇒ 現状でフィックス
  23. MARGBOX::ResetTooYoungWife TYW婚でない場合は復帰する ⇒ 現状でフィックス
  24. TRIBEBOX::IsConnected 「系列優先ノード不在が起きることはあり得る@20180903」⇒ 現状でフィックス
  25. TRIBEBOX::DoesMajorTribePathExist GetStartTribeが空で始系列ではない場合がある ⇒ 現状でフィックス
  26. TOPOLOGY::TribeDecomposition デバッグ用ダンプ ⇒ checkで判定する
  27. TRIBELIST::TribeRelocation CheckBrotherCrushを実行しない ⇒ 現状でフィックス
  28. TOPOLOGY::CheckAbsorbMarriage 事後にConfirmGoldenCoupleを実行する ⇒ 現状でフィックス
  29. nodule.h STOPマクロの定義 ⇒ 現状でフィックス

GetOSDisplayStringは保留してあとで見直すこととした.⇒かなり修正したのでもう一度バックアップを取っておこう.N一族では多重カードが出ているが,これは避けられないのだろうか?多分,基準ノードの配偶者は仮ノード消去できないというルールがどこかで導入されているはずだが,多重を極小化することは系図作図上の最優先項目であると思われるのだが…. この図面にはそれ以外にもいろいろありそうだ.「始系列参照パスが途切れている系列」というのが複数出ている.これもかなり問題がある.

おそらく,N一族家系図はゼルコバの木正式版をリリースするための最後の関門になるのではないかという気がする.それほど難しい図面ではないのだが…しかし,これに掛かる前に全般的なバグのクリアランスを片付けておきたい.一応動き始めたところで,一度障害サンプル集のオープンテストを走らせてみることにする.WordPressの書き込みでまたエラーが出始めた.

image

マウスも不調だ.古いマウスの方がまだましな感じだが,マウスホイールが使えない.

「家内婚は左手本人預かりとする」という仕様変更

午後10時起床,晴れ.__asm int 3  が NOP に書き換えられてしまうという問題についてもう少し食い下がってみる.VS 2017 を起動するとき,「管理者権限で起動」しないようにすれば書き換えできないのではないか?と考えてやってみたが効果なかった.昨日のログでは,①バックアップに戻してから,②ipchのフォールバック位置を設定したあとにノーマルな状態に戻っているので,この操作を試してみる.⇒何の効果もない.

STOPに相当する関数__debugbreakを見つけたが,動作はまったく同じだ.つまり,一度ヒットすると0xCCの位置に0x90が書き込まれてしまう.結局#define STOP __asm int 3 とまったく同じ動作になる.これ以上粘っても仕方ないだろう.これを受け入れるしかない.STOPで停止したところに手操作でブレークポイントを設定することにした.

ASSERT_NEVER などの場合はマクロの中にマクロがネストしているので多少厄介だが,ASSERT_NEVERで停止するということはすでにその時点で検定に失敗していることを意味するのだから,動作を反復テストする必要性はないと考えられる.これでようやく腰を据えてデバッグできる.

エラーを無視して走らせるとSUWになり,以下の図面が表示される.

image

上図を見ると,AIはAFの下流に存在しているが,明らかにAFの優先ノードはADでなくてはならないように思われる.優先ノードの設定はTribeDecomposition→ MakeTribeBox で実施されている.この論理が誤っているように思われる.先祖リストに列挙されるノードは以下の5つだ.AM,AN,AF,AE,AO.AIはAM系列に含まれるので,それがAFを先祖とする系列に再登場するという点がおかしい.

いや,それは違う.「結婚」は夫ないし妻のいずれかの「場所」で一度だけ展開されるが,親子関係は必ず「その場所」で展開されるから複数の親を持つ場合には複数の仮ノードが生成されるというのが常態だ.AFからAIに至る経路は2つある.AF→ AD→ AB→ AA→ AIとAF→ AD→ AG→AIだ.AEからAIに至る経路も2つあり,AE→ AB→ AA→ AIとAE→ AC→ AA→ AIだ.

AIは親を二組持っているから,出現は2箇所つまり,AIの仮ノードは2つある.AFはAEよりも先に展開されているから,AFの優先ノードがAIになるというのは誤りではない.従って,AI(1)がAE系列に属するという点に誤りがある.AB+AC→ AAがAF系列で処理されていないのが問題だ.AB+ACは家内婚になっているが,どうもこの辺りで変則的な動作になっているような気がする.確かにそのようだ.ここでは家内婚を遅延処理するような調整が入っているが,それを外すことで簡単に描画できた.

image

確かにどこかで,このような調整を行った記憶はある.「家内婚は左手本人預かりとする」という仕様変更を2018-11-08に実施している.しかし,このような遅延処理が不可能ないし矛盾したものであるとは考えられないので,なぜこの論理が通用しないのかを考えてみよう.系列優先ノードは系列分解フェーズで決定されるが,結婚の展開はそれよりあとのGODOWNSTREAMで実施されているためだ.障害が発生するのはさらにそのあとのMAKEUPTREEフェーズ.現行論理では系列優先ノードの付け替えというのは普通にやっているので,それが適用可能かどうかを見ることにしよう.

EstablishMajorTribeChain はそのようなシチュエーションに適用可能な関数と思われる.いや,この関数はあまり完備したものではない.もう一度一から探し直すような処理が必要だ.IsConnectedでは付け替えができない.IsConnectedを適用するためにはYリストが整備されている必要がある.TRIBEBOX::AlternateTribeRealNodeにも包括的な付け替え論理が入っているが,この場合は優先仮ノードは固定で実ノードの代替品を探すという論理になっている.系列枠オブジェクトの右枝に先祖ノードが配置されていないまったくの空白状態から代替優先ノードを探す論理を一から起こすしかない.

Windows の以前のバージョンを削除しますか?という通知が入っている.ディスクスペースが逼迫しているためだ.タブレットには余分なものは一切置かないようにする必要がある.と言ってもユーザ領域は1GBも使っていない.Windows.oldをバックアップして潰すしかないだろう.約4GBだ.