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

午前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で発生している.解決できるだろうか?

コメントを残す

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

CAPTCHA