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右手婚とすべきではない.

“AFTERMARGSAMEGENEフェーズではBTWを仮ノード消去に先行” への2件の返信

  1. 毎日ご苦労様です。
    貴殿の努力に感謝し粗品を送らせていただきます。 2/10日 16:00ー18:00
    ご健闘をお祈りします。

    1. 届きました!思いもしなかったギフトありがとうございました.落とし穴にハマった状態から抜けられず,もしかしてわたしももうこれで終わりなのじゃないだろうか?などという考えまで浮かんで来たり… その辺りをうすうす察しておられたのかと思いますが,このサプライズは効きましたよ!まぁ,わたしは DIE HARD なのでまた,HELLBENT に匍匐前進したいと思います.(つい最近英語の学習を再開したので覚えたての語彙を使ってみました…)

コメントを残す

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

CAPTCHA