午後3時半起床，曇り．朝食は油揚げ入り卵うどん．昨日は業スーで買い出ししてきたので卵や牛乳など「高栄養食品」がふんだんにある．百合が180円という特価で売っていたので，この部屋には似合わないかもと思いながら買ってきた．大輪でもしかしたら「蘭」と呼ぶべきなのかもしれないが，百合と蘭の違いが分からない．今日は散歩の帰りにダイソーに回って歯磨きなどを購入．ともかく朝食を食べてからウォーキングという流れだけは確立できたように思われるが，スマホのアクセス時間は短縮されていない．

今日もまたYoutubeで長いクリップを見てしまった．英語教材は通常は5分～15分，ウォーキングに出るときはそれらを何本かまとめて30分～1時間くらいのストリームに仕立てているのでほぼコントロールできているのではないかと思われるのだが，やはり曲者は「長時間ビデオ」ではないだろうか？今日は長いビデオは1本しか見ていないはずだが，トータルでは10時間くらいになってしまっている．長いビデオは「後で見る」ことにして今後は週末にまとめて見ることにしよう．まぁ，過ぎてしまった時間は取り戻せないのでともかく仕事に入ろう．

サンプルは依然として反例2019-02-26\BUG19-01-27 06-56-47.NONだ．この図面はエラーは出ていないが，いろいろおかしいところがある．一番問題なのは重婚同類グラフが循環していないのに非連結系列が発生しているという点だ．非連結系列は8つある．このうちＣＵ系列だけはPRIME_MARITALタイプだが，それ以外はすべてPRIME_PARENTタイプだ．ただし，優先仮ノードと実ノードが同名になっているのはＤＮ系列だけでそれ以外はすべて別ノードと接合している．これはかなり疑問だ．[系列枠]: #521 odr=6 HM=0 先祖=#223 ＡＬ(0)[6] 優先=#736 ＡＪ(1)→#203 ＡＢ(0) →主系列#509:ＡＩのケースを見てみよう．

ＡＪは親を一組しか持たないのでPRIME_PARENTは明らかに誤っているように思われる．しかし，結婚も一つしか持っていない．配偶者はＡＢだ．ＡＢもＡＪとの結婚しか持っていないが，この結婚はＡＢの預かりとなっている．従って，ＡＪは仮ノード消去されなくてはならないのだがそうなっていない．理由を探ってみよう．仮ノード消去はNAMEBOX::EraseGhostNameで処理されているが，この関数では本人ノード→本人ノードのケースしか処理されていない．いや，それは間違いだ．NAMEBOX::IsPossibleRealnodeで実ノード側が弾かれている．理由は

!hidden() && getvisible() && (getmarglink() || getrelation() == REL_ROOTS) && !empty && !getghostbits(DUMMYBOX|EXTRACTDUMMY)

でないためだ．このノードは不可視になっている．かなり疑問だ．どこで不可視になっているのかSWOで探索してみることにしよう．いや，この関係は先行してBTWで処理されているようだ．確かにBTWを先行させるような論理変更が実施されている．ＡＪ(0)はDOUBLYBLESSED｜BTWRIGHTSPOUSE属性を持っているが，(1)はBTW属性を何も持っていない．これはかなりおかしい．ＡＪもＡＢも結婚を一つしか持っていないのだから，ＡＪ(0)が左手本人かつ右手配偶者となることはあり得ないと考えられる．

現行では配偶者が左手本人となることを認めているが，それには条件があったはずだ．このBTWはＡＪ(0)が左手本人となる構成で成立している．仮にそれで良いとしてもそうであるとすれば右手婚が誤っている．NAMEBOX::IfBTWPossibleでこのようなケースを弾くようにした．これで問題は解決したようだ．

非連結系列は解消し多重も発生していない．このバージョンを少し走らせてみよう．とりあえず，反例2019-02-26の4本は通った．反例2019-02-02の21本も通った．反例2019-01-28の19本も通った．反例2018-11-09にはまだ解けていないサンプルがある．どこかで無限ループしている．仮検定用サンプル\反例2018-11-09\BUG18-10-30 22-50-03.ZELと思われる．

▲仮検定用サンプル\反例2018-11-09\BUG18-10-30 22-50-03.ZELで無限ループが発生する．MPLCでレッドラインオーバーが起きている．天皇家の派生ファイルで基準ノードは＠23 大山守皇子．どうもこのサンプルは相当加工が入っているようなので一旦無名化してから解析することにする．基準ノードのＡＷは結婚を1つしか持っていないが，その配偶者のＮＢが複数の結婚を持っていることが問題を複雑なものにしているように思われる．また，家内婚が5つも発生していることも撹乱要因になっている可能性がある．

SUWは可能だが図面はほとんど壊れていて，全体を見ることができない状態になっているが，TRIBEBOX::CheckMargBoxChangedでスラッシングが起きているようだ．障害はTribeRelocationのステージ【５.２】重婚同類グラフ検定の事後処理を行なうの出口で起きている．不良動作に関わる結婚枠は4つある．いや，もっともっと広範で複雑な動作になっている．最終的には大量の不可視結婚枠で「不可視ノード移動」が発生するようになる．

これを暫定的に止めると最終的に3つないし4つの結婚枠で「不可視枠を移動」ないし「結婚点を一致」が起こるようになる．「結婚点を一致」が起きているのは[結婚枠]:#543：#659 ＣＤ(0)＋#1427 ＱＹ(0)→#4233 ＣＳ(2) だが，「不可視枠を移動」を暫定的に停止すると[結婚枠]:#4469：#1247 ＮＬ(0)＋→#1249 ＮＭ(0)で「TYW枠の移動」が発生するようになる．「TYW枠の移動」を止めると今度は4つの結婚枠で「ゴールデンペア」が発生するようになる．

CRUSHCOUNTOVERした結婚枠をすべて排除すると描画まで進むことができるが，多重が5件発生する．これらの多重は世代的にかなり離れた位置で起きている．どうもかなり手に負えない状態になっているように思われる．図面はかなりの改変を受けているように思われるが，全体図を見ると骨格には変化がないようにも思われるので，おそらく改変があったとして局所的なものに留まるように思われる．従って，この図面はどうあっても仕上げられなくてはならない．仮修正する前にバックアップを取っておくべきだった…

今日のところはこれ以上手を付けずに明日に回すことにしよう．

午後4時起床，雨のち曇り．朝食は最後のおせちを水団仕立てにして片付けた．日付けはすでに0時を回って8日になっているが，起床時刻，ログの日付けとバックアップファイル名を統一するというルールに従って，3月7日としておくことにする．当月10日わたしの誕生日は姉夫婦と外食することになっていたのだが，ご亭主の休みが取れなくなってお流れ．2,3日雨模様の日が続いたが，開けたようなので散歩に出た．

今日も8時間くらいネットにアクセスしている．英語音声が聴き取れるようになってきたのでついついあれもこれもと聞いてしまう．ニュースフィードの流入を一部制限するようにしたので，もう少し時間短縮できてもよいはずなのだが，5分，10分のビデオでは短か過ぎて物足りなくなっているため，ついつい長いビデオを聴いてしまう．

ネットアクセスは上限3時間と決めてみたがどうも実態に合わない．すぐ超過してしまうし一度超過してしまうと歯止めが崩れてずるずると止まらなくなってしまう．明日からはむしろ，もう少し現実的に4時間ということにしてみよう．この四時間には朝食とウォーキングが含まれる．朝食はパンないしうどんに限定するということに決める．八枚切り食パンで4食，うどんが3玉で3食とすればきっちり一週間だ．正月のおせちも片付いたし，うどんの滞貨も完全に一掃されたので，今後はきちんとした献立で3食食べられるようになるかもしれない．

この四時間のウォームアップのあと，仕事にストレートに入れるのか？それともその前に昼食が入ることになるのか？はまだ未定だ．時間配分から考えると2時間くらい仕事して切りのよいところで昼食というのがベストという気もする．仕事の取っ掛かりではまず，始業時バックアップを取ってから前日のログの校正が入るので最少でも30分の予備的な作業がある．やはり，この辺りを片付けてその日の仕事の方向性が固まった時点で昼食というのがよいのではないかと思う．調理は必ずしも毎日ではないが，皿洗いは毎日やらなくてはならない．パン食の場合はほとんど食器を使わないので皿洗いをやっている時間がないかもしれないが，その辺りはフレキシブルでよいのではないだろうか？

朝のウォームアップに要する四時間を「朝練」と呼ぶことにしよう．これをそっくり差し引いて正味の仕事時間はどのくらい残るだろう？これまでのパターンでの仕事時間を仮に12時間とすると，今後は8時間くらい仕事ができればよしとするしかないのではないだろうか？去年の今頃はまだ30キロの米袋を担いて部屋を往復したり，チンしている間に軽い筋トレをやったり，部屋の中をぐるぐる歩るき回る「歩行瞑想」の時間などもあったのだが，今年は100%座りきりなので肩の筋肉だけでなく，足腰の筋肉も完全に落ちてしまった．まぁ，毎日歩いていれば足の筋肉は戻ってくるし，食べていればどうしても運動したくなるので上記のようなタイムテーブルが確立すればなんとかなるのではないかと思う．ともかく，この状態から一刻も早く「脱出」しなくてはならない．

おかしい．どこか壊してしまったのだろうか？SAMEGENEMARRIAGEで止まるようになってしまった．バックアップに戻ってみよう．⇒戻った．

午後4時半起床，曇りのち雨．朝食は薄切り食パントースト2枚，野菜サラダ．ネットアクセス時間を制限するためのタイマーは設定通りに作動したが，リスニングトレーニング中だったのでそのまま続行した結果，また大幅に予定時間を超過してしまった．ネットの閲覧範囲をよほど厳格に制限しないとこのままでは泥沼から抜けることができない．

反例サンプルは一応多重は解消した状態になっているが，果たしてこの修正が本当に正しいのか？収束しているのかどうかを確認する必要がある．仮修正がかなり残っているのでそれらをフィックスする必要があるが，この方向でよいという確証が出るまでは保留せざるを得ない．画面上の瑕疵に関しては一旦目をつぶって，机上の反例だけでもテストしてみることにする．リリース版を起こす段階ではないので，開発環境のリリースモードでテストしてみることにしよう．

机上の反例サンプルを集めたら9000本を超える大きなフォルダになった．どうもどこかでハングしている気配だ．画面も相当崩れていてかなりデグレードしているような気がする．障害は山のように発生している．反例2019-02-26という一番新しい反例に絞ってテストしてみることにする．このフォルダには4本しか入っていないが，すべてでエラーが起きた．いや，直近のサンプルでも「非連結」が残っている．重婚同類グラフで循環がないのに非連結になっているというのはかなりおかしい．やはりまずこれをフィックスすることが先決だろう．

始系列は[系列枠]: #501 odr=1 先祖=#327 ＣＬ(0)[1] 優先=#325 ＣＫ(0)だが，始系列を直接参照している系列がない．これはかなりおかしい．というか，これでは解けない．TribeRelocationのステージ【５.１】絶対世代番号に基づいてカードシフトでは始系列を参照している系列が3つある．

1. #509 odr=3 HM=1 先祖=#217 ＡＩ(0)[3] 優先=#728 ＡＡ(1)→#201 ＡＡ(0)
2. #541 odr=7 HM=1 先祖=#341 ＣＳ(0)[7] 優先=#737 ＡＡ(2)→#201 ＡＡ(0) →主系列#501:ＣＬ
3. #549 odr=9 HM=0 先祖=#471 ＦＫ(0)[9] 優先=#740 ＡＡ(3)→#201 ＡＡ(0) →主系列#501:ＣＬ

いや検定出口でも状況は同じだ．いずれも参照実ノードはＡＡ(0)になっている．判定関数がBTWの仕様変更に対応していないのではないだろうか？

午後3時半起床，曇り．朝食は食パン薄切りトースト2枚，コロッケ，白菜のサラダ．大分遊んでしまった．いまさらネットを遮断するなどのことはできないが，ともかくネットにアクセスする時間を削減しない限りここで沈没してしまう．ほっておくと毎日チェックするページのボリュウムが再現なく増えてしまう．最近はかなりヒアリング力が付いてきたのでそれがおもしろくて配信される英語教材ビデオを端から視聴しているので，それだけでも優に3時間を超えてしまう．

英語教材を視聴している間は基本的にワイヤレスイヤホンを使っているので，そのバッテリが切れるまでという上限を設定することは可能だが，多分4時間くらいは実稼働するのではないだろうか？スマホにアクセス時間制限機能が付いていると便利だと思うのだが？そのくらいのものはあっても良さそうな気がするので探してみよう．あるある！ただし，子ども用だ．子供をスマホ依存症から守るために「アプリに時間制限」をかける方法

しかし，これは一日のある時間帯をロックするというものなのでわたしのように生活時間不定の場合にはあまり向いていない．むしろ，朝起きたときにアラームを仕掛けておくというのが適当なのではないだろうか？「時計」アプリは時差を見るために常時使っているが，「時計」というくらいなのだからそれくらいの機能は付いているだろう．①アラーム，②ストップウォッチ，③タイマーの3つの機能がある．使うとすれば①か③だ．

アラームというのはおそらく「目覚まし時計」のことだろう．むしろ，タイマーを仕掛けるというのが一番使い易そうだが，タイムアップしたときにアラームが鳴るようにできるだろうか？当然そうなっている．サウンドも選択できる．Ringing Alarm という昔の電話のベルのようなのもあるが，Alarm Rooster という雄鶏が時を作る聲というのがあるのでこれを使ってみよう．これでともかく時間制限ができるようになった．

設定時間をどのくらいにすればよいか？妥当な線としては3時間ではないだろうか？この3時間には，①メールとニューズフィードのチェック，②英語ヒヤリング用ビデオの視聴と閲覧，③フェースブック，G+などSNSのチェックが含まれる．現状では一日20時間くらいアクセスしていると推定されるので3時間まで削減できれば仕事もできるだろう．仮に4時間まで延長されたとしてもまだ十分な時間を確保できるものと思われる．このタイマーは画面を消してもバックグラウンドで走っているようだ．

さて，仕事に戻ることにしよう．現在チェックに使っているサンプルは反例2019-02-26\BUG19-01-27 06-56-47.NONだ．すでに基準ノードの配偶者ポジションにはＡＡ(0)が表示され，残る多重はＣＲ(0)の配偶者ポジションにあるＡＡ(2)だけになっている．なぜＣＲ＋ＡＡのBTWが成立していないのか？その理由を見ることにしよう．そもそも BetweenTwoWomenで呼び出しが掛かってきていない．おそらく「 セグメント先頭枠だけ処理する＠2017-10-25」で弾かれているのではないかと思う．いや，この結婚はＡＡの下にあるのだからそれは無関係であるように思われる．

BetweenTwoWomenはすべての結婚枠を検査してその結婚枠が右手婚となるかどうかをチェックしているが，左手本人はあくまで本人ポジションのカードに限定している．この制限を緩和してIfBTWPossibleを使うようにしたところ再び基準ノードの配偶者が消えてしまった．以下の仮修正を入れて収まった．

1. NAMEBOX::IfBTWPossible　HaveSingleFatherBox 呼び出しを後方に移動
2. NAMEBOX::IfBTWPossible　左手本人が基準ノードであるときの特殊処理を無条件で実行するように変更
3. NAMEBOX::IfBTWPossible　「基準ノードの配偶者が単親婚を持っている場合」の検査関数をSingleFatherBoxからHaveSingleFatherBoxに変更
4. NAMEBOX::HaveSingleFatherBox　配偶者の場合は無条件で偽を返すように変更

これにより非連結要素のない下記のような図面が出力できるようになった．

ただし，この図面には，①不用な結婚点があちこちに散らばっている，②BTW連結線が引かれていないところがあるなどあちこちに瑕疵がある．また，主選択カードを切り替えようとしてTREEVIEW::PrimarySelectionで「主選択人名枠不在」エラーが発生した．再現手順は不明．

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

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

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

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

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

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

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

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

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

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

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

NAMEBOX::DoublyBlessedOneの中でChangeRealRefferenceを使ってノード対の付け替えを実施している．暫定的に止めることでＡＡ(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ファイルを使って解析することにする．ＡＡは(0)～(3)の4つの仮ノードを持っている．ＡＡ(0)は不可視の配偶者ノードで右手婚配偶者と左手本人の属性を持っている．(1)は不可視の消去された仮ノード，(2)は可視の配偶者ノードで左手本人，(3)は不可視の配偶者ノードで右手婚配偶者属性を持っている．

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 ＣＳ(0)[7] 優先=#737 ＡＡ(2)→#201 ＡＡ(0) →主系列#501:ＣＬだ．この参照は左手本人から右手配偶者に向かうためBTW左接続関係とされる．しかし，「左手枠配偶者を左手本人とするBTW拡張」では配偶者が左手本人となる場合があるのでこれは合法だ．これでようやくスタート地点に戻ったのではないだろうか？

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

Your 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ヶ月はかかりそうだ．会話練習はやろうと思えば知り合った仲間とボイスチャットすることも不可能ではない．ひょっとして数ヶ月後には英語がペラペラになっている可能性はゼロではないが，おそらくそのときには日本語をすっかり忘れているのではないかと思う．

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

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

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

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

Ｙ！パートナーはもう打ち切ってもよいかもね．「みんなの近況」というのは結構読ませるので毎日チェックしてた．一度だけマッチングしたけど相手は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回取っているのでわたしの肺が「肺気腫」寸前の状態になっていることに関しては異論はない．隣家の旦那さんが「肺気腫」で救急車で搬送され，その後自宅療養で「酸素吸入器」を使うようになったという事例も見聞きしている．どうもこれではあと一年だな？という気がしてきた．いよいよタバコを止めるしかないのだが，カートンで買ったばかりだ．しかも，タバコが切れたと思ったのは早とちりでまだ２箱も残っていた．

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

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

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

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

タバコをカートンで買うようになったので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日間限りのディスカウントもやっていたが，デビッドカードが使える銀行口座が残高ゼロの状態だったため時機を逸した．

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

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

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

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

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

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

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

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

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