投稿者: babalabo

午後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では子どものいる子ども枠を持っている場合には真を返している．

午前0時起床，曇り．夜中映画を流しっ放しで寝てしまったので，スマホのバッテリーが空になってしまった．充電を続けているが，50%を超えてもまだ起動できない．ルーターも3日間の上限10GBを超えているのでやけくそ遅くなっている．ルーチンではスマホで昨日のログをチェックしながらタブレットで校正という手順になっているのだが，スマホが使える状態まで回復していない．またメインPCがいつの間にかネットアクセス可能状態になっていた．

タブレットでログをチェックすることはできるが，「スマホのブラウザで最適化」という現行方針とマッチしない．やや大げさな言い方だが，スマホが使えないとほとんど失明したのと同じになってしまう．電気料金の請求書が入っていた．8千円を超えている．400Wのストーブを常時点灯しているだけで5千円！別にストーブを焚いているのだから，これでは掛かり過ぎだ．湯たんぽに戻るという訳にもゆかないが，できるだけ200Wでしのぐようにしなくてはならない．石油ストーブをもう少し長時間使って室温を一定に保った方が，まだ安くつくかも….

スマホは充電100%にならないと起動できないのだろうか？65%を超えているのにまだ起動できない状態だ．100%になっても切り替わらない．電源スイッチを長押しして入った！以下昨日の続き：

冷泉院への切り替えはTribeRelocationのステージ【５.２】重婚同類グラフ検定の事後処理を行なう，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())により停止する．右手婚配偶者が左手本人というエラーだ．障害が起きているのは#201ＡＡ(0)．これはおそらく「左手枠配偶者を左手本人とするBTW拡張＠20190130」に依るものと思われる．いや，ちょっと違うのではないか？

この拡張で配偶者でも左手本人になれることになったが，左手本人と右手婚配偶者が同一ということはあり得ない．これは単純に却下でよいのではないか？ゼロ復帰するようにしてエラーは解消したが，多重が発生するようになった．このエラーを無視すれば多重は発生しない．ＡＡの出現は４つある．

1. (0)　配偶者　不可視　DOUBLYBLESSED｜BTWRIGHTSPOUSE
2. (1)　本人　不可視：消去された仮ノード
3. (2)　配偶者　可視　被参照実ノード　DOUBLYBLESSED
4. (3)　配偶者　不可視　BTWRIGHTSPOUSE

ＡＡは結婚を3つ持っている．すべて有配偶者で相手は，①ＣＫ，②ＣＲ，③ＦＫだ．

ＣＫは基準ノードでＡＡはその配偶者だが，ＣＫのボックス内に入っていない．多重カードゼロというのはよいが，「基準ノードの配偶者は基準ノードに近接配置」という原則が崩れている．連結線の欠落もあるが，それはあとから見ることにしよう．ＡＡは単親婚は持っていないので原則どこにでも配置できるはずなのだが… ＦＫとの間には子どもはいないが，それ以外の二人との間にはいる．ＣＲとの子どもは配偶者であるＡＡの預かり，ＣＫとの子どもはＣＫの下にある．

図面的には多重ゼロとなっているので一応「解」と認められるが，なぜ基準ノードの枠外に出てしまっているのか？その理由を見ることにしよう．ＡＡは本来ならBTWにならなくてはならないのだが，そうなっていないのはなぜか？基準ノードの配偶者ＡＡ(0)が不可視というのが問題だ．つまり，この結婚はBTW右手婚とすべきではない．

午前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のステージ【２】系列優先仮ノードと優先実ノードを設定するでは①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のステージ【２】系列優先仮ノードと優先実ノードを設定するのループでTRIBEBOX::MakeUpTreeのあとで実行している検査とSetupPrimaryNodeをループの外に出して別ループで実行するようにしてこのエラーは解消したが，今度は別の位置でエラーが出るようになった．[系列枠]: #806 odr=0 先祖=#376 ※３(0)[0] 優先=#282 桐壷の更衣(0)の優先ノードは桐壷の更衣．桐壷院が基準ノード承香殿女御（朱雀院の）の配偶者であるため，桐壷院＋桐壷の更衣の結婚は桐壷の更衣の系列で展開されている．

このため桐壷の更衣の仮ノードは1個しか存在しないので系列優先ノードを桐壷院に切り替える必要がある．エラーを無視して描画した場合には冷泉院に切り替わっているが，実仮ノードで世代差が発生している．この図面では重婚同類グラフが循環しているので異世代多重が発生することは避けられないが…

TRIBEBOX::decidePrimaryNodeで優先仮ノードを決定する時点で優先実ノードの存在を確認するようにした．このためにGetRealnode(NAMEBOX*)という関数を新設した．優先実仮ノードの対が得られないときはGetAlternativePrimeNodeが実行され，優先仮ノードの切り替えを実施する．これで桐壷の更衣から桐壷院に切り替えることができたが最終的には冷泉院に切り替わる．