昨日の続信
|
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」