VAIOにOpen Live Writerを導入した

VAIOにOpen Live Writerをインストールしてサイトにアクセスできるようにした.また,VAIO2では途中で止まっていたVisual Studio Community 2017のインストールを再開した.どちらもネットアクセスにはスマホのテザリングを使っている.上限は10GBだが,まだ9.87GB残っているので余裕だ.月が変われば最大15GB/月まで高速で使えるようになる.VAIOは常時ネットに接続しているので,ネットアクセス用のサブ機,VAIO2は通常はLAN接続してテスト機として使えるだろう.大きいパッケージがスムースにダウンロードできるというのはありがたい.ただし,LANが遅い.開発用フォルダを転送するのに10分以上掛かる.最近の修正をフィックスしておこう.

  1. 軸線グラフではreferを使わない@20210212 2箇所
  2. CheckVerticalPosition中は系列ポテンシャルの変更不可@20210212 3箇所
  3. CheckNormalizedSectionで危険対同士の衝突は無視@20210213 1箇所
  4. goodsonが上位ノードの枠内で結婚点一致ならマージを廃止@20210214 → 廃止
  5. MoveLowerMargTreeではTYW枠は移動しない@20210215 1箇所
  6. 仮修正 11箇所,暫定 2箇所,if 0 3箇所,#if 1 1箇所
  7. OBSOLETE 10箇所

源氏物語全系譜6.1.ZELのZ木家系図を#74薫で開いて,MakeUpTree中にTRIBEBOX::GetRealnodeで実ノード不在エラーが起きる.これは,GetAlternativePrimeNodeで失敗していることを意味する.障害が起きているのはTRIBEBOX #1546 先祖=#1335 先帝(0)[4] 優先=源氏宮で,源氏宮の仮ノードは2つしかない.(0)は先帝系列,(1)は一院系列だが,先帝系列のtorder=3に対し,一院系列のtorderが4であるため不成立となっている.系列順位は①摂政太政大臣,②二条太政大臣,③先帝,④一院のようになっている.

torderの設定基準を基準ノードの重みではなく,先祖ノードの重みに変えてみた.⇒これで系列順位は,①摂政太政大臣,②一院,③二条太政大臣,④先帝のように変わり,#1614 源氏宮(1)→#1347 源氏宮(0) で主系列#1542:一院に接続できるようになった.多分これが正解なのではないかと思う.

image

同上サンプルの全体図を#9 冷泉院で開いて,上記と同じ場所で実ノード不在が発生する.障害が起きているのはTRIBEBOX #1552 先祖=#1397 常陸介(0)[7] 優先=常陸介で,系列順位は5位.優先ノードの常陸介の仮ノードは2つで,(0)は常陸介系列,(1)は大臣(橋姫)系列だ.大臣(橋姫)系列の順位は6位なので,現行ルールでは常陸介系列の主系列となることはできない.

TRIBEBOX::DecidePrimaryNodeではGetAlternativePrimeNodeで代替となる優先仮ノードを提案しているが,それが棄却された後,もう一度深堀りして代替案を見つけている.最終的にはこれで解決しているように思われるので,TRIBEBOX::GetRealnodeでは「主系列実ノード決定不能」の理由で停止しないようにした.

ZTシステム構成図7.ZELの全体図を#201 noduleで開いて,系列優先ノード決定不能が発生し,StackOverflowになる.TRIBELIST:SortTribeListByWeightで系列順位の基準を昨日の修正「系列優先ノードの重みに従ってソートする@20210216」に戻してやれば動作する.どう対処すればよいか?障害が起きているのはTRIBEBOX #906 先祖=#837 CARDTABLE(0)[3] 優先=BASETABLEだ.これはかなりおかしい.この系列は始系列のはずだ.しかし,系列種別はPRIME_PARENTになっている.いや,違う.この系列は始系列ではない.

系列順位を決定する基準は系列分解の手順に従うというのが本来の方式だ.系列優先ノードの重みないし,先祖ノードの重みをこの目的に使うのは不当である.系列順位はTribeDecompositionで決定している.⇒MakeUpTreeの中で実行している系列枠リストの並び替えを廃止.

同上サンプルを#87 NAMESORTでソートしてPAIRBOX:RepairCommonEndPointで停止した.CheckPairBoxのエラーが起きている.エラーを無視して描画は可能.「最大区間ノード対の逆転」が起きている.障害ノードはPAIRBOX #1887:#964 nodule(6)→ #956(1).「最大区間ノード対の逆転」が修復されていない.⇒SwapBundledPairが効いていない.

SwapBundledPairは動作しているが,まだ別のエラーが残っているのに中間で復帰しているためだ.SwapBundledPairを実行した時点でCheckSamePointで再検査するようにした.⇒CheckSamePointは純検査関数であるのに,setInclusiveを使っているのは問題がある.この関数はノード対の相対矩形領域を更新している.⇒CheckSamePointの中ではオブジェクトへの書き込みを行わないように修正した.

ZT BASICの完全木テストが通った

ZTシステム構成図7.ZELの全体図を#57 BASETABLEでソートして三極検定レッドラインオーバーが発生する.結婚枠枠の衝突が起きている模様だ.系列枠TRIBEBOX #912 先祖=#769 COUPLING(0)[6] 優先=#983 nodule(8)の衝突が止まらない.衝突は複数世代に渡るかなり複合的なもののように見える.

  1. gene=1 move=612  #1456 <>  #712
  2. gene=1 move=612  #678 <> #656
  3. gene=0 move=306  #655 <> #652
  4. gene=-1 move=465  #1463 <> #676
  5. gene=-1 move=306  #676 <> #702
  6. gene=-2 move=1096  #629 <> #634
  7. gene=-2 move=97  #633 <> #635
  8. ————————————————–
  9. gene=0 move=97  #655 <> #652
  10. gene=-1 move=179  #1452 <> #1468
  11. gene=-1 move=97  #676 <> #702
  12. gene=-2 move=1262  #633 <> #635
  13. gene=-4 move=15  #697 <> #660
  14. —————————————————–
  15. gene=1 move=612  #1456 <> #712
  16. gene=1 move=612  #678 <> #656
  17. gene=0 move=306   #655 <> #652
  18. ......

1周期が2ラウンドに渡る12個の衝突を含む長いサイクルが繰り返されている.この衝突サイクルを解析するのは至難の業だ(衝突以外の因子もからんでいる).しかし,おかしいのはレッドラインオーバーで一旦ブレークすると,その後は衝突は完全に影を潜めてしまうという点だ.何がどう変化しているのか?

障害が起きているのはMainExperimentのステージ【7.2】完全木検定:すべての系列を完全系列として正準化するで実行されるMakePairListCleanだ.⇒REDLINEの上限を現行の40から60に引き上げて解決した.REDLINEは概ね系図の世代数に依拠した数字だが,この処理は系列枠単位なので系列サイズによっても左右される.

同上サンプルを#87 NAMESORTでソートして,ノード対と実ノードの世代不一致で停止した.NAMEBOX::MakeUpPairBoxでは「makePairBoxで新規に生成されたノード対を構成」しているが,その中でTRIBEBOX::hasPhysicalConnectionにより,「実ノードを切り替え」が起きている.この関数の中でなぜ敢えてNAMEBOX:ChangeTribeRealnodeを実行しているのか,趣旨がよくわからない.

ChangeTribeRealnodeというのは,「系列優先実ノードを付け替える」ための関数,MakeUpPairBoxは新規に生成されたノード対のパラメータを整備するための関数だ.⇒この関数の中でIsPrimaryGhostでない場合はゼロ復帰しているので,呼び出していること自体は誤りではないが,ここでやるべきことではないような気がする.⇒「ここではChangeTribeRealnodeを実行しない@20210216」としておく.

#88 PARTIALNAMEで三極検定レッドラインオーバーが起きた.⇒まだ上限数が不足している.REDLINE値として「有効な結婚数」を適用するようにして解決した.

#91 TREEVIEWで系列優先実ノード不在が発生する.エラーを無視して実行すると,TRIBEBOX::IsMinorOfで主系列参照チェーンのループが起きる.TRIBEBOX #942 先祖=#821 NODELIST(0)の系列優先ノードが決定できない.TRIBEBOX #924 先祖=#769 COUPLING(0)[12]とNODELIST系列がどちらもNLIST< LISTNODE,CID>を優先ノードとしているためだ.

NLISTは2つしか仮ノードを持っていないので線形順序を与えることができない.⇒系列枠リストの順序に従い,前方系列しか主系列を選択できないという制限を与えて解決した.系列枠リストをソートするために,TRIBELIST::SortTribeListとは別にSortTribeListByWeightという関数を作り,系列優先仮ノードの重み(基準ノードからの距離)に従ってソートするようにした.

同上サンプルを開いてPAIRBOX::CancelCommonPairで停止する.(plist == bottomlist)というエラー.CancelCommonPairは端点共有を解除するための関数で「対象ノード対を現在のノード対リストから取り出し,最下段チャンネルに仮移動する」操作を行う.「現チャンネルが最下段の場合には最上段チャンネルに移動」に修正した.

同上サンプルを#84 FAMILYTREEでソートして,MPLCループレッドラインオーバーが発生した.TRIBEBOX #902 先祖=#784 FAMILYTREE(0)[1] 優先=#784 FAMILYTREE(0) 始系列でCheckMargBoxChangedが起き,以下のシーケンスを反復している.

  1. 不可視ノード移動x9件
  2. ————————————————
  3. 兄弟順位の逆転 #626
  4. 不可視枠の移動 move=-3100
  5. ————————————————
  6. goodsonを設定 goodson=#722

兄弟順位の逆転補正を停止すれば描画できる.兄弟順位逆転が起きているのはMARGBOX #626:#784 FAMILYTREE(0)+#716 familytree(0)→#725 BaseLink(0)だ.障害ノードはprevious=#721 linktable(0)とperson=#722 namesort(0)だ.

familytreeの子ども枠は幅広く,namesort(0)は+3100と-3099の間を往復運動している.namesortが子ども枠の中央付近に来るとgoodsonが交互に変化してシーソーになってしまうため運動が反復して停止しない.MARGBOX:checkBrotherOrderでは対象ノードがgoodsonであるときはつねにゼロ復帰するようにして解決した.

同上サンプルを#87 NAMESORTでソートしてTRIBEBOX:hasPhysicalConnectionで停止した.(!realnode->getghostbits(PRIMGHOST | ELDERWIFE)) で優先仮ノードがREALGHOST属性を持つのに実ノードが(PRIMGHOST | ELDERWIFE)ではないことが検出されている.⇒ここでは停止しないでダンプするだけとする.

image

重婚クラスタ図の出力がおかしい

重婚グラフ(多重グラフ2)の出力がおかしい.グラフをダンプすると節点数48,枝数54となっているが,エクスポートしたグラフ(重婚クラスタ図)をインポートして表示してみると,ノードが2つ足りない.#1848のcouplingと#1774のpagesetupだ.枝数54には#1846 noduleと#1848 couplingの自己ループ枝が含まれている.また,#1848 couplingy→ #1774 pagesetup,#1848 coupling→ #1768 familytreeの枝もある.#1774 pagesetupから出る枝は存在しない.婚姻グラフ(多重グラフ1)の連結成分数は48なので,重婚グラフの節点数と一致する.⇒SIMPLEGRAPH:ExportGraphで自己ループ枝は出力しないようにしてみたが,状態は変わらない.

TREEVIEW::sendUpdateDataではcouplingもpagesetupも作られている.ただし,LINKTABLE::ImportEndではカードテーブルPDBに登録されたカード数は46になっている.カード参照番号#3のpagesetupはlinktableで上書きされている.また,#27のcouplingは配列要素で上書きされてしまっている.ExportGraphではカード参照番号として成分番号を使っている.これが重複しているということなのだろうか?グラフ2をエクスポートする前に,sortComponentListでグラフ1の連結成分リストをソートしているが,成分番号の付け替えを実施していないのだろうか?⇒いや,やっているはずだ.⇒SIMPLEGRAPH:sortComponentListに論理ミスがあった.

image

これで正しい重婚クラスタ図を描画することができるようになったが,「先祖ノード絶対世代番号不一致」は相変わらず収まっていない.AdjustTribeGenerationをShiftDirectAbsoluteの実行に先駆けて実施すると,14あった世代差は2~6程度まで縮まる.最終的にループを抜けるときには1まで軽減される.AdjustTribeGenerationでは冒頭でSetAbsolutePotentialを実行している.これは「絶対世代番号系と物理世代番号系を一致させる」とあるので,この段階で問題は解決していなくてはならない.⇒あれこれ試してみたがうまくゆかない.一度バックアップに戻って出直そう.これまでの修正は以下の2点だ.

  1. SIMPLEGRAPH::ExportGraphで自己ループ枝を出力しない
  2. SIMPLEGRAPH::sortComponentListに論理ミス

ZT BASICでZTシステム構成図7.ZELの全体図を#1 couplingで開いて,TRIBEBOX::hasPhysicalConnectionで停止した.系列優先仮ノードがREALGHOSTを持つとき,(realnode->getrealnode() != primenod)という理由だ.⇒hasPhysicalConnectionを整理して,「系列優先仮ノードが実ノードで逆参照されていない場合」でも系列タイプがPRIME_INVERTでない場合は停止しないようにした.また,優先仮ノードが実ノードで別のノードから参照されている場合には,ChangeTribeRealnodeを試みるようにした.この事例では最終的には落ち着くところに落ち着いている.

同上サンプルを#2 kakeizuでソートしてMakePairListCleanでエラーが発生した.ループカウントオーバーが起きている.「兄弟順位の逆転」と「TYW枠の移動」が反復実行されている.前者ではNAMEBOX #747 tribelist(0)が149移動,TYW枠の移動はそれに見合う形で-149移動している.TYW枠の移動によって,兄弟順位の逆転が発生していると見てよい.兄弟順位の逆転はprevious=#747 tribelist(0) person=#984 TRIBELIST(1)で起きている.障害の起きているTYW枠はMARGBOX #1633:#747 tribelist(0)+→#983 treeview(3)だ.

TYW枠の移動量はRightContactMargTreeで求めている.この関数は6箇所で使われているが,NAMEBOX::GetRightContactでは,前方ノードとの接触距離をGetContactDistanceで測定している.MARGBOX::checkBrotherOrderではGetRightContactで同様の検査を実施している.NAMEBOX::IsLefMovePossibleでは「本人の第一配偶者が右移動不可の場合に限定」される.

MoveTooYoungWifeでは結婚点一致以外の除外条件はない.MARGBOX::CheckZeroPositionではZTYW婚が結婚点一致位置に移動可能かどうかを検査するためにRightContactMargTreeを使っている.GetRightContactでは内部でGetContactDistanceを使っているので,実質同等である.

ただし,MoveTooYoungWifeでは結婚枠を直接移動しているので,上位人名ノードには関わりがないはずであり,そうでないとしたら親参照パス不良ということになるのではないか?いや,むしろ人名ノードを移動するとき,TYWを共連れにしていることが問題なのではないか?本人ノード自体はRelativeで相対移動しているが,MoveLowerMargTreeで下流系を連れて移動している.⇒直下のTYW婚は移動しないようにした.

▲同上サンプルを#57 BASETABLEでソートして三極検定レッドラインオーバーになった.

ZTシステム構成図7.ZEL #15 selectedcardで水平スプリット

ZTシステム構成図7.ZELの全体図を#15 selectedcardで開いて,系統並び替えの出口検査で水平スプリットを検出.

この図面には6個のTYW婚が出現している.

  1. #2067:#2066 baselist基本世代枠(2)+→#773 baselist基本世代枠(0)
  2. #2131:#2130 topUndo(1)+→#767 topUndo(0)
  3. #2139:#2138 anod[](4)+→#1057 anod[](1)
  4. #2211:#2210 Bobject(3)+→#912 Bobject(0)
  5. #2219:#2218 Bobject(9)+→#1093 Bobject(1)
  6. #2311:#2310 nodule(24)+→#902 nodule(0)

スプリットの原因となっているのはbaselist基本世代枠だ.baselist基本世代枠は3つ仮ノードを持っている.(0) #773, (1) #1067, (2) #2066だ.(0)はtribelistの子ども,(2)はtopolgyの子ども,(1)がTYW本人ノードで配偶者GENELISTを持っている.うち,(2)はかけ離れた位置にある.(1)と(2)が同一セグメントと認定されるタイミングを調べてみよう.いや,違う.(1)は不可視でセグメント値を持っていない.消去された仮ノードだ.(2)はLDRで,(0)がTYW本人だ.(0)と(2)のセグメントブロックがマージされるタイミングでは下図のようになっている.

image

この操作自体には問題はない.問題はそれ以前に起きている.前方(画面右)の黒いブロックは144というセグメント値を持っている.その次の草色のブロックは29で,上記のタイミングでこのブロックは前方のブロック144と接触する位置まで移動しているが,その後方になる黒のブロックはいずれも144という値を持っている.つまり,すでにこの時点で誤りが発生している.

image

!解けた!ただし,この解はまだ,暫定的なものだ.MAXIMALGRAPH::mergeUpperSegmentで「goodsonが上位ノードの枠内にあり,結婚点が一致している場合は子ども枠上位ノードと接合」するという規則を一時的に止めることによって得られた結果だ.この修正が果たして一般的に通用するものであるかどうかは今のところ不明だ.⇒いや,これは外しても大丈夫なようだ.この条件に合致するものは相当あるが,なしでも問題なく解けている.この論理の問題点は対象結婚枠が「タイト」でなくても上位ノードと接合できるという点だ.

上記サンプルを#24 UNDOCHAINでソートして三極検定レッドラインオーバーが発生した.かなり無茶苦茶なひどい図面になっている.

image

SUWではなく,単純にブレークすれば正常な図面が出力される.

image

TRIBELIST::AdjustTribeGenerationで「先祖ノード絶対世代番号不一致」が大量発生している.⇒この問題は後から見ることにする.mergeUpperSegmentで上記の修正を元に戻せばエラーは解消するが,それでは元の木阿弥だ.UNDOCHAINのケースとselectedcardが両立するような解決案として,goodsonでマージする条件として対象結婚枠がIsElderWifeBoxではないという条件を付け加えた.これでどちらも通るようになった.

これが問題の完全解になっているとは思われないが,少なくともこれまでよりはましな解になっていることは確かだと思う.現行リリース版ではエラーが多発しているので,「バレンタイン・バージョン」と称する版を所内リリースした.

「先祖ノード絶対世代番号不一致」の問題に移ろう.この事象もよく分からないところがある.絶対世代番号と物理世代番号の間で14もの差が出ている.それだけでなく,エクスポートした重婚グラフもかなりおかしい.この図面は仕上がりで12世代だが,重婚グラフでは11世代しか出ていない.

image

そもそも先祖ノードが「配列要素」となっているのが意味不明.

image

ここには,couplingかないしCOUPLINGが来なくてはならないところなのだが… しかし,婚姻グラフ(多重グラフ1)の連結成分リストの出力は正しいように思われる.SIMPLEGRAPH:dumpComponentを書き直して,簡単なリストを出力する関数SIMPLEGRAPH::dumpComplistを作った.

SIMPLEGRAPH::dumpComplist 連結成分リスト sc=1 list=#1848 k COMPLIST 1848
   1 [0]coupling COUPLING
   2 [1]pagesetup PAGESETUP
   3 [1]familytree FAMILYTREE
   4 [2]topology TOPOLOGY
   5 [2]linktable
   6 [2]namesort NAMESORT
   7 [2]partialmap PARTIALNAME
   8 [2]undosys UNDOSYSTEM
   9 [2]extraslot2
  10 [3]SIMPLEGRAPH graph3 keisengraph graph2 graph1 tajugraph1 tajugraph2 tajugraph3 tempgraph copygraph
  11 [3]MARGTABLE MDB
  12 [3]UndoChain UNDOCHAIN UndoCurptr undochain
  13 [3]longtable RecordList
  14 [3]CARDTABLE PDB
  15 [3]tribelist TRIBELIST
  16 [4]complist
  17 [4]starttribe TRIBEBOX
  18 [4]treeview TREEVIEW
  19 [4]BASETABLE
  20 [4]undotop
  21 [4]baselist基本世代枠 GENELIST
  22 [4]nodelist NODELIST
  23 [4]anod[]配列
  24 [4]anod[]配列
  25 [4]edgelist
  26 [5]topUndo UNDONODE
  27 [5]配列要素 CARDLINK
  28 [5]EDGELIST
  29 [5]配列要素 MARGLINK
  30 [5]GENEBOX GENEBOX
  31 [5]COMPLIST
  32 [5]ARRAY
  33 [6]MARGBOX margbox
  34 [6]nlist
  35 [6]NAMEBOX nambox
  36 [6]anod[]
  37 [6]pairlist PAIRLIST
  38 [7]NLIST< LISTNODE,CID>
  39 [7]PAIRBOX PAIRBOX
  40 [8]LIST LIST
  41 [8]Bobject Bobject
  42 [9]所属グループ
  43 [9]衝突検定リング
  44 [9]圧縮検定リング
  45 [9]DATALIST DATALIST
  46 [9]描画Yリスト
  47 [9]親参照リスト
  48 [10]nodule

連結成分リスト 成分数=48 ノード数=86 世代数=11 min=0 max=10

世代数は11でこれは実際の系図出力より1少ない.この食い違いがどこで生じているのかを見ておこう.ノード数=86は実際のカード数188より大分少ないが,これは終端ノードを省いているためだ.これを追加したグラフを作ってもよいが,効率を落とすだけなので省くのが正解だと思う.世代数が1少ないというのも同じ理由だ.確かに省略されている分,間違い易い.

多重グラフ1の連結成分リストは完全に正しいと言ってよいだろう.重婚グラフは節点数が46で成分数48より2少ない.重婚グラフの節点は重婚クラスタであり,多重グラフ1の連結成分に他ならないのでこの食い違いは問題だ.落ちているのは,1 [0]coupling COUPLING と2 [1]pagesetup PAGESETUP のようだ.いずれにしても重婚グラフがまちがっているか,ないし,エクスポートでやり損なっているかのいずれかだ.

ZTシステム構成図7.ZELの軸線が通った

ZTシステム構成図7.ZELを#1 couplingで開いて,系統並び替え出口検査で垂直スプリットが検出される

従来論理のMakeHasseDiagramを廃止して,GetHasseDiagramと差し替えているが,TOPOLOGY::TestInevitableMultiZeroとVerticallyTightenHasseDiagramで実行していたSIMPLEGRAPH::sortComponentListを継承していなかった.GetHasseDiagramの実行後にSetAbsoluteGenerationとsortComponentListを実行することでスプリットは解消した.

同上サンプルで多重カード3件が残る.うち1件(COUPLING)は重婚クラスタ循環に起因する不可避の多重だが,残り2件(NLIST < LISTNODE,CID>とnodule)は同世代に多重カードが発生しているので,回避できなくてはならない.原因を調べてみよう.まず,noduleから見てゆこう.

noduleの仮ノードは(0)~(103)まである.ダミー枠を除いても17個ある.うち,(0)と(3)を除く15個はLDRだ.(0)は仮ノード消去の実ノードですべての親子連結線はここに集まっている.このノードはTOOYOUNGWIFE属性(TYW転換された抽出結婚枠とその本人)も持っている.(3)は軸線ノードだが,外部からは参照されていない.(16)は「LDRチェーン末尾に接続するTYW結婚枠を上位人名枠から参照」している.多重カードの削減はメインループのTOPOLOGY::ReduceMultiCardで実施しているが,実効性がない.これはおそらく(0)が結婚を持っているためだろう.

特に,単身婚の子どもを持っていることが効いているのではないか?血統軸線図の構築フェーズBUILDCENTERLINEは17で,GODOWNSTREAMの11より後に実行されるので軸線ノードが決定するときには結婚枠の割当はすでに決まってしまっている.しかし,軸線ノードの持つMOTHERLESSではない結婚枠をMargBoxTransferで移転したような技法を使えば,単身婚を軸線に移動させることはできるはずだ.⇒うまくいった.一発で2つとも多重が消えた!軸線も完全に通った.これが通れば,大概のサンプルはこなせるだろう…

image

上記サンプルを#8 linktableでソートして,TRIBELIST:MakePairListCleanで無限ループが発生した.MDB(2)→(1)とMDB(3)→(1)が競合している.どちらも危険対属性(CRITICALPAIR)でPAIRLIST::VerifyPairBoxで一方が別チャンネルに移動した後,RepairVerticalInverseで元のチャンネルに戻されている.⇒危険対の操作はCheckInverseCycleに任せて,CheckNormalizedSectionでは無視することにした.⇒解決.

▲同上サンプルを#15 selectedcardで開いて,系統並び替えの出口検査で水平スプリットが検出された.⇒確かにひどいスプリットが発生している.

image

障害が起きているのは始系列で,先祖ノードはCOUPLINGだ.⇒TRIBEBOX::CheckGeneSplitの検査は結婚枠単位だが,幅の広い結婚枠が3つあるため領域が被覆された状態になっている.BaseLink(0)の入っている枠は(-118, 12109),PDB(0)の枠は(676, 10024),pagesetup(0)は(-298, 9548)もある.この種の空洞はこの関数では検出できない.伸びた兄弟枠(ルーズな結婚枠)を詰めるのは水平セグメント検定の分担だ.何がそれを妨げているのだろう?⇒原因がTYW婚にあることは明らかだ.実際,TYW婚を完全禁止すれば問題なく描画できる.

image

TYW婚はシンメトリ婚と同様の「フロート婚」であり,どのような位置にも水平移動できるが,その状態を完全に捕捉するのは難しい.むしろ,水平セグメント検定の対象から除外してしまうということが考えられる.つまり,ほったらかしにするという方針だ.言い換えれば,既定の木構造の規制範囲外とする.逆に言えば,「衝突を起こさない限りどこにいてもよい」ということになる.フロート婚は一般に衝突を起こした場合には解体されることになっているので,これでも特に問題ないのではないか?ものは試しなのでやってみたいが,かなり大きい修正なのでバックアップを取ってから始めるのが妥当だろう.

MargBoxTransferで軸線枠を移動する

ZTシステム構成図7.ZELの全体図を#30 MDBで開いてMARGBOX:GetUpperNodeで停止する.「親ノード不在」が起きている.⇒TOPOLOGY::CallBuildShaftLineで軸線枠を設定する際に,結婚枠の親参照パスを付け替えて上位軸線ノードを参照するように修正してエラーは解消したが,絶対座標変換後のCheckAtypicalMarriage(非類型的結婚処理)でエラーになる.

上記サンプルの全体図 #30 MDBでTOPOLOGY:CheckAtypicalMarriageの「stave異常値」エラーが起きる.これは結婚連結線の割当てに失敗したことを意味する.障害が起きているのは,NAMEBOX #772 MDB(0),NAMEBOX #1261 MDB(2)とNAMEBOX #1229 MARGTABLE(1)だ.MDBは親を4組持っている.①topology+TOPOLOGY,②linktable,③namesort+NAMESORT,namesortだ.軸線はnamesortになっているが,topologyという選択もあったはずだ.

この図面では多重が2件発生している.MDBとMARGTABLEだ.topology→MDBは子どもがいないので消去できるはずなのだが,多重になっている.MARGTABLEには親はいない.単身婚の子どもBASETABLEとMDBとの結婚の子どもがいる.これらの子どもはMDB(2)の下にいるが,MARGTABLEとMDB(2)は連結されていない.MDB(0)というカードが可視で残ってしまっていることが混乱の原因なのではないかという気がする.

CallBuildShaftLineでは軸線枠の移動が5件発生している.①MARGBOX #689:#798 COUPLING(0)+#1212 coupling(1)→#747 pagesetup(0),②MARGBOX #655:#745 familytree(0)+#1218 FAMILYTREE(1)→#754 BaseLink(0),③mbox=MARGBOX #704:#772 MDB(0)+#1229 MARGTABLE(1)→#908 anod[]配列(0),④MARGBOX #683:#867 配列要素(0)+#1230 MARGLINK(1)→#1231 nodule(3),⑤MARGBOX #715:#880 margbox(0)+#1232 MARGBOX(1)→#882 owner(0).

これらはすべて有配偶者婚だが,stave異常値に関係しているのは,③のMDB(0)+MARGTABLE(1)のように思われる.出力図面で見ると,結婚枠は移動しているが,MARGTABLE(1)の隣接位置に残ったままになっている.明らかに結婚の移動と同時に配偶者も移動する必要がある.MARGBOX::MargBoxTransferという関数があるので,これを使ってみよう.⇒解決した.

image

ただし,この図面にはまだいくつか疑問が残っている.まず,重婚同類1,重婚1というダンプが出ているが,それらしきものが見当たらない.⇒いや,あった.COUPLINGだ.COUPLING はクラス名だが,クラス名はクラスの(代表)インスタンスと婚姻関係を結ぶことになっている.COUPLINGの孫にextraslot2というCOUPLINGのインスタンスがあるためだ.従って,この図面では多重は不可避であり,重婚同類1というのは正しい.

MDBはオブジェクトであり,すべてのオブジェクトはnoduleないしNODULEから派生しているはずなのに,軸線が届いていないのはなぜか?実際,上図でも右下コーナーに2枚のカードがブルー表示されている.これは養親子系血族であることを示しているのだが… 軸線の選び方が悪いのか,あるいは単なるデータの不備か?軸線の終端ノードの_goodson は子どもがいないのでここで止まるのは仕方ないが,別の経路があったのではないか?

MDBの孫の配列要素はnoduleという子どもを持っているが,最長鎖の長さでは同じになってしまうために選択されなかったのだろう.noduleは「クラス」なので,親はすべてクラスかないしクラス+オブジェクトだ.MDBの軸線の下流系はすべてオブジェクトばかりでnoduleに接続していない.MDBの軸線上のノードは先祖ノードのCOUPLINGを除くとすべてオブジェクトだ.先祖ノードをcouplingに取れば首尾一貫するのだが… 多分父系/母系を指定できるようになればある程度選択可能になるとは思われる…

上記サンプルを#1 couplingでソートしてMARGBOX:setownerで停止した.結婚枠とownerの世代が整合しないというエラーだ.⇒軸線グラフ検定は重婚クラスタ検定より前に実施されるため,まだ絶対世代番号は確定していない.この段階では世代の不整合は見過ごしてもよいのではないだろうか?⇒エラーを無視して描画は可能.MARGBOX::setownerで出る「結婚枠世代不一致」以外にも,「兄弟世代番号不一致」がMARGBOX:checkVerticalPositionで多数発生する.

checkVerticalPositionでは検査の直前に結婚枠と兄弟ノードの世代番号を一致させる処理を実行しているのだが… このエラーの原因はネストした処理の中で系列ポテンシャルが更新されているためだ.本来CheckVerticalPosition中は「系列優先実仮ノード世代差の補正はここでは行なわない」としているのだが,穴が空いているところが(複数箇所)あった.

「CheckVerticalPosition中は系列ポテンシャルの変更不可@20210212」としてエラーは解消した.MARGBOX:CheckVerticalPositionの出口ではSAMEGENEMARRIAGEフェーズでのみTRIBEBOX::adjustGenerationRangeを実行しないとしていたが,これに加えてAFTERMARGSAMEGENEフェーズの場合も同様に抑制するようにした.

image

一応描画はできるようになったが,2つ問題がある.①画面下部で垂直スプリットが発生している,②軸線が通っていない.まず,①の問題から見てゆくことにしよう.絶対世代番号はLIST[8]→ DATALIST[9]→ nodule[10]となっているが,実際にはLIST[8]→ [9]→ DATALIST[10]→ [11]→ [12]→ nodule(3)[13]のように伸びてしまっている.

noduleは(0)と(3)で多重になっているが,世代的には(0)の方が正しい.LISTとDATALISTには同名で♂型と♀型の2種があるので混乱するが,リネームしないでこのまま進めよう.まず,DATALIST♂がなぜシフトされているのかを見ておこう.重婚クラスタ図を出力すると,下図を得る.

image

これは重婚グラフと呼ばれるもので,ShiftDirectAbsoluteでは婚姻グラフの連結成分リストを基準に世代割当てを実施している.上図で各カードの右肩に付いている数字は,グラフ節点の「距離数」と「絶対世代番号」だ.距離数はすでに正規化しているので,世代番号と一致している.この値は,婚姻グラフの連結成分リストの要素(重婚クラスタ)にも転記されているはずだ.というか,重婚グラフの節点は婚姻グラフの連結成分に他ならないので,当然この値が設定されていると考えてよい.

UQモバイルをスマホプランRからくりこしプランMに切り替えた

UQモバイルの契約を変更して,スマホプランRからくりこしプランMに切り替えた.プランRが10GB 2980円/月に対し,プランMは2480円で15GBまで使える上,使わなかった分は翌月に繰り越せるというのだから断然有利だ.容量オーバーになったときの最大転送速度はどちらも1Mbpsで,このスピードがあれば通常のブラウジングやメールの送受信には不自由しない.UQモバイルには「節約モード」というのがあるので,普段は1Mbpsでやりくりし,サイトへのアップロードや動画にアクセスするときだけ「高速モード」を使うことにする.楽天モバイルも熊谷までは来ているが,ここまで届くようになるのはいつのことやら…

ZTシステム構成図7.ZELをMDB @30で開いて,MARGBOX:CheckMarchainで「上位人名ノード不整合」のエラーが出た.

軸線グラフを生成するときの親子枝には関係する結婚リンク情報が含まれている.従って,A→Bの親子関係が複数存在する場合には親子枝も複数発生する.しかし,軸線グラフのトポロジーでは多重枝は意味がないので,「親子関係の重複登録は行わない」としたのだが,「軸線ノードでMOTHERLESSでない」というエラーが出ている.つまり,軸線枠を配偶者が所有するという状態になっている.これを回避するにはどうすればよいか?

先に進む前に最近の修正をフィックスしておこう.仕掛りのオプションには以下がある.

  1. ADG一般の最長鎖検定をサポートする@20210207 1箇所
  2. VerticallyTightenHasseDiagramを廃止する@20210209 1箇所
  3. GoodSonをシフトしたときはgoodson解除しない@20210209 2箇所
  4. CARDLINKが軸線でもjikusenでないNAMEBOXは可とする@20210209 1箇所
  5. ESTABLISHMAINEXPERIMENT@20210210 4箇所
  6. GetHasseDiagramで推移枝をすべて削除する@20210210 2箇所

TOPOLOGY::CallBuildShaftLineの中から呼び出されているBuildShaftLineを廃止し,CallBuildShaftLineでは軸線グラフの反鎖リストを直接参照して,軸線ノードを決定するように書き換えた.このとき,軸線グラフの枝に埋め込んでいた結婚枠への参照を使わずに軸線枠を決定できるようにした.これで軸線ノードと軸線枠を軸線グラフから直接決定できるようになったが,MOTHERLESSの問題に対処する必要がある.CheckMarchainで「上位人名ノード不整合」エラーが出た後もエラ-は延々と続き収拾がつかないので,setGoodSonを止めて以下を得た.

image

エラーは解消したが,軸線は通っていない.CallBuildShaftLineで軸線枠がMOTHERLESSの場合,親の拡張子ども枠に移動するようにして軸線は通るようになったが,別のエラーが発生している.下図はSUW(ShowUnderWear)で強制描画したものだ.

image

PAIRBOX::SwapBundledPairでCheckNoCommonEndPointのエラーが発生している.この問題は軸線とはまったく別個の問題と考えられるので別途シューティングする必要がある.

ZTシステム構成図7.ZELの直系血族図を#30 MDBで開いて,PAIRBOX::SwapBundledPairで停止する.この関数は共有端点束のノード対を区間の長さによってソートするものだが,予備的な検査で共有禁止ノード対が検出されたために停止している.障害ノードはPAIRBOX #1440:#1415 nodule(14)→#1174(4)だが,このノードは端点共有の代表ノード対だ.このようなノード対が複数存在する場合にも対応できるようにSwapBundledPairを整理して,ソートしてから共有禁止ノード対を見るようにした.

移動対象ノード対はPAIRBOX #1414:#1381 nodule(10)→ #1174(4)だ.この後,RepairCommonEndPointの出口のCheckPairBoxで「端点一致でsamepointゼロ」のエラーになる.⇒PAIRBOX::searchCommonPairに不備があった.「NOCOMMONPAIRノード対は端点共有できない@20210211」のように修正して解決した.

image

▲上記サンプルの全体図を#30 MDBで開いてMARGBOX:GetUpperNodeで停止した.「親ノード不在」が起きている.

短い軸線・伸びる軸線を描画する

STAGE6.ZELをNLIST LISTNODE@61でソートすると,SIMPLEGRAPH:GetLongestChainで無限ループが発生する.「反鎖リスト(同世代ノードリスト)を生成する」の段で,「重複パス上の(基準ノード以外の)任意のノードを削除する」の操作に失敗している.ループに入る直前のグラフをインポートすると下図のようにすでに最長鎖のみの状態になっている.

image

しかし,この図面はdumpgraphと内容が一致しない.ダンプでは節点数=6 枝数=8となっているのに,図面では11点も表示されている.

デスクトップ上のCSVを削除して作り直ししたら,開けなくなった.⇒CSVをインポートしたときも同じ動作になる.つまり,GetLongestChainで無限ループしている.CSVファイルをテキストエディタで開いてみると,確かにLISTは親を2つ持っている.NLISTとnlistだ.その後は,LIST→DATALIST→nodule→NODULEのように単線になっている.最下位のNODULEは自己ループを持っている.⇒初歩的な論理ミスがあった.下図のようになるのが本当だ.

image

仕上がりはこんな感じだ.

image

NLISTは「この図面」では親を持たないので先祖ノードになっているが,軸線図としては正しい.もう一つ反例がある.#201 noduleだ.このCSV(ループ直前でエクスポート)は別アプリで開けた.

image

反鎖リストの長さは11で,データ数は1, 1, 1, 1, 1, 4, 5, 4, 4, 1, 1となっている.上の図とかなり異なる並びになっているのは,世代番号によって区分しているためだ.⇒GetLongestChainにもう一つ誤りがあった.ループ中でノードが削除される場合があるのに,次のノードを取り出すのに削除されたノードを参照していた.⇒処理に入るまえに次ノードをあらかじめ取り出すようにして解決したが,まだ不具合が残っている.TREEVIEW::baseboxが空になってしまう.

この人名枠は昨日新設したSelectBaseBoxで設定しているが,初期ステージで設定したnodule(0)がExtractBox2LDRで削除され空の状態になっている.TREEVIEW::CleanSansyoの中で対象オブジェクトがbaseboxの場合にはSelectBaseBoxを実行するようした.これで問題は解決したが,BUILDCENTERLINEフェーズでCallBuildShaftLineを実行した後も,SelectBaseBoxを実行するようにした.

同上サンプルの親族種別=5(法定親族図) #1 name=couplingでソートして,TOPOLOGY::FindJikusenAncestorで停止した.軸線グラフ上に基準ノードが存在しないというエラーだ.MakeParentChildGraphで生成した直系血族グラフをエクスポートして確認しておこう.

image

節点数26,枝数32で基準ノードも健在だ.GetLongestChainの結果を見てみよう.⇒ダメだ.壊滅している.

image

GetLongestChainの中から呼び出されているGetHasseDiagramの出力を見てみよう.GetHasseDiagramでは絶対世代番号を確定し,推移枝を除去する.

image

総点数は変化していない.次の反鎖リスト(同世代ノードリスト)を生成するという段で失敗しているようだ.このブロックでは重複パスを削減してグラフを単線化することを行っている.パスの削減は一世代づつ実施され,そのたびにMakeAntiChainListで反鎖リストを更新して単線になっているかどうかをチェックしている.MakeAntiChainListではCOMPLISTを使って反鎖リストを生成しているだけで,節点や枝の操作は行っていない.最初に2段目のpagesetupが削除される.ノード削除後,グラフは下図のように変化する.

image

いや,違う.削除されたのはpagesetupではなくて,familytreeだ.確かにこれはまずいかもしれない.familytreeが削除されると,coupling→pagesetupが直結して,最長鎖が短縮してしまう.しかし,仮に短くなったとしても最終出力が得られなくてはならない.まず,こちらの方を先に調べることにする.この後は下図のようになる.

image

軸線が短縮してしまうのは仕方ない.pairlistとnlistが残っているのは末裔ノードとしてロックされているからだ.後はこの2つのノードを削除するだけなのだが,どうなるのだろう?末裔ノードはpairlistとnlistの他にnoduleがある.重複パスを削減対象となったノードは自己ループを持っていても削除される.この3つのノードには優劣はない.重複パスカットで見ているのは「基準ノードは削除されない」という一点だけだ.というのは,パスが重複している限りはどのパスを選択しても到達可能と考えられるからだ.しかし,今の場合は少し事情が違う.

pairlistとnlistはnoduleと同位ではあるが,noduleの方は「パスを持っている」だけの優位性がある.従って,「孤立点となっている場合には削除」としなくてはならないだろう.DeleteIsolatedNodeでは孤立点は削除しているが,自己ループを持っている限りは削除されない.これを修正して「自己ループしか持たない孤立ノードも削除対象」とするのが早いのではないか?⇒IsDeadEndPointという関数を新設して,「パスを失った末裔ノード」つまり,自己ループだけになったノードを検出できるようにした.これで一応動くようになって,下図が出力された.

image

一応これはこれで筋は通っているが,やはり最長軸線と呼ぶのには抵抗がある.推移枝をすべて削除してしまえばこのようなことは起こらないが,そうすると軸線が引けない場合が発生する可能性がある.どうすればよいか?現行論理では重複パスのカットでは枝ではなく節点を対象に削除しているので,その節点が接続している枝が推移枝しか持たないのかどうかということはにわかには分からない.

しかし,最長鎖には推移枝を含まないと言い切れるかどうかも疑問だ.どのノードを残すべきかの判定が必要になる.いや,そもそも,その枝以外ない場合は推移枝を残すという方式が間違っている.ここで削除したいのは,まさにそのような枝であり,それをあらかじめ排除しておけばこのような問題は発生しない.⇒GetHasseDiagramで推移枝は無条件に削除するようにした.この結果,下図の出力を得た.

image

これが正解だ.昨日のサンプルにも「伸びた軸線図」がいくつかあるが,すべて間違いだと思う.「短い軸線」が存在するのは避けられないが,「伸びる」ということは原理的にあり得ない.なぜなら,伸びた軸線があるとすれば,必ずそれを代替する伸びていない軸線があるはずであるからだ.GetHasseDiagramは2箇所で使われている.①血統軸線図,②重婚クラスタ検定だが,少なくとも血統軸線図の場合はこの方式で間違いない.Stage6.zelの完全木テストが通った.

image

実際の出力を見ると,かなり「伸びた軸線」が発生している.これは避けられないものなのかどうか?チェックする必要がある.下図はStage6.zelをTreeViewでソートしたものだが,軸線は伸びている.

image   image

一見すると伸びない軸線が存在するように見えるが,それらはTreeViewを通っていない.血統軸線図の検定を行うときの対象グラフはそもそも直系血族図なので,これらのノードはグラフ上に現れない.実際,TreeViewの直系血族図(上の右図)に含まれるのは,軸線上のノード8点とpagesetupの1点だけだ.

▲ZTシステム構成図7.ZELをMDB @30で開いて,MARGBOX:CheckMarchainで「上位人名ノード不整合」のエラーが出た.

「 非多重グラフで多重枝の登録は不可 」というエラーが出ているので,TOPOLOGY::MakeParentChildGraphで「親子関係の重複登録は行わない@20210210」としたが,果たして問題ないだろうか?一人の人物が,同じ子どもを対象とする複数の養子関係を結ぶということはあり得るので,A→Bという親子関係は異なる結婚に関係して複数あり得ると考えるべきなのではないか?しかし,現行論理では多分多重カードを許したとしても,そこまでは対応していないものと思われる.あるいは,このサンプルではそれが必要になるのだろうか?「軸線ノードでMOTHERLESSでない」というエラーも起きている.

MOTHERLESSというのは「配偶者を持たないか隠蔽された本人直下の単親婚子ども枠」となっているが,本人直下の子ども枠は有配偶者の場合でもMOTHERLESSとされるのではなかったろうか?実際,このエラーメッセージはそのことを言っているものと思われる.多重枝を持つのはよいが,それをハンドリングするのが難しい.いよいよ奥の手を使うときが来たのではないだろうか?

重婚クラスタ図と既存ハッセ図を比較する

CSVファイルをインポートすると,どこかでこのファイルに書き込みを実行している.通常系図ファイルはDLL側でオープンされるが,CSVファイルの場合は,VB側でオープンされ,VBで読み取ったレコードがDLL側に送られるようになっている.CSVファイルを読み取り専用に設定して開いた場合には書き込みは行われない.ただし,エラーも発生しない.⇒テストはリリース版で実行しているが,リリース版のコードにテスト用のコードが残っていて,書き込みを実施しているのではないか?リリース版では少なくもテスト用のエクスポートは止めておかなくてはならない.これではテストにならないので,もう一度リリース版を作り直してみよう.⇒Version 2.2.0.025 Release 2021-02-09を所内解放した.

TribeRelocationのステージ【4】重婚同類グラフ検定でBuildSameGeneMarriageGraphを実行して生成された「重婚クラスタグラフ」をインポートして表示すると下図を得る.

image

節点数27,枝数34の非循環的有向グラフだ.これからGetHasseDiagramでハッセ図を生成して得られる図面が重婚クラスタ図だが,どうもうまくいっていない.節点数は変化していないが,すべての枝を失ってしまっている.

image

どこで失敗しているのだろう?かなりおかしい.多重クラスタグラフがいつの間にか軸線図グラフにすり替わっている.いや,勘違いだ.GetHasseDiagramは血統軸線図検定の中でも呼び出されている.⇒SIMPLEGRAPH::ExportGraphが動作していない.TOPOLOGY:SaveClusterGraphなら保存できる.

ExportGraphは不要なフィールドを省いてコラム数を11まで削減したものだが,少なくとも軸線図ではこれで動いている.⇒SIMPLEGRAPH:ExportGraphの共通ブロックにCARDLINKを使っているところがあった.場合分けしなくはならない.⇒多重クラスタグラフが取れた.多重クラスタ図も作れる.下図左はGetHasseDiagramで出力した重婚クラスタ図,右は既存ハッセ図検定の出力.

image   

節点数は27で同じ,枝数は30に減少している.世代数は10で既存ハッセ図検定の出力と同じだ.比較してみよう.2つの図面の基本的な違いは,推移枝をカットする位置と思われる.重婚クラスタ図では下流でカットし,既存ハッセ図では上流でカットするようになっている.しかし,この違いは必ずしクラスタ検定と既存ハッセ図検定の差という訳ではない.GetHasseDiagram(新設した関数)で引数のseed(起点)を変えてやると下図のような図式が出力される.

image

ただし,GetHasseDiagramの中で実施している上流検定と下流検定の順序も入れ替えている.つまり,出力結果の図式は手順によって変わるということが言える.現行では推移枝を無差別に削除しているが,その枝が端点ノードの唯一の枝の場合は削除しないように変えてみよう.

image

大分それらしくなってきたので,この方向でもう少し作業を進めることにしよう.TestInevitableMultiZeroとVerticallyTightenHasseDiagramを廃止して,GetHasseDiagramに置き換えた.出力を見てみよう.左が現在,右が従来方式だ.

image   image

3段目のundosysは本来4人兄弟なのだが,従来方式ではそのうちの2人が抜けて下の方に移動してしまっている.これは,少なくともこの図面の制作意図には反しているように思われる.このサンプルの原図であるZTモジュール構成図は,モジュール構造を可視化することを目的とするものであるからだ.どちらの図面も軸線が複線になってしまっている.世代関係を維持しながら,この軸線を通すためには,どうしてもnoduleを3世代分垂直シフトする必要がある.垂直シフトを許すとフロート婚が発生する可能性があるために現行では禁止されているのだが,それを解除するとどうなるかを見てみよう.⇒まだエラーは出ているが通った.

image

これでよいのではないかと思う.すべてのノードが重婚クラスタ検定で割り当てた絶対世代番号の位置に配置されている.これができれば,問題はほぼ解決したも同然だ.どんな大風が吹いてもびくともしない構造物が作れそうだ.

STAGE6.ZELを#6 undosysで開いて,MARGBOX::setgoodsonのエラーが出る.(PHASE > CLEARTABLE && GoodSon && (!goodson || !goodson->GoodBox) && !IsExtractDummy() && !OnSetGoodSon && !OnRestoreExtractBox && !OnBuildShaftLine && IsVital() && !OnsetGoodSibling && !OnCancelBetweenTwo) という理由だ.つまり,「GoodSonを訳もなく空にしてはならない」という意味だ.

コメントには「対象ノードがgoodsonである場合はgoodson解除する@2018-03-30」とある.これはカードシフトされたカードはgoodsonにはなれないという意味だが,今の場合軸線なのでgoodsonを解除することはできない.⇒「GoodSonをシフトしたときはgoodson解除しない@20210209」としておこう.今度は,makeGoodSonで停止した.

(!head->IsaSibling() && head->GoodSon->getmyhome() != head)という理由だ.「単体枠でGoodSonを持っているがGoodSonのボックスはこの結婚枠でない」というコメントが付いている.この結婚枠が設定しているGoodSonは#266nodule(0)で抽出されたノードだ.結婚枠に入っているのはnodule(4)でnodule(4)→nodule(0)のように接続されている.noduleの仮ノードは(1)が欠番で,(0)から(12)までの12個表示されている.undosysとnodule(0)をつなぐ抽出枠チェーンは(4)→(5)→(6)→(0)のように繋がっている.(4)→(5)→(6)はダミーなので(0)がGoodSonとなるのは妥当だろう.

軸線がシフトすることを認めるとしたのだから,ここでは停止しないというのでよいのではないだろうか?ないし,条件に「EXTRACTBOXでない」を付け加えてもよい.⇒今度はNAMEBOX:MakeTooYoungWifeで停止した.「カードシフトによる抽出ダミー枠のチェーンをTYWの長い尻尾に転換」しようとしている.これはまずいのではないか?

NAMEBOX::CardShiftDirectではGoodBoxをTYWに転換することは禁止している.従って,このノードは軸線ではない.MakeTooYoungWifeではNAMEBOXではなく,CARDLINKがjikusenであるかどうかをチェックしているが,NAMEBOXが軸線でなければ許可してよいと思う.これでエラーはすべて解消した.ダミーノードにはjikusenのマークは付与されないので,可視ノード数とjikusenの個数が一致しない場合がある.couplingでソートすると下図のようになる.

image

ここまでやるか!?という感じもあるが,まぁ,やるっきゃないね…

STAGE6.ZELの#30 MDBで「軸線が通っていない」エラーが出た.出力では一応通っているように見えるのだが…

image

水平座標の比較の基準としてTREEVIEW::baseboxを使っているのだが,これ以外のすべての軸線ノードとの間で不一致が生じている.それも-56 <> 108という大きな差が出ている.軸線上のノードはMDB(2)だ.baseboxはMDB(0)で不可視の消去された仮ノードだ.baseboxの選定が悪いということになる.baseboxはSETRELATIVEフェーズで設定されている(その前にも仮設定されていはいるが…).

条件は始系列に属する可視ノードだ.⇒軸線が決定したときに見直すか?ないし,baseboxが不可視になったときに取り直しをするかのどちらかが必要だ.⇒TREEVIEW::SelectBaseBoxという関数を新設し,baseboxが不可視になったときにはこの関数を実行するようにした.

▲上記サンプルを#43 graph1でソートして,SIMPLEGRAPH:GetLongestChainで無限ループしている.重複パスの単線化に失敗している.完全木テストで連続実行している場合にのみ起こる.#43 graph1で起動した場合には発生しない.いや,#43ではなく次の#61で起きているようだ.

STAGE6.ZELの全体図最長鎖グラフが出た

STAGE6.ZELの全体図最長鎖グラフが出た.この図はSTAGE6.ZELのすべてのカードを節点とするグラフで,親子枝のうち推移枝だけを除いたものだ.通常最長鎖グラフというときには最上段の先祖ノードと最下段の末裔ノード以外の行き止まりノードは削除されているので,これは,最長鎖グラフと呼ぶより,むしろハッセ図と見た方がよい.

image

このグラフから具体的な最長鎖を切り出すのは難しくない.基準ノードはこの軸線(最長鎖)には含まれていない.このグラフを取り出すために既存のGetLongestChainを少し加工しているが,現状のGetLongestChainはBuildHasseDiagramとリネームし,GetLongestChainで処理を止めている部分とFindJikusenAncestorの中でMakeAntiChainListを合体して,GetLongestChainとすることにしよう.つまり,BuildHasseDiagramでまずハッセ図を生成し,GetLongestChainではそれから最長鎖を切り出すという手順になる.

さて,これからが本番だ.まず,既存のハッセ図検定で作っているグラフをエクスポートするところから始めよう.ハッセ図の節点は重婚クラスタで枝は親子関係だ.その前に試しておくことがある.SIMPLEGRAPH::ExportGraphではレコードのすべてのフィールドを送っているが,多分必要な部分だけ送ることができるはずだ.まず,そのことを確認してみよう.⇒問題なさそうだ.「番号,性別,氏名,よみ,所属,肩書き,父母数,父番号,母番号,続き柄,配偶者」だけを送るようにした.SIMPLEGRAPH::nodtypeにノードのクラス種別を設定するようになっているのだが,使われていないようだ.ハッセ図を出してみた.上の全体図最長鎖グラフと比べるとかなり違う.

image

最長鎖図の世代数は11に対し,ハッセ図は10世代.最長鎖図には軸線上のものを除き,葉が7枚あるが,うち1枚以外はすべ下向きだ.一方ハッセ図では上向きが5枚,下向きが2枚でまったく違うものになっている.なぜか?理由は簡単だ.この2つはそもそも対象グラフが異なる.前者の節点は系図上のカード,後者は重婚クラスタだ.