基準ノードの配偶者で多重が起きる問題

午前11時起床,曇り.朝食はネギ入りとんこつラーメン,ほうれん草と青菜のお浸し.結局ステファニーの Connect & Communicate コースを取ることにした.コースは12週で$497のところ,$397.分割すると150ドルx3回になる.通常割賦では200ドルx3なので150ドルの節約だ.ディスカウントの締め切りが迫っていたので急遽決断した.English Full:Time 24/7 のコースは10コースあるが,短いクリップの寄せ集めなので1日1コースは履修可能に思われる.

Connect & Communicate コースの方は週に一度の配信なのでダブルブッキングでもこなせると判断した.と言っても C & C コースにもすでに相当量の既存教材が蓄積されているので,うかうかすると仕事しているヒマがなくなってしまうかもしれない.今日はともかく打ち切って仕事に入ることにしたのだが… ネットで遊んでいるといくら時間があっても足りなくなる.昨日の続きに戻ろう.

現状における問題点はAAが多重になってしまっているという点だ.AA(0)は基準ノードの配偶者だが,このノードは可視で正しい位置に配置されている.AAの仮ノードは現在以下のような状態になっている.

  1. (0) 基準ノードの配偶者,可視の左手本人
  2. (1) 可視の本人ノード
  3. (2) 可視の配偶者ノード
  4. (3) 配偶者ノード 不可視の右手婚配偶者

問題は(1)の本人ノードと(2)の配偶者ノードだ.(1)は仮ノード消去されなくてはならないので,そうなっていない理由を調べる必要がある. (2)では(3)のケースと同様に(0)とBTWを組まなくてはならないのにそうなっていない理由を調べる必要がある.まず,(1)から見てみよう.おかしい.動作が変わってしまった.どこか壊してしまったのだろうか?見当が付かないので一旦バックアップに戻ろう.いや,バックアップに戻しても同じ障害が起きる.

エラーが起きているのはIsMukoYoshiだが,このエラーはNAMEBOX::UnErasableでcheckをオンにしただけで起きるようになる.どうも検査用コードで実動作が起きているようだ.checkブロックでIsMukoYoshiを実行している.この関数は「家内婚の左手本人であるか否かを判定」するためのものだ.対象ノードは#731AE(1).この関数は拡張枠全体を検査している.結婚枠の中に対象ノードを配偶者とするノードが存在する場合には「家内婚」と認定し,さらに検査を行う.

対象ノードはBTW右手本人属性と左手本人属性を持っている.これに対し例外が起きているノードはBTW右手本人だ.家内婚はBTWとして処理されているはずだから,対象ノードが左手本人,障害ノードが右手本人という関係になっているものと推定される.家内婚左手本人とは結婚枠の中で下流に位置するノードと定義されているはずだが,現行では多分家内婚は左手本人預かりとなっているはずだ.「家内婚は左手本人預かりとする@20190126」というオプションはオンだ.

この関数の論理ではBTW右手本人を家内婚左手本人としているように思われる.これでよいのかどうかは別途調べる必要があるが,今の場合は候補ノードはBTW右手本人なので家内婚左手本人と断定しようとしているようだ.IsValidNameBoxではBTW右手本人をIsValidNameBoxで取り出そうとしているが明らかに誤っている.このノードはBTW右手配偶者なのだから当然不可視で空の状態になっている.⇒IsValidNameBoxに代えてIsNameBoxAppearを使うようにした.これでcheckブロック内の障害は片付いた.

NAMEBOX::CheckUnerasableには「本人カードがこのノードだけで同世代の配偶者ノードが2つ以上ある場合は消去不可 @@2017-02-27」という判定条件が入っている.現行では原理的に配偶者多重を防止するようになっているはずだから,このロジックは不用と思われる.この条件変更は「左手枠配偶者を左手本人とするBTW拡張@20190130」によると考えて間違いないだろうか?多分それでよいはずだ.これで問題の一つは片付いた.

多重も2枚だけになった.これは仮ノード消去の参照先としてAA(2)が選択されているためと考えられる.ここではやはり,基準ノードの配偶者を特殊扱いするための属性を与えておくことにしよう.これは「基準ノードの配偶者」というだけでよいのだろうか?だとすれば属性ではなく特性関数でもよいような気はするのだが… 2月10日のログ「基準ノードの配偶者が枠外に出てしまう問題」で「検査関数」を導入するとしているのがそれに当たる.実装したかどうかやや不明だが,作ってしまった方が早いかもしれない.

IsBaseNodeSpouseとHasBaseNodeSpouseという2つの関数が作られているので使うことにしよう.これらの関数は実装されてはいるが使われていない.HasBaseNodeSpouseは「同名仮ノードのうちに基準ノードの配偶者が含まれているか否かを判定し,基準ノードの直近配偶者を返す」という関数だ.NAMEBOX::IsPossibleRealnodeで使ってみることにしよう.

NAMEBOX::DoublyBlessedOneの中でChangeRealRefferenceを使ってノード対の付け替えを実施している.暫定的に止めることでAA(0)を参照できるようになった.ただし,参照実ノードが2つ発生しているところから見てChangeRealRefferenceには何か不良があるように思われるので一度元に戻して調べて見ることにする.

中断地点から作業を再開する

午前10時起床,晴れ.朝食は納豆うどん.フェースブックではメーセージ交換が始まると相手のアイコンが画面上に表示されるようになる.そのことを知らなかったので昨日は知り合ったばかりのとびきりの美人から「いい加減にしてよ,一晩中寝かさないつもりなの?」と怒られてしまった.結局指を2本使ってアイコンを消す方法が見つかったのだが… まだ怒っているだろうか?

開発環境を立ち上げたら,Visual Studio の無料試用期間が完了したという表示が出ている.mmm… すっかり払い込み済と思っていたが,まだ入金していなかったかもしれない.これは多分マイクロソフト本社の直販と思われるが,確かに外国送金した記憶はない.楽天カードでは送金していないし,そのあとのデビッドカードを作ったのはつい最近でステファイーのコースの10ドルくらいしか送っていない.

マイクロソフトアカウント自体が無効になっているのでまずこれを有効化するところから始めなくてはならない.マイクロソフトアカウントは多重認証になっていたような気がするが,スマホのAuthenticator は捨ててしまった.どうもうまくゆかない.このアカウントを削除してしまった方が早いのではないだろうか?いや,もしかすると少し早まってしまったかもしれない.そもそもインターネットに接続していなかった.

メールアカウントは活きていた.アカウントは活きていたが,メールの受信にやけに時間が掛かる.どうしたのだろう?outlook.jpのメールはクラウド上にあると考えられるが,同期が取れていないようだ.ライセンスは更新できた.どうやって送金したのだろう?楽天カードはすでに失効していたはずなのだが… 完全にボケている!Visual Studio 2017 はとっくに無料化されていたのをころっと忘れていた.

スマホで「Messengerが電力を消費中」というメッセージが出る.これは昨日「アイコンが消えない」という騒動が起きてからだ.今日はアイコンはまったく出ていないのだが…いや,出ている.English Vocabulary だ.このアプリは一旦止めておいたのだが… 今日の出題は「onomatopoeia の同義語はどちらか?」というものだ.やはり,止めておくことにしよう.

一番最後の反例は BUG19-01-27 06-56-47.NON と思われるのでここから再開することにしよう.現状の論理は仕掛りになっているが,そのまま走らせるとSUWが発生する.さて,どうしたものだろう?一度修正前の版に戻った方が早いような気もするのだが…. ともかく,もう少し追いかけてみることにする.MoveWedlock で例外が発生している.SUWをスローしているのはGetUpperNodeだ.「親ノードが親パス上にない」というエラーが発生している.

続行して描画は可能だが,かなり崩れている.やはり一度バックアップに戻った方がよさそうな気がする.かなり問題だ.ZELKOVA2019_2019-02-10では同じ位置で例外が発生する.その前の版と言えばZELKOVA2019_2019-02-7しかない.とりあえずこれを使ってみよう.この版なら開ける.ログと突き合わせてみよう.日付から見て2月6日の修正は完全に入っているものと思われるが…

2月6日の最終修正の反例は反例2019-01-28\BUG19-01-27 06-56-47.ZELだ.開くことはできた.ただし,一箇所検査で停止するところがある.どうもこの部分は未解決のまま進んでしまったような形跡がある.TribeRelocationで「BetweenTwoWomenを先行実行する@20190206」という修正は入っている.IsAliveの「削除ノードがShadowedの場合にはLIFEは空にならない@20190206」という修正も入っている.この修正を入れた時点でバックアップを取っているのが,この版ではないか?

ここから先はもう一度デバッグし直すしかないようだ.IsPossibleBTWLeftHandでightwife->IsLeftHandBoxのときゼロ復帰すると多重が発生する.これはログの記述通りだ.従ってこのエラーは無視してよいと思われるがそれを正当化できるだろうか?つまり「左手枠配偶者を左手本人とするBTW拡張@20190130の場合はBTW右手配偶者が左手本人となる場合があり得る」ということなのだが… もう一箇所停止するところがある.

TRIBEBOX::SetMinorTribeで (primary->getrelation() == REL_SPOUSE) という理由で停止している.これは「系列優先仮オードの関係属性が不正」というエラーだ.この系列の接合タイプは「PRIME_BTWLEFT,  BTW左接続関係:両手に花左手本人→右手本人」となっている.これは置いてあとで見ることにする.出力図面で見るとMN(0)は配偶者ノードだが,右手婚配偶者属性と左手本人属性の両方を持っている.実際の図面を見てみることにしよう.

このサンプルを無名化したものが上のNONファイルなので以下ではNONファイルを使って解析することにする.AAは(0)~(3)の4つの仮ノードを持っている.AA(0)は不可視の配偶者ノードで右手婚配偶者と左手本人の属性を持っている.(1)は不可視の消去された仮ノード,(2)は可視の配偶者ノードで左手本人,(3)は不可視の配偶者ノードで右手婚配偶者属性を持っている.

image

  1. (0) 不可視の配偶者ノード 右手婚配偶者+(3)の左手本人
  2. (1) 不可視の消去された仮ノード
  3. (2) 可視の配偶者ノード (1)の実ノード,(0)の左手本人
  4. (3) 不可視の配偶者ノード 右手婚配偶者

この図面は多重は存在しないが,いくつか問題がある.①左手本人が不可視になっている,②基準ノードの配偶者が不可視になっている,右手婚配偶者かつ左手本人というのは矛盾がある.これらの矛盾はすべて(0)に集中していると言える.上の停止箇所と突き合わせてみよう.以下の2点だ.

  • rightwife->IsLeftHandBox 右手婚配偶者=左手本人
  • primary->getrelation == REL_SPOUSE 系列優先仮ノード=配偶者

最初の項目は規定通りエラーとしなくてはならないだろう.2番目の項目はこの系列がBTW左接続関係となっているためだが,まずこの系列を特定しておこう.[系列枠]: #541 odr=7 HM=1 先祖=#341 CS(0)[7] 優先=#737 AA(2)→#201 AA(0) →主系列#501:CLだ.この参照は左手本人から右手配偶者に向かうためBTW左接続関係とされる.しかし,「左手枠配偶者を左手本人とするBTW拡張」では配偶者が左手本人となる場合があるのでこれは合法だ.これでようやくスタート地点に戻ったのではないだろうか?

仕掛りの論理では「右手婚配偶者=左手本人」を無視して処理を続行した結果一応多重のない図面が得られてるが,やはり問題があると言えるだろう.今日は仕事再開の初日なのでこの程度で眠ることにしよう.おまけ:

Natalya VinogradovaYour left hand amuses yourself fingering your long hairs while your right hand that holds a pencil is writing something on the notebook on the upper side of your thighs.

とびきりの美人とお友だちになってしまった

午前9時半起床,朝食はtamo2さんから送られてきた「即席鹿児島ラーメン亭 とんこつ味」をネギだくで頂く.タブレットはまだ長机上にあるが,そろそろ仕事に戻ることにしよう.ここに来てフェイスブックの「友達」が一挙に11人に増えた.いや,実際はもっと多いような気もするのだがリストでは11人となっている.ほとんどはステファニーの The Fluency Breakthrough 24-Hour Challenge で知り合った仲間だ.

昨日のログでは「10ドルで提供するというディスカウント」と書いているが間違っていた.実際には正価の497ドルから100ドルディスカウントだったが,延長されて3月3日締切ということになったようだ.フェイスブックでチャットした仲間もまだ決めかねているようで3月3日までに決めると言っていたが,わたしはすでに1ヶ月10ドルの English 24/7 というコースに払い込んでいるのでしばらくはこれを続けるつもりだ.

全10コースで1日1コースづつ片付ければ10日でクリアできそうだが,何回か反復トレーニングする必要があるので最低1ヶ月はかかりそうだ.会話練習はやろうと思えば知り合った仲間とボイスチャットすることも不可能ではない.ひょっとして数ヶ月後には英語がペラペラになっている可能性はゼロではないが,おそらくそのときには日本語をすっかり忘れているのではないかと思う.

とびきりの美人とお友だちになったよ.

Karina Akhtyamova

「今日はもう眠れない」と言ったら,「なんで?」と尋ねるので「いや~それは(君には)言えない」と答えておいた.いや,最後に「Oyasumi」と言ってくれたので「これでぐっすり眠れる」って言えたけど… ちなみに彼女は日本に何度も来たことがあるそうで,かなりの日本びいきだ.わたしの生涯で出会った最高の美人かも…

さて,そろそろタブレットを仕事机に戻すことにしよう.(英語学習を含めて)遊びと仕事を切り離さなくてはならないが,English 24/7 はヒヤリングだけでは少し無理でどうしてもテキストを見ながらということになる.これをスマホでできるだろうか?問題なさそうだ.問題は外に持ち出したときスマホの画面がほとんど読めないという点だが,ウォーキングのときは何かヒヤリングに適した教材を選べばよいだろう.

最大の問題はいかにネットアクセスのトータル時間を削減するか?だ.朝のメールチェックで約1時間(これには配信されたニュースのチェックも含まれる),ウォーキングが30分~(歩行中のヒアリングトレーニングを含む),ウォーキングに出る前に朝食を摂らなくてはならない.パン食や麺なら20分程度,皿洗いは10分で済むとしても調理となれば1時間は掛かる.ワイアレスイヤホンで調理しながらヒヤリングというのは可能だから英語学習は「ながら」でやるしかないかもしれない.となると,メールチェックは食卓についてからということになる.これしかないのではないだろうか?

Y!パートナーはもう打ち切ってもよいかもね.「みんなの近況」というのは結構読ませるので毎日チェックしてた.一度だけマッチングしたけど相手は28歳!さくらでないとしたら,ミスクリックとしか考えられない.入会早々数百人から「いいね」をもらっているというのだから,単純に「あり得ない話」だ.大体ここは50代前ならほぼセフレ探し,それ以上なら真剣に結婚相手探しと見て概ね間違いないと思われるけど,結婚相手の条件は少なくとも「経済的に安定していること」だからね.素敵なガールフレンドもできたことだし,この際後腐れのないようにアプリを廃棄しておこう.実際言ってわたしは「有料会員」になるつもりはなかったし.

回転性めまいの渦から生還する

午前9時起床,晴れ.青菜入りうどん.2週間ログの更新が止まっている.ログが止まっているということは仕事をまったくしていないことを意味する.実際この間わたしは完全に仕事机から離れていた.このログも仕事机ではなく食卓兼作業用長机上のタブレットで書いている.タブレットはもっぱらログ編集用に使っているので本来は仕事机上でメインスクリーンの左手に配置されているはずのもの.タブレットはバッテリを内蔵しているので移動は可能だが,なんと別にコンセントを取って長机に常駐しようという構えだ.

mmm… なんでこんなことになっているのか?一言で言えば「スマホにハマっていた」ということになる.それをご説明する前に一つ短いビデオクリップを見て頂くことにしよう.WARNING: This video may contain graphic content for some users. ダメだ!残念ながら「このサイトのアップロードサイズ上限を超えています」になってしまった.

https://www.facebook.com/age.baba.5/videos/1446041038865024/?t=0

https://www.facebook.com/groups/631880437256393/

Facebook にはアップロードできるが,連日ルータの転送量上限の「3日で10GB」を超えているためムチャ遅くなっている.残り17分となっているが,数字の5倍くらい掛かっているので終わるまでにはあと1時間くらい掛かりそうだ.確か午前2時を過ぎると通常のスピードに戻るはずだが…. 終わった.

https://www.facebook.com/age.baba.5?fref=nf&__tn__=%2Cdm*F-R&eid=ARA1h-KUQxT4pWEwoX4PcRMYpcFHz9DK29S77M2Txcypqlh6cU1kXZiL5n8zuoGirBVdbhktublNkD4F

ある朝気が付くとどうも頭がふらふらしている.しかし,それも一過性ですぐに納まったのでその日は普通に暮らしたが,翌日トイレで便器の前に立った瞬間いきなり回りの壁がものすごい勢いで回転し始めた.エドガー・アラン・ポーの大渦巻きに巻き込まれたようなというのは誇張ではない.そのまま気を失ってしまうのではないかと思ったが,息を止めることで渦も納まった.

不安になって姉に電話しようと思ったが,そのうち忘れてしまった.酸素不足かも知れないと思ったので,戸口を全開して空気を入れ換えた.今年は例年の冬囲い(梱包材のぷちぷちで窓を覆っている)に加えて,着る毛布などをカーテンレールから垂らして二重・三重に保温しているのでほぼ密封状態になっている.(窓ガラス/ぷちぷち/カーテン/レースカーテン/着る毛布・ポンチョ)

血中の酸素濃度が低下してくると酸欠状態になる.ネットで「酸欠」を検索すると最初に「肺気腫」というのが出て来た.前に心電図を2回取っているのでわたしの肺が「肺気腫」寸前の状態になっていることに関しては異論はない.隣家の旦那さんが「肺気腫」で救急車で搬送され,その後自宅療養で「酸素吸入器」を使うようになったという事例も見聞きしている.どうもこれではあと一年だな?という気がしてきた.いよいよタバコを止めるしかないのだが,カートンで買ったばかりだ.しかも,タバコが切れたと思ったのは早とちりでまだ2箱も残っていた.

その翌日は月曜日で姉の食材配給日なので18日ということになる.姉からも「酸素不足じゃないの?」と言われたので「完全な換気」を試みた.まだ冬囲いを解くには早過ぎるので,窓ガラスのカギの部分だけカッターナイフで切り開き窓をこじ開けて10センチくらいの隙間を作り,ドアも全開して空気が部屋を通り抜けるようにした.

その翌日,今度は布団の中で頭を動かしただけでめまいを感じるようになった.窓を覆っていた毛布・ポンチョを取り外し窓を全面開放する.ネットでもう一度検索してみると,これは「回転性めまい」というものであり,朝起き抜けにしか起きないという症状から推定して「良性発作性頭位めまい症」というものだということがほぼ確定した.これは内耳前庭にある耳石のかけらが剥がれて三半規管のリンパ中に混入したという状態だ.

脳に障害がある場合には「悪性発作性頭位めまい症」ということになるのだが,いまのところそのような兆候はないので「良性」としてよいと思う.耳石の移動は内耳の奥で起きていることなので特にこれと言った治療法はない.医師は頭を回転させて耳石を安定な場所に移動するといった施術を行う.自分で直す方法も開発されてはいるが,「良性発作性頭位めまい症」は2週間程度で収まるとされているのでしばらく放置することにした.

いずれにしても命に別状はなさそうだということが分かったので,タバコも普通に吸っている.めまいが始まった時期とワイヤレスイヤホンを使い始めた時期がほぼ一致しているのでそれが直接の原因となっている可能性はかなり高いように思われる.特に夜寝ながら映画を見るというのが効いているような気がする.夜更かしして朝寝坊,昼間に疲れて一旦寝床に入ることもあり,結果的に睡眠時間が多くなっているので,低血圧→貧血という流れも考えられたのでレバーを買ってきて鉄分を補給した.しかし,一番問題なのはこの冬ほとんど外出せず,室内での運動もほとんどやっていなかったことではないかと思う.

image

タバコをカートンで買うようになったので20日に一度しか外出しない.以前は2日に一度はタバコを買うために外に出ていたのでほとんど運動量ゼロというのに等しい.ウォーキングは回転性めまいが発生した日から再開しているが数日で効果が出てきた.まだ起きたときにわずかながらふらっとした感じは残っているが,ほぼ解消したと言える状況だ.

ウォーキングするときにはスマホを持ち出してリスニング力を付けるために英語ビデオをイヤホーンで流す.ネット上には無料で視聴できる英語学習用教材が山のようにあるが,ステファニーのフェースブックイベント「The Fluency Breakthrough: 24-HOUR CHALLENGE」に参加したあと,$10/monthの English Full:Time English 24/7 を購読することにした.English 24/7は10コース分の教材が含まれているが,自由にダウンロードできるので全部ダウンロードしてしまえば,あとはオフラインで自習することもできる.

ステファニーの English Full:Time には Connect & Communicate というコースもあり,ここでは学習者がパートナーを選んでビデオチャットすることもできるが,12週で497ドルも掛かるので参加はしばらく見合わせることにする.上記「The Fluency Breakthrough: 24-HOUR CHALLENGE」は無料だが,自撮りのビデオをアップロードする課題を課されるというかなりスリリングなイベントだった.このイベントの直前には Connect & Communicate を10ドルで提供するという3日間限りのディスカウントもやっていたが,デビッドカードが使える銀行口座が残高ゼロの状態だったため時機を逸した.

体感的には 仕事 > ログの記録 > 英会話演習 くらいの負荷なので,まず十分なポテンシャルが戻ってきたような気がする.

tamo2氏からホワイトオーク樽で三年の古酒「神の河」が届く

午前9時起床,晴れ.朝食は7分玄米食,大根の煮付け,おろし大根,大根と油揚げの味噌汁.今日はうどんの残が1個になったので久しぶりにご飯を炊いた.食事中にtamo2さんからのゆうパックが届いた.写真を撮ったのでグーグルドライブをインストールして開こうとしたのだが,うまくゆかない.Backup and Sync from Google というアプリはインストールされている.ウェブ上ではGoogleドライブが使えるのでこちらからダウンロードすることにしよう.

IMG_20190210_174014

喉が乾いていたのでお礼も言わないうちに蜜柑を一つ食べてしまった.外皮は固くて剝きづらかったが中身は驚くほど甘い.キャラメルの箱くらいの「ボンタン飴」が入っている.懐かしい.渋谷時代の仲間の一人ニーナが鹿児島出身だったので,この飴は昔もらって食べたことがある.「げたんは」という真っ黒で三角形の黒糖菓子.お茶を淹れて一つ摘んだが,二つ三つと全部食べてしまいそうになったので箱を閉じた.麦焼酎の古酒がある.「神の河」と書いて「カンノコ」と読むらしい.何気に神々しい雰囲気だ.

これは開けるしかないかな?今日は早寝して明日から真面目に仕事することにしよう.

基準ノードの配偶者が枠外に出てしまう問題

午前5時起床,晴れ.朝食は茹でうどんに納豆と大根おろし.BUG19-01-27 06-56-47.NONで基準ノードの配偶者が枠外に出てしまう問題を追いかけてみよう.「左手枠配偶者を左手本人とするBTW拡張@20190130」は「配偶者多重」を解消する奥の手だが裏目に出ている.基準ノードの配偶者の仮ノードは直近の一枚を除いてすべて消去されなくてはならない.例外はこのノードが単親婚を持っている場合だけだ.この場合,基準ノード直近の配偶者は上記の意味での「左手枠配偶者を左手本人とするBTW拡張」としなくてはならない.

AA(2)が「配偶者左手本人」になっているのは明らかに誤りだが,どうすればこれを防止できるか?配偶者の仮ノードは複数あり,そのうちのどのカードを「配偶者左手本人」に指名するか?が問題だ.同名ノードの中に基準ノードの直近配偶者がいる場合にはこれを最優先すべきであるのは当然だ.判定を容易に行うためには,「基準ノードの直近配偶者」という属性を保持させるのが分かり易いが,これは後付けで実施することにして,とりあえず検査関数を導入しておこう.

いや,それ以前の問題だ.IfBTWPossibleの入口でGetSegmentTopで弾かれている.これを暫定的に止めて走らせてみるとAA(0)はきっちり基準ノード直近に配置されている.CR(0)+AA(0)という結婚枠は2つある.この結婚枠はすでにZTYWになっている.配偶者AAのBTWが掛かってくるタイミングが遅過ぎる.ステージ【5.2】重婚同類グラフ検定の事後処理を行なうで処理されていなくてはならないのだが… TRIBEBOX::BetweenTwoWomenで配偶者を排除しているためだ.しかし,ここで処理すると図面が完全に壊れてしまう.

このフェーズでは従来通り配偶者は不可としておくしかないように思われる.ZTYWはメインループのステージ【7.2】MPLCで実行している.BTWに掛かるのはステージ【7.9】ですでに手遅れだ.しかし,これはGetSegmentTopの判定が悪いのではないだろうか?いや,それ以前の問題だ.NAMEBOX::FindDoublyBlessedOneで取り出している結婚枠に問題がある.ZTYWではなく「ZTYW本人を参照する仮ノードが存在する元の親枠」を取り上げている.この結婚枠はgetmargboxで取り出されているが,AA(2)にリンクされている結婚リンクの参照する結婚枠はこの親枠になっている.

getmargboxを補正する動作をFindDoublyBlessedOneに組み込んでIfBTWPossible→ GetSegmentTopはパスできるようになったが,HaveSingleFatherBoxが真を返している.HaveSingleFatherBoxでは子どものいる子ども枠を持っている場合には真を返している.

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