2019-03-09

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

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

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

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

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

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

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

image

非連結系列は解消し多重も発生していない.このバージョンを少し走らせてみよう.とりあえず,反例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 大山守皇子.どうもこのサンプルは相当加工が入っているようなので一旦無名化してから解析することにする.基準ノードのAWは結婚を1つしか持っていないが,その配偶者のNBが複数の結婚を持っていることが問題を複雑なものにしているように思われる.また,家内婚が5つも発生していることも撹乱要因になっている可能性がある.

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

これを暫定的に止めると最終的に3つないし4つの結婚枠で「不可視枠を移動」ないし「結婚点を一致」が起こるようになる.「結婚点を一致」が起きているのは[結婚枠]:#543:#659 CD(0)+#1427 QY(0)→#4233 CS(2) だが,「不可視枠を移動」を暫定的に停止すると[結婚枠]:#4469:#1247 NL(0)+→#1249 NM(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 CL(0)[1] 優先=#325 CK(0)だが,始系列を直接参照している系列がない.これはかなりおかしい.というか,これでは解けない.TribeRelocationのステージ【5.1】絶対世代番号に基づいてカードシフトでは始系列を参照している系列が3つある.

  1. #509 odr=3 HM=1 先祖=#217 AI(0)[3] 優先=#728 AA(1)→#201 AA(0)
  2. #541 odr=7 HM=1 先祖=#341 CS(0)[7] 優先=#737 AA(2)→#201 AA(0) →主系列#501:CL
  3. #549 odr=9 HM=0 先祖=#471 FK(0)[9] 優先=#740 AA(3)→#201 AA(0) →主系列#501:CL

いや検定出口でも状況は同じだ.いずれも参照実ノードはAA(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だ.すでに基準ノードの配偶者ポジションにはAA(0)が表示され,残る多重はCR(0)の配偶者ポジションにあるAA(2)だけになっている.なぜCR+AAのBTWが成立していないのか?その理由を見ることにしよう.そもそも BetweenTwoWomenで呼び出しが掛かってきていない.おそらく「 セグメント先頭枠だけ処理する@2017-10-25」で弾かれているのではないかと思う.いや,この結婚はAAの下にあるのだからそれは無関係であるように思われる.

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

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

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

image

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