系列優先ノードの切り替えはEstablishMajorTribeChainの専管とする

源氏物語全系譜6.1.ZELの直系親族図を#125 髭黒で開いてNAMEBOX:MakeExtractBoxで停止する.oya->getmarglinkで空が返っている.getmarglinkは結婚枠の属する結婚リンクを求める関数だ.このチェックポイントは「全体図を#120 八宮の母女御でソートしてgetmargboxで停止するという障害の原因を突き止めるために暫定的に挿入したものだ.getmarglinkが空を返すというのはノーマルな動作だが,どのようなケースでそれが起きているのかを確認しておきたい.

抽出対象ノードはNAMEBOX #1593 蛍兵部卿宮(1)でMakeExtractBoxはNAMEBOX::CardShiftDirectの下位関数で,結婚枠内のノードとその下流系を抽出してその下にぶら下げる「長い尻尾」を構成するときに,その一段分の操作を実施する関数だ.この関数の主語は処理対象となる人名枠でoyaというのは,そのノードを格納している結婚枠であり,「親元結婚枠」である場合と,「抽出枠」である場合の2通りがある.今の場合はすでに1段目の処理は完了しているので,「抽出枠」だ.

この結婚枠はEXTRACTDUMMY|EXTRACTBOX|MOTHERLESSという属性を持っているので,「多重カード削減のためシフトされた抽出結婚枠」であることは間違いない.通常,結婚枠は結婚リンクに直接接続しているため,結婚リンクと一対一に対応しているが,抽出枠やTYW枠などは余分に追加された描画要素なので,変則的なトポロジーになっている.今の場合NAMEBOX #1839 蛍兵部卿宮(2)のNAMEsDUMMYスロットに接続している.蛍兵部卿宮(2)はEXTRACTDUMMYという属性を持っているので,「親元結婚枠」に残された代用ノードと思われる.

いずれにしても,親枠が結婚リンクを持たない場合があるということがわかった.しかし,これはかなり変則的な状態と考えられるので,このような状態を属性として保持しておくことにしよう.人名枠や結婚枠にはクリティカル属性というのがあるので,ここで設定することにする.HASNOMARGLINKという属性を新設し,NAMEBOXの場合にはsetmarglinkでセット/リセットするようにした.MARGBOXの場合は接続なので,MARGBOXのコンストラクタでチェックすることにする.

image

上図には「長い尻尾」が3本出現しているが,これは玉鬘と致仕太政大臣の親子関係から強制されるレイアウトだ.長い尻尾を使うことで玉鬘が多重となることを回避している.「全体図を#120 八宮の母女御でソートしてgetmargboxで停止」という元の問題に戻ってみよう.現行では重婚同類が存在するときにはShiftDirectAbsoluteを実行しないとしているので,停止しないようになっているが,ShiftDirectAbsoluteを実行するという論理に戻してみる.

NAMEBOX::getmargboxの出口検査で結婚枠不在で停止する.障害ノードはNAMEBOX #3416 桐壷院(2)で,クリティカル属性HASNOMARGLINKを持っている.NAMEBOX::TYW2ExtractBoxの主語は#1767 桐壷院(1)でTOOYOUNGWIFE属性を持ち,HASNOMARGLINKはオンになっている.桐壷院(1)の長い尻尾をDumpDummyChainで見ると,

1  thread        #3416 桐壷院(2) #3450 前春宮(1)
2  #3417 [結婚枠]:[2] #3424 桐壷院(3) #3452 前春宮(2)

のようなLDR束になっている.桐壷院(2)は親枠内のLDR,(3)はダミーノード,この下にTYW枠

MARGBOX #3425:#3424 桐壷院(3)+→#1767 桐壷院(1)

が配置されている.TYW2ExtractBoxではTYWチェーン先頭のLDRを固定ノードに切り替えてLDR束から外すだけで人名ノードの接続関係は変化していないはずだから,桐壷院(2)→ (3)→ (1)という順序も変化していないはずだ.このうち,HASNOMARGLINKは真ん中の(3)だけで,(2)と(1)は同じMARGLINK:#72 pnum=1 refnum=1 夫=CARDLINK:#424 @10一院[0] 妻=空 子=CARDLINK:#408 @2桐壷院[3]を参照している.さて,どこに問題があるのだろう?

NAMEBOX::resetghostbitsでは,「LDR束線分から離脱したときは,親参照を元の親の結婚枠に戻す@20210113」として,oya = getmargboxでoyaが空でなければ親参照を設定している.この処理は長い尻尾に属するすべてのノードを対象に実行されている.従って,中間にMARGLINKを持たないノードが出現するのは避けられないように思われるのだが… ⇒getmargboxではそれに備えた仕組みを備えている.つまり,対象ノードがダミーノードなどmarglinkを持たないオブジェクトの場合にはYリストを上昇して上位結婚枠を探すようになっている.

一般に系図木を階層的に見ると,人名枠と結婚枠がサンドイッチのように交互に層をなすようになっているから,本来なら必ず結婚枠を見つけることができなくてはならない.それができないのは,このノードがダミーノードとしてのEXTRACTDUMMY属性を失っているからだ.どこでそれがリセットされたかが問題だ.

このダミーチェーンは最初抽出枠チェーンとして生成された後,同じShiftDirectAbsoluteの中でExtractBox2TYWによってTYWに転換されている.このとき一度EXTRACTDUMMY属性をリセットされ,代わりにDUMMYBOX属性を与えられている.その後,SolveMargboxCollisionでTYW2ExtractBoxが実行され,resetghostbits(DUMMYBOX)でリセットされると同時に親参照付け替えのためにgetmargboxが呼び出されている.NAMEBOX::TYW2ExtractBoxではその直後にsetghostbits(EXTRACTDUMMY)が実行されるので,おそらく致命的な瑕疵にはなっていないのではないかと思われる.問題は解決した.桐壷院は結局,抽出枠で収まっているようだ.

image

重婚同類のときShiftDirectAbsoluteを実行することによる弊害というのがまだ残っている可能性もあるが,現在の構成で進めることにしよう.

同上サンプルの全体図を#191 左大臣(真木柱)でソートしてTRIBEBOX::SetMinorTribeで停止した.優先ノードが消去された仮ノードのとき,優先仮ノードの実ノードと系列の参照する実ノードが一致しないというエラーだ.障害が起きているのはTRIBEBOX #1569 先祖=#1258 一院(0)で,優先仮ノードはNAMEBOX #3476 冷泉院(5),実ノードはNAMEBOX #1371 左大臣の女御(0)だ.冷泉院(5)はLDRで関係は養子,左大臣の女御(0)は実子でいずれも本人ノードだ.BTW関係は成立していない.接続種別は婚姻関係になっている.

最終出力では左大臣の女御はBTWのRIGHTHUSBAND(右手結婚枠本人仮ノード)になっている.左大臣の女御は基準ノード左大臣 (真木柱)の子どもで,左大臣の女御+冷泉院には子どもがいないため,始系列にはこの2つのノードしか含まれない.

image

基準ノードの子どもを仮ノード消去するというのはよくないが,左大臣の女御+冷泉院の結婚が始系列で展開されているとすれば,そもそも仮ノード消去するようなことにはならないはずなのだが… まして,このノードがLDRというのは考えられない.どういう操作をするとそういうことになるのか?⇒いや,勘違いしていた.一院系列の冷泉院から左大臣系列への参照なのだから,そのようなことはあり得るかもしれない…

冷泉院(5)がLDR参照しているのは,同じ一院系列内の冷泉院(3)だ.このようなことはあり得るだろうか?冷泉院の仮ノードは5つあり,可視のものだけでも3個ある.ただし,うち一つはLDRなのでリアルに可視と言えば2つになる.これは避けられないだろう.最終的には一院系列は優先=#1766 冷泉院(3)→#1371 左大臣の女御(0)で収まっている.これはBTW左接続関係だ.「系列実ノードが一致しない」というエラーはDoublyBlessedOne→ ChangeRealRefferenceの過程で起きている.

この関数は,右手配偶者が実ノード参照されているとき,「右手配偶者が実ノードのときは左手本人に付け替える」ために実施されるもので,安定した状態とは言えない状況なので,OnEstablishMajorTribeChainの場合を除外しているように,除外してよいのではないかと思う.BTW処理中はOnDoublyBlessedOneが立っているので,これを見ることにしよう.⇒このエラーは回避できたが,別のエラーが残っている.

SetMinorTribe→ DoesMajorTribePathExistでhasPhysicalConnectionが呼び出され,(!realnode->getghostbits(REALGHOST))で停止するというエラーだ.⇒「ChangeRealRefferenceで系列優先ノードの切り替えは実施しない@20210119」ということにした.系列優先ノードの切り替えはEstablishMajorTribeChainの専管事項とし,BTWやTribeGhostNameは系列優先ノードの切り替えには関わらないというのがわかり易いと思う.

▲同上サンプルの直系親族図を#57 女三宮でソートして,NAMEBOX:TailSheddingで停止した.TRIBELIST::ShiftDirectAbsoluteで起きている.重婚同類が存在するので,オリジナル版ではパスされていたコードだ.ShiftDirectAbsoluteは重婚同類検定で決定した絶対世代番号に基づく垂直再配置なので,多重が入ってくると混乱が生じることは明らかだが,多重が存在する場合には重婚同類検定の結果がまったく使えないというのもおもしろくない話だ.

この辺りはもう少し改善の余地があると思われるので,追求してみたい.そのためには,重婚同類検定(以下多重検定)でどんなことをやっているのかを調べてみなくてはならない.多重検定ではグラフを3つも使っている.どんな用途で使っているのかをまず調べてみよう.

エラーを無視して続行で描画まで進むことはできる.多少不自然なところはあるが,何とかこなしているようだ.

image

重婚同類が3で多重が10発生している.うち1件は基準ノード自身の多重だ.系列は4系列でほとんどすべての領域を占める始系列の一院系列と,それに埋め込まれた二条太政大臣系列,※3系列,先帝系列からなる.後の3つはいずれも構成メンバー3~4の小さな系列だ.障害が起きているのはNAMEBOX #1927 光源氏(2)で,仮ノードと実ノードの世代差が-1になっている.

ロコモティブシンドロームに追い抜かれる?

昨日の続信

kamui さま

>早速の返信ありがとうございました。

「正式版はいつ出るのか?」という疑問をお持ちの方が多数おられますので,不躾ながら返信を「公開」させて頂きました.m(__)m

>是非、今年度中のリリースをお願いします。

ご寛恕いただきありがとうございます.時間が速いので…ロコモティブシンドロームに追い抜かれなければよいのですが…

>リリースしていただければ新しいパソコンも買えます。

最速のパソコンというのを使ってみたいですね!(わたしが使っているのはキャンペーンの特価品ばかりです)最近パッケージ全体をリビルドすることが多いので,痛感しています.これまでは時間・空間コストの節約(ケチること)を最大の課題としてきましたが(Windows 96で走るゼルコバの木クラシックなどというのはその最たるもの),そんなことを言っている場合ではないような気もしています.(アメリカ人の太っ腹な資源浪費に負けてしまいます)ゼルコバの木を動かすには超速マシーンが必要という時代が来るかもしれません…

>「システムの完全なグラスボックス化にあります」 これいいですね

スリムアップというのは一種の断捨離のようなもので,システム全体のクリーンアップ(大掃除)を目指しています.AIが人間の知能を超える「シンギュラリティ」の日が近いということが盛んに言われていますが,その前にニューロネットのブラックボックスと(我々の)グラスボックスが融合する日が来なくてはならないだろうと思っています(笑).

A.B.

源氏物語全系譜6.1.ZELの全体図を#81 弘徽殿女御で開いて,TRIBEBOX::hasPhysicalConnectionで停止する.系列優先仮ノードの属性がREALGHOSTのとき,実ノードが可視という理由だ.⇒おかしい.停止しなくなってしまった.TRIBEBOX::hasPhysicalConnectionのラッパ関数HasPhysicalConnectionを作っただけで,特に有意な修正は行っていないつもりなのだが…

障害が起きているのはTRIBEBOX #1569 先祖=#1258 一院(0)[2]で優先仮ノードはNAMEBOX #1255 秋好中宮(0),優先実ノードは#1766 冷泉院(1),主系列TRIBEBOX #1567 先祖=#1375 摂政太政大臣(0)[1] 優先=#1329 弘徽殿女御(0) 始系列にBTW右接続関係で接続している.障害はSetMinorTribe→ DoesMajorTribePathExist→ hasPhysicalConnectionで検出されている.

秋吉中宮(0)はREALGHOSTだが,同時に両手に花の右手結婚枠本人仮ノードでもある.こういうことは起こり得ることだ.⇒今度は動作するようになった… ⇒「実ノードが可視」のチェックは「実ノードが仮ノードを参照している場合」に限定するようにした.

同上サンプルを#98 夕顔でソートしてhasPhysicalConnectionで停止した.仮ノードがBTWRIGHTSPOUSEのとき,実ノードがDOUBLYBLESSED属性を持たないというエラー.障害は#1569 一院系列,優先仮ノードは#1762 冷泉院(1),優先実ノードは#1257 冷泉院(0).冷泉院(1)はBTWRIGHTSPOUSE(両手に花の右手結婚枠配偶者仮ノード),冷泉院(0)は三位中将系列でREALGHOSTだが,BTW属性は持っていない.系列接続種別はBTW右接続関係になっているが,その相手方ではない.しかし,どこかで最終解決を得ている模様だ.

出力では冷泉院(0)と(1)がBTWRIGHTSPOUSE,(2)がDOUBLYBLESSEDで収まっている.にも関わらず,「実仮ノード本人で系列種別が」というエラーメッセージが継続して出ている.これは冷泉院(2)が被参照実ノード属性を持っているためだ.この参照は冷泉院(3)→(2)の参照で,冷泉院(3)はLDRだ.系列種別がDecideTribeTypeと一致している場合は警告を表示しないようにした.

同上サンプルを#118 伊予介でソートしてhasPhysicalConnectionで停止した.障害系列は#1573 一院系列で優先仮ノードは#1763 光源氏(2),実ノードは#1760 空蝉(1).どちらもDOUBLYBLESSED|RIGHTHUSBANDの属性を持っている.系列接続種別はBTW左接続関係になっているが,hasPhysicalConnectionはPRIME_BTWRIGHTを求めている.しかし,DecideTribeTypeはPRIME_BTWLEFTを返している.なぜか?この2つのノードは相反する属性を持っている.なぜこういう状態になっているのか調べる必要がある.

少なくとも空蝉はDOUBLYBLESSEDとRIGHTHUSBANDの両側になり得る.伊予介との関係と光源氏との関係があるからだ.光源氏はDOUBLYBLESSEDだけのように見えるがどこかで解消しているのかもしれない.いずれにせよ,優先仮ノードがDOUBLYBLESSEDとRIGHTHUSBANDの両方を持っている場合,接続種別をどちらか一方に決めつけることはできない.どのように判定すればよいのか?DecideTribeTypeがどのように判定しているのかを見てみよう.

DecideTribeTypeでは実際に仮ノードの結婚チェーンを検査して一致するものがあればPRIME_BTWRIGHTを返しているが,そうでなければPRIME_BTWLEFTを同様の方法で検査している.DecideTribeTypeの検査は厳密で信頼できると考えられるので,むしろこの結果と一致しているか否かで判断するのがよいと思われる.

同上サンプルの直系血族図を#7 秋好中宮でソートして,TRIBEBOX:checkTribeVerticalPositionで停止した.TribeRelocationの出口近く,FOLDINGCHANNELSフェーズでFoldingChannelsを実行中のエラーだ.(PHASE > AFTERMARGSAMEGENE && !NOMULTICARD && senzo->IsValidNameBox() && !sameGeneCycles && !TRIBES && senzo->getFloor() != ancestor->getnodegene()) という条件で停止している.多重が存在しない状態で,先祖ノードの物理世代番号と絶対世代番号が一致しないというエラーだ.⇒エラーを無視して描画は可能.

image

この図面には一院系列,大臣(葵)系列,※3系列の3つの系列が含まれている.障害が起きているのはTRIBEBOX #1569 先祖=#1367 大臣(葵)(0)[2] 優先=#1577 六条御息所(2)→#1575 六条御息所(1)だ.「多重はない」としながら,六条御息所で多重になっている.絶対世代番号というのは,重婚同類検定で決定される数値だが,おそらくこのときには大臣(葵)の直下の六条御息所を光源氏の隣のカードと同世代位置に配置するという設計だったのに違いない.それが実現されていないのは,明らかにShiftDirectAbsoluteとAdjustTribeGenerationを(暫定的に)止めているための帰結だ.これを復活させて下図を得た.

image

産湯を捨てるつもりで赤子を流してしまうところだった(汗).

同上サンプルの全体図を#120 八宮の母女御でソートしてNAMEBOX:getmargboxで停止した.TribeRelocation→ MakePairListClean→ CompleteTribeBoxを実行しているところだ.(getY() && PHASE > GODOWNSTREAM && !disposing && getrelation() != REL_ROOTS && !hidden())という理由で停止している.この行には「結婚枠不在」というコメントが付いている.

getmargboxは人名枠の属する結婚枠を返す呼び出し頻度の高い汎用ルーチンだ.障害ノードは#3424 桐壷院(3)で一院系列に属する.関係は実子だが,TYW婚への参照を持っている.この参照リンクには「LDRチェーン末尾に接続するTYW結婚枠を上位人名枠から参照」というコメントが付いている.障害が起きているシチュエーションは,SolveMargboxCollisionで結婚枠の衝突が検出され,MARGBOX:TYW2ExtractBoxで関係するTYW婚を抽出枠に転換する処理が実施されているところだ.このエラーはかなり難しい.

このノードはMakeExtractBoxで生成されたときから結婚リンクを持っていない.ShiftDirectAbsoluteの中で生成されているので,この部分のロジックをオリジナルの重婚同類が存在するときには実行しないという論理に戻しておくことにする.この部分はあとで見直すことにしたい.

▲同上サンプルの直系親族図を#125 髭黒で開いて,NAMEBOX:MakeExtractBoxで停止した.oya->getmarglinkで空が返っている.これは上記の問題の原因とも言える箇所で,この値が空になっていると,上記のようなエラーが生じる可能性がある.#144 真木柱でも起きる.#125 髭黒の場合を見てみよう.⇒重婚同類は存在しないため,ShiftDirectAbsoluteが実行され,その中でエラーが発生している.

NAMEBOX::MakeExtractBoxでは,「対象ノードを親枠から一段シフトする」処理を実行している.MakeExtractBoxはCardShiftDirectから呼び出されてカードの一段シフトを実行している.CardShiftDirectは「結婚枠からこのノードとその下流系を抽出して結婚枠に格納し,このノードの位置にはEXTRACTDUMMYダミーノードを置く.抽出された部分結婚枠はダミーノードの下に配置する.抽出部分結婚枠はダミーノードのNAMEsDUMMYに接続する.」を実行している.今の場合はシフト量は2段で,ループの2回目でエラーが発生している.MARGBOX:getmarglinkには以下のような説明が付いている.

「LDR結婚枠の親ノードは結婚枠なのでgetmarglinkでは空が返る.抽出枠/TYW枠の親ノードは人名リンクなので空が返る@2018-01-23 ZTYW枠の結婚リンクを求める手続きを追加した@20180110」

ガラス箱とガラパゴスって音が似ている?

kamui氏からメールが入っていたので返信した.

kamui さま

いつもお世話になっております.

>コロナの中、憂鬱な日が続いています。久しぶりにテント村に行きましたら「源氏物語全系譜6.1.ZELの法定親族図 #1 ----事象が発生している」などの記述が有りましたので、Windowsの最新バージョンへのインストールが可能になったのではないかと思いメールを出しました。

思い出して頂きありがとうございます.当方の開発機のOSバージョンは1909ですが,インストールできています.この後,2004,20H2というのが出ているようですが,まだ試していません.

>正式版のダウンロード可能になるのはいつ頃ですか?

本年度(2021年)中にはリリースしたいと考えています.仕掛りのバージョンは描画などにかなりの不具合があり,仮リリースもできない状態になっています.Alphabet(Google)傘下のDeepMindはアミノ酸配列からタンパク質の3D構造を予測するAlphaFoldと呼ばれるAIで目覚ましい成果を挙げていますね!「タンパク質3D構造予測問題」と「家系図作図問題」のどちらが難しいか?は言うまでもありませんが,我々のシステムもいよいよガラパゴス化(独自進化?)してきたことを率直に認めるしかありません.

G島でこのまま朽ち果てるのか,何か新しい成果を携えてカムバックできるのか?これが事実上最後の機会になると考えられるので,描画上の不具合などは一時棚上げして,システムのスリムアップを進めているところです.ニューラルネットの最大の弱点はそれが内部構造の見えないブラックボックスであるという点にありますが,我々の目標はそれと真逆の,システムの完全なグラスボックス化にあります.(ガラス箱とガラパゴスって音が似ているような?笑)

2021/01/17 硝子箱島にて
馬場 英治

源氏物語全系譜6.1.ZELの全体図を#1 光源氏で開いて「重婚同類グラフ検定異世代多重カウントオーバー」でループが停止しない.⇒系列枠:snum=1619 primetype=3:婚姻関係 senzo=#788 右大臣 (明石)で「実ノード不一致」が発生している.ループのボトムでブレークするようになっているが,EstablishMajorTribeChainでそれ以前にgoto TRYAGAINを実行している.⇒対処した.

この図面では系列が64個あり,そのうち一院系列の系統に含まれるものが,31個ある.この系統グラフは4つの連結成分に分離している.①始系列(一院系列)を含む28系列のグループと,②衛門督(箒木)系列,③伊予介系列,④右大臣(明石)系列だ.前回の法定親族図のときは,衛門督系列と伊予介系列は一つの成分になっていたので比較的簡単に解けたが,今回はかなり難しそうだ.

④右大臣(明石)系列の優先ノードは髭黒(2)で実ノード候補は玉鬘(0)と髭黒(3)だ.当初は髭黒(2)→ 玉鬘(0)という接合になっているが,EstablishMajorTribeChainで付け替えを試みようとして失敗している.髭黒の仮ノードは4つある.#1373(0)は一院系列で配偶者,#1804(1)は先帝系列の配偶者,#1841(2)は右大臣(明石)系列の実子,#3662(3)は右大臣系列のLDR.当初は髭黒(2)はTYW婚で外部に出ていて,髭黒(3)→(2)というノード対で連結されている.

この構成では髭黒(2)→ 玉鬘(0)という接合は難しい.EstablishMajorTribeChainの中で代替案を探す時点でこのノード対をRetrieveGhostで削除したところ髭黒(3)のノード自体が削除されてしまった.これはTWY婚の本人ノードが元の位置に戻るというノーマルな動作だが,そのまま続行できないので一旦EstablishMajorTribeChainから離脱してリトライするようにして解決した.かなり迂遠な解になってしまうが,今のところこれしかない.これで一応④右大臣(明石)系列の問題は解決したと考えてよいと思う.

image

しかし,伊予介系列と衛門督系列の孤立は続いている.前回サンプルでは空蝉が衛門督系列と伊予介系列の接点となり,軒端の荻が伊予介系列と一院系列を繋いでいたのだが,今回の図面では伊予介系列には空蝉の席がなく,軒端の荻は蔵人の少将という配偶者を持つという構図になっている.いや,少なくとも伊予介と衛門督は伊予介を媒介として接合できるはずだ.⇒確かにそれは可能と思われるが,現行アルゴリズムではそのような動作にはならない.

現行論理ではトップダウンで始系列を基準とし,始系列の連結成分中のノードとの接合しか探していないからだ.もし,伊予介系列が始系列と連結できれば初めて衛門督→伊予介が対象に入ってくる.軒端の荻は結婚を持っているが,BTWを使えば接合できるはずだ.なぜそれが出てこないのだろう?⇒すでに優先=#1827 軒端の荻(1)→#1353 軒端の荻(0)で設定されているからだ.EstablishMajorTribeChainでは既存の設定では物理コネクションを確立できないと見て,最初から除外している.

放置状態であればループの中でBTWを成立させてもよいと思われるのだが,なぜそうならないのか?⇒NAMEBOX::DoublyBlessedOneの冒頭,IfBTWPossibleで弾かれている.これは,軒端の荻が基準ノードである光源氏の配偶者であるためだ.「基準ノードの配偶者の配偶者を左手本人とするBTWを不可とする」というルールが@20190130に制定されている.これには例外があって,「基準ノードの配偶者が単親婚を持っている場合には左手本人とする」となっている.

「左手本人仮ノードが単親婚を持つ場合にはつねにBTWを構成する」という非常に強い条件があるが,これと同様に「左手本人仮ノードが系列優先ノードの場合はつねにBTWを構成する」という条件を付け加えてもよいのではないだろうか?⇒これで問題は解決した.軒端の荻と空蝉はいずれもBTW左手本人として光源氏と接合している.伊予介のカードがダブってしまうのはどうにも避けられないが,この図面には重婚同類循環が3つもあるので仕方ないだろう.

image

同上サンプルの#3 桐壷の更衣でNAMEBOX::TailSheddingのエラーが出た.TailSheddingの引数のdiffが負値になっている.diffには実ノードと仮ノードの世代差が入っている.diffが負になると調整ができないのでエラーになる.⇒ShiftDirectAbsoluteとAdjustTribeGenerationを止めるとこのエラーは消える.この2つの関数は多重が存在する場合には実行しないというのが本来の仕様でそれを暫定的に一度だけ実行するようにしているのだが,その妥当性を含めてこの辺りを精査する必要がある.

この処理を作動するように変更したのは,光源氏の法定親族図で三位中将系列の主系列参照チェーンが切れるというところからだ.この処理を停止すると今度はTRIBEBOX::adjustGenerationRangeで「先祖ノードが系列世代範囲を逸脱」というエラーが出るようになる.この関数は16回呼び出されているが,実行しなくても描画には影響しない.

光源氏の法定親族図では一度も呼び出されていない.三位中将のチェーン切れという問題も生じていない.全体図では一度呼び出されるだけだ.呼び出し16回というのは桐壷の更衣の全体図に限られている.系列ポテンシャルの設定はSetMinorTribeで実行しているので,ほとんど不要になっているのではないかと思われる.ただし,この関数は10箇所から呼び出されているので,よく使われている関数だ.

検証グラフ系を用いて系列間物理コネクションを修復する

主系列参照チェーンが途切れている,というより,系列間物理コネクションが切れている系列の発生に対処するために,TOPOLOGY:MakeLinearEdgeListという一度は廃棄された関数を掘り起こして改造を試みているところだ.主系列への参照設定をTRIBEBOX::setMajor関数に集中し,この関数の中で物理コネクションの検査を行い,グラフには物理的に接続している場合にのみ枝を追加するようにした.

この結果,AFTERMARGSAMEGENEフェーズでは,TRIBEBOX #1589 先祖=#1361 衛門督(箒木)(0)[13] 優先=#1702 空蝉(1)→#1351 空蝉(0) →主系列#1567:一院とTRIBEBOX #1627 先祖=#1355 三位中将(0)[18] 優先=#1711 夕顔(2)→#1674 夕顔(1) →主系列#1567:一院の2つの系列の物理コネクションが切れていることが判明した.

このうち,後者は事後に接続を回復しているが,前者は最後まで切断状態が継続している.AFTERMARGSAMEGENEのループは多重カードが存在する間はループするようになっているが,STOPCARDSHIFTが立っているために一度で抜けてしまっている.まず,これを見ておこう.重婚同類循環が存在する場合にはSTOPCARDSHIFTを立てるようになっている.STOPCARDSHIFTが立っていると,ループを一度で抜けてしまうだけでなく,以下の2行も実行されないようになっている.

ShiftDirectAbsolute(topology->tajugraph1->complist);
AdjustTribeGeneration();

この2行を実行すると三位中将系列の切断は解消するので,暫定的にこの制限を緩和しておこう.これで次の段階に進む準備が整った.⇒TribeTreeGraphのノード数が4,枝数も4しかない.⇒現行では「物理コネクション」がなくても主系列を設定できるようなルーズな仕様になっているためだ.しかし,これは必要な措置なのでこれに従うしかない.グラフの枝を主系列設定時に生成するのではなく,検査時にまとめて処理することにしよう.作り直して検査用の新しい関数を作った.

TRIBEBOX::EstablishMajorTribeChainという関数は@20190204に廃止されているが,この名前をTRIBELISTの関数として復活させることにする.いや,グラフオブジェクトはTOPOLOGYの所有なのでやはりTOPOLOGYのメンバーとしておいた方が無難だ.⇒一応動作するようになったが,いろいろと問題がある.

image

上記の出力は望んでいたものだが,やや変則的な動作になっている.EstablishMajorTribeChainでは連結成分に分解された衛門督系列を連結するための解として伊予介+空蝉の結婚を見つけ出しているのだが,もう一度ループを通すと,今度は三位中将系列で非連結が発生するようになってしまう.上の図はループに戻らずにそのまま描画まで進んだ場合の図面だ.⇒余分な処理を外すことによって動作するようになった.

  1. AFTERMARGSAMEGENEのループで,ShiftDirectAbsoluteとAdjustTribeGenerationは一回だけ実行するようにした
  2. TRIBEBOX::AlternateTribeRealNodeを廃止した
  3. DONTSORTTRIBEを廃止した
  4. sameGeneCyclesでもSTOPCARDSHIFTをオンにしないようにした

衛門督・伊予介系列が孤立してしまう事象

源氏物語全系譜6.1.ZELの法定親族図 #1 光源氏で以下の図のように衛門督系列と伊予介系列が孤立してしまうという事象が発生している.

image

伊予介系列は当初は軒端の荻を優先ノードとして始系列の一院系列に繋がっているが,上図では先祖ノードの伊予介を優先ノードとして衛門督系列の従系列に変わっている.衛門督の優先ノードは空蝉で一院系列の従系列になっているが,空蝉(1)が結婚を持っているため消去できないので物理的なコネクションを確立することができない状態だ.

これを解決する最善策は,衛門督系列を逆に伊予介系列の従系列とし,伊予介系列では軒端の荻を優先ノードに立てて一院系列につなぐという構図だが,現行論理ではそこまでのことはできない.軒端の荻は上図では一院系列の軒端の荻(0)とは世代差がある.これは,空蝉と軒端の荻がどちらも光源氏の配偶者であり,同世代に並ぶことを求められているためだ.しかし,衛門督を伊予介の従系列にすれば軒端の荻の世代を調整することも可能となる.

ともかく,現状で「主従系列間の物理コネクションが確立されていない状態」が検出できるようにする必要がある.「系列間の物理コネクション」を以下のように定義してみよう.

  1. 系列間物理コネクションには,①(LDRを含む)消去された仮ノードによる連結と,②BTWによる連結の2種がある(それしかない)
  2. 系列優先仮ノードと実ノードは仮ノードがLDRの場合を除き,同世代でなくてはならない
  3. 通常の場合,仮ノードは不可視,実ノードは可視である BTWによる連結では仮ノードが可視となる場合がある 逆婚姻関係では実ノードが不可視,仮ノードが可視となる
  4. 通常仮ノードと実ノードは同一カードを参照しているが,場合によっては別の(配偶者)カードを参照することもある

TRIBEBOX::IsConnectedとその下位関数DoesMajorTribePathExistは本来上記の検査を実施することを目的としているのだが,かなり甘いものになっている.DoesMajorTribePathExistでは検査の重複を避けるために始系列参照パスフラグ(majortribepath)というのを置いているが,あまり当てにならないので廃止した方がよいと思う.

TRIBEBOX::hasPhysicalConnectionという検査関数を作ってDoesMajorTribePathExistから呼び出すようにしてみた.この結果,衛門督系列では系列間の物理コネクションが完全に失われているということがわかった.さて,それではどうすればよいのか?一つの考え方としては,衛門督系列の空蝉(1)が結婚を持っているのに系列優先ノードになること自体を誤りとするという立場があり得る.この場合は衛門督は別の優先ノードを探さなくてはならないので,空蝉(1)の結婚から伊予介の従系列になっている可能性がある.

これはこれで一つの解決とは思われるが,結婚を持っているノードは系列優先ノードになれないという縛りは少しきつ過ぎるような気がする.系列優先ノードがそれしかない場合,相手のある結婚なら相手方に渡すという方策もあり得るが,単身婚の子どもがいる場合にはそれもできない.単身婚の子どもがいる場合でも,複数の親がいればそちらに渡すことも可能であるかもしれないが…

逆に言えば,単身婚の子どもがいてかつ親が一組しかない場合には優先ノードにはなれないということだろうか?いや,そんなはずはないはずだ.現行では逆婚姻関係というのも認められているのだから,従系列に本人ノードを残すという結合形態もあり得るのではないか?

グラフ理論的にこの問題を解くことを考えてみよう.まず,「すべての系列はなんらかの方法で(少なくとも1つの)他系列との物理的なコネクションを持つ」としよう.また,「従系列→主系列という方向は任意に変更可能」であるとしてみよう.この2つの仮定が成立するとすれば,以下の手順でつねに連結な有向木を得ることができる.

  1. すべての系列につき,任意の物理コネクションを確立する
  2. 系列を頂点とし系列間の物理コネクションを枝とするグラフGを生成する
  3. グラフGが連結ならば,→5に進む
  4. グラフGを連結成分に分解し,連結成分間の物理コネクションを確立する→グラフGが連結になるまでこれを繰り返す
  5. グラフGの枝に始系列からの向き付けを与え,有向木に転換する

ステップ2で生成されるグラフGが連結であるか否かが問題だ.もし,このグラフが連結であれば,そのグラフ上の任意の頂点を根点とする全域木が存在することは証明されているから,それを有向木に転換するのは難しくない.仮に,グラフGが連結でなかったとしても,それを連結成分に分解し,連結成分間の任意の物理コネクションを確立することは可能と考えられるから,この方法は確実に成立すると言ってよいだろう.

具体的な事例で考えれば,今の場合はステップ4で衛門督+伊予介系列とそれ以外の系列という2つの連結成分に分解されるはずだ.この中で2つの成分を連結できる要素は軒端の荻しかないということになるはずだから,衛門督系列→伊予介系列に向き付けを変更した上で,軒端の荻の物理コネクションを確立するための操作を実施するということになるのではないだろうか?かなり厄介そうではあるが,これができればグラフが非連結になるという事象は根絶されることになるはずだ.抜本的な解決策としてはこれしかないような気がする.

「結婚を持っているノードは系列優先ノードになれないという制約」の妥当性を見るために,空蝉+伊予介の結婚を解消し,その代わりに空蝉に単身婚の子どもを与えて描画してみた.

image

上図で衛門督系列の優先ノードはこれまで通り空蝉だが,問題なく接続している.従って,結婚を持っているノードは系列優先ノードにはなれないというのは正しくない.伊予介+空蝉の結婚の描画が難しいのは,世代的な矛盾(重婚同類循環)があるためと考えられる.

TRIBELIST::SortTribeListにはかつては「系列木の枝グラフをトラバースして線形枝リストを生成し系列枠の全順序を決定する」という処理が入っていたのだが,@20180821 辺りで廃止されている.⇒コードは残っている.TOPOLOGY::MakeLinearEdgeListだ.TribeTreeGraph,copygraph,tempgraphの3つの枝グラフを使っている.TribeTreeGraphはTRIBEBOX::setMajortribeで主系列を設定するタイミングで従系列→主系列の枝を追加している.

既存論理の瑕疵を発見した.BTWを構成するときには,事前にNAMEBOX::IfBTWPossibleで予備検定を行い,実施可能と判断してから実行に移るようになっているが,この関数の中ではBTWの当事者ノードが同世代であることをチェックしているにも関わらず,伊予介と空蝉のケースではそれから漏れていた.系列間のBTWが生じるとそれを使って系列接続関係が再構成され,系列ポテンシャルを調整して実仮ノードの世代を一致させるための系列シフトが実行される.伊予介系列は本来軒端の荻の仮ノード消去で一院系列に接合していたものが破棄されて衛門督系列に従属するように変化しているのはこのためだ.

BTW当事者の世代一致が無視されているのは,「左手本人仮ノードが単親婚を持つ場合にはつねにBTWを構成する」という理由による.この場合には無条件でBTW成立と判断しているが,明らかにやり過ぎと考えるしかない.「当事者の世代一致」という条件を「左手本人仮ノードが単親婚を持つ場合」よりも前方に配置してこのような誤動作を防止するようにした.これにより,孤立しているのは衛門督系列だけになった.

image

現状ではこの系列は有効な系列優先ノードを持たない状態なので,グラフを使った系列連結検定の対象となり,結合相手として系列順位では下位に当たる伊予介系列を見出すことができるだろう.そうすれば,この図面には非連結の部分がなくなり,図面として完成する.多分これがもっとも合理的な解法ではないかと思う.

ネカフェに出かけて拡張機能をダウンロードしてきたが,まだ足りないものがある

昨日もネカフェに出かけて,Visual Studio Installer Projectのための拡張機能をダウンロードしてきたのだが,まだ足りないものがある.MFCのパッケージが不足している.ネットには一応繋がっているので,インハウスで試してみよう.1.009MBあるのでおそらくダメなのではないかと思われるが… 30KB/秒くらいのスピードしか出ない.ときどき0KBまで落ちる… それでも2%まで進んだ.まぁ,望みは薄いがやらせておくことにしよう.さて,昨日の障害に戻ることにしよう.

「系列タイプ決定不能」という問題が起きているが,それ以前に,伊予介系列の優先ノードである軒端の荻がなんの属性も持っていないというのが問題だ.これは「IsPrimeboxOrNotを有効化」オプションのON/OFFとは関わりない事象だ.まず,これを追求する必要がある.軒端の荻の仮ノードは一度も操作された形跡がない.これはかなりまずいのではないか?⇒TRIBEBOX::GetMajorTribeChainという関数があるので,この関数でチェックできなくてはならないと思うのだが…

@20190204に廃止されたTRIBEBOX::EstablishMajorTribeChainという関数があるので復活させてみたが,効果はなかった.おそらく最大の問題は軒端の荻(0)と(1)の世代が異なるという点にあるのではないかと思う.TribeRelocationの20.AFTERMARGSAMEGENE 重婚同類グラフの後処理で以下を実施している.

  1. CheckTribeVerticalPosition 系列枠内ノードの垂直位置調整
  2. AlternateTribeRealNode 系列優先仮ノードと実ノードで世代差を調整
  3. TribeGhostName 系列枠の範囲内で消去可能な仮ノードを消去する
  4. BetweenTwoWomen 系列枠の範囲内で両手に花を構成する

ここで調整されるべきだろう.AlternateTribeRealNodeで伊予介系列の検査を実施した時点では実仮ノードの世代は一致している.衛門督 (箒木)の主系列を伊予介系列に設定する時点で系列シフトが発生しているのではないかと推定される.⇒衛門督の優先ノードは空蝉で主系列は一院.おそらく伊予介の多重を解消するためにカードシフトを実行したのではないかと推定される.伊予介のBTWが設定され,系列シフトが起きている.伊予介のBTWによって衛門督の優先ノードであった空蝉(1)が可視となり,逆に空蝉(1)→(0)のコネクションが切れてしまっている.

伊予介のBTWの結果,伊予介系列は優先#1366 伊予介(0)→#1702 空蝉(1) →主系列#1589:衛門督(箒木)という変則的な接続に変化している.これらの操作のどこに問題があると言えるのだろう?空蝉は一貫して衛門督系列の優先ノードだが,軒端の荻と同様,一度も仮ノード消去されたことがない.問題点を挙げてみよう.

  1. 空蝉も軒端の荻も仮ノード消去を受けていない 空蝉(1)が消去できないのは結婚を持っているため
  2. AFTERMARGSAMEGENEフェーズでは,TribeGhostNameで仮ノード消去を実施しているが,ここでは対象を系列枠内に限定している
  3. 従って,仮ノード消去による系列接続ではMakeUpTreeでその処理が実施されなくてはならない
  4. 現行ではBTWの優先度はとても高くなっていて,①関係するノード対の破棄,②姉妹婚の破棄,③シンメトリ婚の破棄,④ゴールデンカップルの破棄,⑤ZTYW婚の破棄が求められる
  5. 系列間BTWで系列シフトが発生している
  6. 系列間の物理的なコネクションが存在することを検証する仕組みが備わっていない つまり,始系列までの参照パスが検証されていない
  7. 現行でも系列接続関係をダイナミックに更新する仕組みは備わってはいるが,ある範囲をカバーする弥縫策に留まっているように思われる

空蝉(1)が消去できないのは結婚を持っているためだ.軒端の荻はEraseGhostをパスしているが,実際には消去されていない.EraseGhost→ MakeGhostNodeでは可視/不可視の調整をしているだけだ.EraseGhostは仮ノード消去の予備検査でEraseGhostNodeの中から呼び出されている.

「右枝ノードが結婚枠を親参照していない」

源氏物語全系譜6.1.ZELの法定親族図を基準ノード=#74 薫で開いて,NAMEBOX::DoublyBlessedOne→ MARGBOX::CheckLongTailからNAMEBOX::makeLongTailを実行して,結婚枠の右枝が結婚枠を親参照していないというエラーになる.この不良はNAMEBOX:BundleStringの中で発生している.この関数は「LDR束線分移動後束芯を一致させる」ためのもので,問題のノード#21950 浮舟(2)はLDRだ.#21929 中姫君(1)と#21950 浮舟(2)が束ねられている.LDR束に束ねられた線分はすべて先頭LDRを親参照するようになっている.これはLDR束全体が一体化したものとして操作される必要があるためだ.

つまり,このノードは結婚枠に含まれる描画要素ではあるが,実態はすでに外部にあると考えなくてはならない.従って,これはエラーではなくノーマルな状態として扱われるべきだろう.これを判定する基準は,「そのノードがLDR束線分に属し,LDR束先頭線分が別の結婚枠を参照している場合」ということになる. しかし,MARGBOX:CheckMarchainで「右枝ノードが結婚枠を親参照していない」という不良が検出されるときには,このノードはすでにLDRではなく,通常の「消去された仮ノード」に戻ってしまっている.

LDRでなくなったとき,ないし,LDR束から離脱した時点で親参照の付け替えがなされなくてはならないと考えられる.LDR束線分属性はBUNDLEDSTRING,LDR属性はELDERWIFEだが,BUNDLEDSTRINGの解除の方が先行するものと思われるので,その時点を特定してみよう.NAMEBOX::PairBoxGeneChangeで実仮世代差ゼロとなり,NAMEBOX::TailSheddingを受ける時点でリセットされている.BUNDLEDSTRINGをリセットしている場所は7箇所ある.個別対応するのも難しいので,resetghostbitsの中で一括処理するようにしてみよう.⇒対処した.

源氏の完全木テストが完了した.

image

フルスペック版の36分39秒に比べるとかなり遅い.完全参照リスト管理を外せばそこそこの数字が出る.

image

▲「IsPrimeboxOrNotを有効化」オプションをONにしたバージョンで源氏物語全系譜6.1.ZELの法定親族図を開いて,TRIBEBOX:DecideTribeで「系列タイプ決定不能」が発生する.障害系列はTRIBEBOX #1566 先祖=#1339 伊予介(0)[16] 優先=#1799 軒端の荻(1)→#1449 蔵人の少将(夕顔)(0)で主系列は#1634:蔵人の少将(夕顔)だ.しかし,これはあまり上等な選択とは言えない.蔵人の少将には親も子もなく,軒端の荻との結婚があるだけだ.この不良は「基準ノードの配偶者の外部婚を排斥」オプションをOFFにすれば解消する.しかし,情況は思っていたよりずっと深刻だ.

image

衛門督 (箒木)系列と伊予介系列は位置的にはほぼ接触しているが,始系列につながる連結線をまったく持っていない.これはかなりまずい事態だ.それでも非連結=0となっているのはなぜだろう?どうも根底から見直しが必要となるような形勢になってきた.連結/非連結は「始系列に至る実仮優先ノード経路が存在する場合を連結,そうでない場合を非連結とする」と定義されている.

ゴミ箱,UNDO,グラフ検証系を止めたベーシックZTの動作

リサイクルシステム,UNDOシステム,グラフ検証系を止めたZTベーシックの動作をチェックしているところだが,アプリ終了でnodl_floatのエラーが出ている.今回は「完全参照リスト管理」を搭載した状態でチェックしているところが前回と異なる点だ.参照リストは親オブジェクトが削除されても存続するという仕様になっていることがこの不良の原因と考えられる.~NODULEを修正して,ゴミ箱が未サポートのときには,増設スロットを含むすべてのスロットの下位オブジェクトを削除するようにしてこのエラーは解消したが,こんどは,CallSetCouplingPtrでCOUPLINGを削除した後,rootnodeをクリアするところで無限ループするようになってしまった.

rootnodeにはnullpointオブジェクトが入っている.このオブジェクトは地べたに置かれた根付きのオブジェクトだ.newで生成されたものではないという属性NOTAUTODELETEを持っているため削除できない.このオブジェクトのアドレスを格納しているrootnodeは昨日nodl_floatを修正して,すでに親ノードが死亡しているときには書き込みを行わないとしたため,空にできない状態になっている.ゴミ箱を使っていないときにはオブジェクトの削除=メモリからのパージを意味するから,死亡しているオブジェクトへの書き込みにはリスクがあるが,今の場合書き込むのはオブジェクトではなくリンクを格納しているアンカーなのでその場合だけは例外として処理されなくてはならない.⇒対処した.

これでrootnodeは始末できたが,こんどは_getblock_で「フリーメモリゼロ」というダンプが出るようになった.Nリングに残留オブジェクトが大量発生している.すべてfreeblockオブジェクトだ.なぜだろう?freeblockはCOUPLING:EraseFamilyTreeでfreeblock:ReleaseFreeBlockを使って完全に解放しているはずなのだが…

_getblock_では(!totalblock || !topblock)のとき,「フリーメモリゼロ」というエラーを返している.どうもまた何かメモリ管理に関する齟齬が発生しているようだ.⇒カウントの問題ではない.nodl_floatでIsAliveでないときは処理しないとしているためだ.⇒いや,違う.親ノードがIsAliveでないときは書き込みしない,ただし,対象ノードがNOTAUTODELETEであるときは,無条件で書き込むように修正した.これで「フリーメモリゼロ」も解消し,rootnodeも始末できた.

源氏物語全系譜6.1.ZELの傍系血族図 基準ノード=#51 若宮(匂宮の)でPAIRBOX::RepairCommonEndPointのエラーが出た.端点共有で始点不一致というエラーがPAIRBOX:#42220:#21900 明石の上(1)→#12444(0)と#42320:#22054 源氏宮(1)→#12988(0)で起きている.⇒これは起こり得るエラーだろう.この端点共有には3つのノード対が関係している.①明石の上,②源氏宮,③承香殿女御だが,元々は①承香殿女御,②源氏宮のようになっていた.明石の上と承香殿の始点の誤差は許容範囲内,承香殿と源氏宮の誤差も許容範囲内だが,明石の上と源氏宮では許容範囲を超えてしまう.

端点共有リストをノード対区間の大きさでソートしてやればおそらくこのようなエラーは(ある程度まで)回避できるのではないかと思われるが,必ずしも確実なものではない.許容範囲を倍にしてやればエラー自体は(ある程度)回避できるかもしれない… こちらの方が簡単だが,むしろ傷が深くなる可能性もある.基準となる始点座標を「固定」しない限りこのような変動は避けられない.

とりあえず,ソートしてみることにする.MoveSamePointではSwapBundledPairを実行しているが,この関数を「最大区間の付け替えを実施」するだけでなく,ソートまで実行するようにすればよい.この関数はPAIRBOX::MoveSamePoint,PAIRLIST::RepairPairBox,NAMEBOX::makePairBoxで使われている.⇒対処した.⇒最終的には上の3つのノード対の端点共有は崩れて分解してしまう.

▲同上サンプルの法定親族図を#74 薫でソートしてMARGBOX:CheckMarchainで停止した.結婚チェーン不整合が起きている.NAMEBOX::BuildMarChain→ CheckMarchainで不良が検出されている.NAMEBOX:#11679 八宮(0)の結婚チェーンで,要素は2つ.MARGBOX:#10223:#11679 八宮(0)+→#11951 大姫君(0)とMARGBOX:#8623:#11679 八宮(0)+#13583 浮舟の母(0)→ だ.前者は可視,後者は不可視でBTWの右手結婚枠.

「右枝ノードが結婚枠を親参照していない」というエラーが起きている.障害ノードはMARGBOX:#8623でYRにはNAMEBOX:#21950 浮舟(2)が入っている.浮舟(2)はこの結婚枠の最初の子どもなので当然結婚枠を親参照しているべきところだが… どこかで外れてしまっているのだろうか?⇒どうも最初から失敗しているようだ.

ネカフェでウクライナ・クライシスを観る

昨日の夕刻,ネカフェでVAIO2にVisual Studioをインストールしようと思って自転車で出かけた.ヨーカ堂の交差点を右に曲がってまっすぐ南に向かう.そこからは緩い勾配がだらだらと続き,ペダルを踏む力も段々と弱くなって最後自転車を降りてしまった.この道は街外れのスカイアルミの前を東西に走る道路に突き当たって止まる.この道になければその右側を通っている別の道か左側の道のどちらかしかないのだが,両方を試していたらへばってしまいそうなので,広い駐車場脇のテイクアウトショップの明かりに引かれ中に入って道を尋ねた.「ネカフェですか?この辺りにはなかったと思いますよ」と言われてすごすご帰りかけたらもう一人の店員が,「この交差点を左に進んで次の交差点で左に曲がると左にあります」と教えてくれた.(外でまごまごしていたら,出てきてもう一度今度は手ぶりで教えてくれた)

ネカフェの受付で会員カードの提示を求められたが,財布の中には入っていない.何か身分証明書のようなものはありますか?と言われて探したらマイナンバーカードが入っていた.喫煙席というのはすでになくなっていたが,別途入口の辺りに喫煙コーナーのようなものが設置してある.VS 2017 Communityは途中までダウンロードしてあったが,追加してVS 2019もインストールすることにした.

ダウンロードしている間手持ち無沙汰なので時間つぶしに「無料動画」というのを視聴してみることにした.「ウクライナ・クライシス」という比較的最近のネタを主題にした戦争物(ウクライナには友人もいる).インストールは一時間程度で完了したが,2時間近くの長い映画を最後まで見てしまった.(ネカフェで1000円掛けて一本の映画を見るのなら深谷シネマの1200円は高くないかも…)

Visual Studio 2017では従来のセットアッププロジェクトをサポートしていない.これを実行するにはMicrosoft Visual Studio Installer Projectを拡張機能としてインストールする必要がある.⇒このくらいはできるだろうと思ったが,Windows復元ポイントを作成していますというところでフリーズしてしまった.ネットには接続している… 中断したら,今度はVS 2017が起動できなくなってしまった.VS Installerを再実行する必要があるという.⇒「再開」で717MBを新たにダウンロードし始めた.150KB/秒くらいでダウンロードしている.終わるだろうか?スピードは段々落ちているので止まってしまうかもしれない.どうもやはりダメのようだ.30KB台まで落ちている…

▲DEFINETRASHCAN(リサイクル),DEFINEUNDOSYSTEM(UNDO),SUPPORTSIMPLEGRAPH(グラフ検証系)を停止したバージョンを走らせてアプリ起動→終了~NODEREFLIST→~DATALIST→… Dispose→ nodl_floatから(*moto)[edan] = NULLで停止した.edan=REFERIST=-2が入っている.親オブジェクトのmotoはすでに削除されている.⇒IsAliveであるかどうかをチェックするようにした.⇒今度は別のエラーが出るようになった.NODEREFLISTの親ノードスロットにデタラメな値が入っている.

UQモバイル月額1980円3GBのプランSから2980円10GBのプランRに切り替えた

最近は包括テストを割と頻繁にやっているので,tamo2さんから送られてきたVAIO2をテスト専用機に仕立ててみようと思ったのだが,Visual Studio 2017をダウンロードできなかった.現在使っているUQモバイルはMAX3Gという契約だが,VS 2017をフルインストールしようと思ったら,50GB以上の容量がなくてはならない.必要最小限までカットしてダウンロードサイズを7GBくらいまで切り詰めてみたが,ダウンロードを開始して間もなく,UQモバイルから「上限オーバー」の通知が届いた.その後は秒速30~0KBまで落ちて来たので布団を被って寝てしまったが,朝起きてみるとほとんど前日と変わらない状態で停止していた.

すでにWIMAX2+は解約してしまったので代替手段がない.UQモバイルは最終的には10GBで2980円という契約に切り替えるつもりだが,直ちには間に合わない.後はネカフェに行ってダウンロードするか,どこか公共WiFiを探すかしかない.確か,つい最近新装オープンしたばかりの市役所にはWiFiがあると聞いているのでそこに行くことも考えられるが,緊急事態宣言の渦中であまり人の集まるようなところには行きたくない.UQモバイルの契約変更を検討してみることにしよう.

月額1980円3GBのスマホプランSから月額2980円10GBのプランRに切り替えた.プランRの利点は容量を使い切ってもMAX1Mbpsが保証されるという点だ.もっともそれがどの程度実効性があるかは分からないが… 契約変更はネットで簡単に終わったが,回線は来月1日にならないと切り替わらない.それまで待ってもよいが,しばらく外出していないので,今日はネカフェに行ってみようかと思う.

リリース版を開発機にインストールした.これまでの版では走らせるたびにデスクトップ上に反例サンプルの山を築いてしまうので閉口していたのだが,ようやく多少まともな版が動くようになった.源氏の完全木テストが完了している.前回と同様デバッグモードだが,前回が34分37秒だから,大分遅くなっている.

image

12分というのは無視できない数字だ.余分なダンプなどをカットしてむしろ多少なりとも速くなるのではないかと思っていたのだが… 何が影響しているのだろう?今は,まだ時間効率を追求するときではないのでまぁ,こんなものだろうということにしておこう.VAIO2にZTをインストールして走らせてみたが,どうも画面のイメージがしっくりこない.メニュー項目の文字サイズがやけに大きくてぼやけている.逆に系図画面上のカードの文字は虫メガネが必要なくらい小さい.逆にカード画面の文字はバカでかく見える.

image

原因はわかった.VAIOの画面を外付けモニターにクローンで表示しているためだ.拡張スクリーンにすればノーマルな解像度で表示できる.

image

これなら申し分ない.PAIRBOX::CalcPairBoxを廃止して,もう一度完全木テストを実施してみた.

image

今度は前回と同等の数字になった.CalcPairBoxの廃止は,端点共有の先頭ノード対をつねに最大区間とするという変更と関わりがある.以前はCalcPairBoxで端点共有の包括矩形領域を計算してそれを先頭ノード対の包括矩形領域に書き込むようにしていたが,その計算が不要となった.