投稿者: babalabo

源氏物語6.1.zelの完全木テストが完了している．実行環境は開発機，エディションはZT Basic．

この後のテストはVAIOで実行することにして，ZT Advanced（標準版）に戻ることにしよう．最近の修正をフィックスしてから始めることにする．

1. GENELIST：BASELISTを廃止する＠20210224　5箇所
2. GENELIST：domainを廃止する＠20210224　10箇所
3. 暫定 1箇所，#if 0 8箇所，#if 1 2箇所

どうも，やり損なってしまったようだ．TRIBEBOX::SetPotentialでエラーが出るようになった．このエラーは確認されているが，現在の環境では起きていないはずだ．もう一度作り直すしかない．「現状でフィックス」しているのだから，変化しているとすればどこかでやり損なっていると見るしかない．⇒原因はわかった．MARGBOX::getFloorとNAMEBOX::getFloorだ．#if 1でグラフ検証系オンの動作を実行するようになっていたのを修正で復元している．⇒元の論理の方が正しい．

ZT Basicは一応動くようになっているので，ZT Advancedのテストに掛かろう．源氏物語全系譜6.1.ZELの全体図を#1 光源氏で開くと，ShiftDirectAbsoluteで(card->getnodegene() – nbox->getFloor())というエラーが出ているが，エラーを無視して描画は可能なので，一旦置いて，ZTシステム構成図7.1.ZELで出ているバグのシューティングを急ぐことにする．⇒おかしい．ZTシステム構成図7.1.ZELが開けなくなってしまった．nodule::setNringでエラーが出ている．考え辛い．⇒リサイクルシステムに動作不良があるようだ．DEFINETRASHCANを一旦止めて動作するようになった．この障害は後で見ることにする．

▲標準版：ZTシステム構成図7.1.ZELの全体図を#24 UNDOCHAINでソートしてadjustGenerationRangeで停止．(tribelist->ZentaiMin != baselist->MinGeneration)が起きている．⇒このエラーはすでに解消しているが，系統並び替えの出口で垂直スプリットが検出される．

確かに物理世代13でスプリットになっているようだ．どうもあちこち具合が悪い．リリース版の動作もおかしい．サンプルを開いてスプリットになるのは仕方ないとしても，その後のファイルが開けない．新規ファイルさえオープンできない．強制的に新規ファイルを開いた後，CSVをインポートしようとしてハングしてしまう．お手上げだ．UNDOシステムのエラーまで出ている．ZT Basicでは源氏物語6.1.zelの完全木を通しているはずだが，VAIO2でエラーが出ているので，先にこちらを見ることにする．開発環境でも再現できる．

▲源氏物語全系譜6.1.ZELの全体図を#5 紫の上（若紫）で開いて，TRIBEBOX::originateで停止する． (getcritical(SPOUSESENZO)) エラーだ．HORIZONTALORDERフェーズのHorizontalArangement→ MoveRectRightHorizontallyで起きている．処理はすでにMainExperimentに入っている．SPOUSESENZOというのは，「BTW左手本人が系列先祖でかつ系列優先ノードの特殊BTWに関わる系列と左手本人およびその結婚枠」ということを意味する．つまり，「BTW左手本人が系列先祖でかつ系列優先ノード」であるような特殊な系列だ．

前回テストと今回の動作が異なるのは，前回のテストではMARGBOX：IsPrimeboxOrNotがつねにFALSEを返すような設定になっていたためと思われる．障害の起きている系列はTRIBEBOX #1612 先祖=#1321 源典侍(0)[29] 優先=#1321 源典侍(0)→#1749 光源氏(3) →主系列#1548:一院で，先祖ノードでかつ系列優先ノードのげ(0)がBTW左手本人になっている．BTW左手本人は可視ノードだから，このような条件が成立したからと言って特に不都合はないように思われる．しかし，その後のTRIBELIST::CheckAllBondedTribeでループカウントオーバーが発生してSUWになる．なぜだろう？

TRIBEBOX::CheckDirectSubTribeで「接触系列を親参照していない」という不良が起きて，「直属系列接続不良」という状態になっている．系列枠のbondageが空になっている．SPOUSESENZOはBONDEDTRIBE | MAGARIHOSEIとともに，IsBondedTribeの中に入っているのでbondageは主系列を指していなくてはならない．checkIfBondedTribeが空を返しているためだ．この関数ではIfContactParentBlockで上位系列との接触を検査している．

SPOUSESENZO属性を完全に廃止することにする．⇒バックアップに戻って作り直した．源氏物語6.1を開発環境でもう一度テストしてみる．エディションはZT Basicだ．

▲源氏物語全系譜6.1.ZELの全体図を#70 浮舟で開いて，NAMEBOX：ChangeTribeRealnodeで停止．「優先仮ノードが配偶者で逆婚姻関係でない接続」というエラーが起きている．#81 弘徽殿女御でも起きる．NAMEBOX::DoublyBlessedOneで「系列優先実ノードが右手配偶者の場合右手本人に切り替える」という措置を行っているところだ．DecideTribeTypeはPRIME_BTWLEFTを返している．これは「BTW左接続関係：両手に花左手本人→右手本人」だから正しい．ここではDecideTribeTypeの値をsetprimetypeするだけでよいのではないか？

ただし，今の場合，配偶者が左手本人になっているが，これでよいのだろうか？「右手配偶者が左手本人で停止＠20210108」というオプションもあるが，そのノードが可視である限りは配偶者が左手本人となることは可能なのではないだろうか？今の場合，系列優先仮ノードはNAMEBOX #1820 薫(3)で可視の配偶者，BTWの相手方はNAMEBOX #1294 女二宮（今上の）(0)だ．薫(3)の系列はTRIBEBOX #1602 先祖=#1443 小宰相の君(0)で，女二宮（今上の）(0)は一院系列だ．

この図面には薫は2箇所に登場する．浮舟の配偶者，および小宰相の君の配偶者だが，このレイアウトにはやや疑問がある．

薫は一院系列に女三宮の子どもとしてのポジションがあるのに，なぜ小宰相の君の配偶者などになっているのか？⇒理由はわかった．「基準ノードの配偶者の外部婚を排斥」というオプションが効いているからだ．これは「基準ノードの配偶者の外部婚は配偶者の配偶者側で展開する」ための例外規則で，基準ノードの配偶者の外部婚を基準ノードから遠ざけるための方策だ．このルールが妥当なものであるかどうかはもう少し見なくてはならない．⇒このオプションを外したら，薫のカードは3枚になったが，もう少し自然な図柄になった．

女二宮＋薫はBTWでカード消去できるはずだが，なぜそうなっていないのかは，後で見ることにする．以下の2つの障害の原因も「基準ノードの配偶者の外部婚を排斥」にあるようだ．

▲同上サンプルの#100 源典侍でNAMEBOX::IsPossibleBTWLeftHandで「右手配偶者が左手本人」というエラーが起きている．⇒このオプションは「左手本人が右手配偶者で停止＠20210108」に改名した．現行では「停止する」だけでBTW不成立としているが，BTW成立という動作も可能だ．その方が多重カード削減の効果はありそうだ．

▲同上サンプルの#221 源氏宮の母でCARDLINK::getnameboxのエラーが出た．配偶者不在でGP例外が起きている．

複数の障害が発生しているが，まずBASIC版で起きている不具合から見てゆくことにしよう．

▲BASIC版：源氏6.1.zelの全体図を#9 冷泉院で開いて，TRIBEBOX：SetPotentialで停止．(primary->getFloor() != pot)が起きている．このエラーはTribeRelocation出口で実行されるHeapTribeBoxesで起きている．障害が起きているのはTRIBEBOX #1540 先祖=#1231 一院(0)[1] 優先=#1628 冷泉院(1) 始系列で，基準ノードの物理世代番号5に対し，系統ポテンシャル値は4になっている．⇒基準ノードの相対世代番号（listdata.Generation）が1になっている．どこかでシフトされているのではないか？⇒いや，それ以前の問題だ．

TRIBELIST::GoDownStreamで基準ノードの冷泉院が冷泉院の御息所の配偶者として展開されている．GoDownStreamが縦型探索になっているということにも関わりはあるが，それより問題は，MARGBOX：IsPrimeboxOrNotの動作を「IsPrimeboxOrNotを有効化」オフで止めているという点にある．この一点だけでも，このオプションが不可欠であることは分かる．関連するオプションとして，「系列接続に関わる結婚の優先展開」や「基準ノードの配偶者の外部婚を排斥」もオンに戻しておこう．DEBUGオプションの「右手配偶者が左手本人で停止しない＠20210108」もオンとしておくのが安全だろう．⇒逆論理にしてオンに設定し，デフォルトオンのVERIFYに移した．

これでエラーは解消したが，グラフ検証系オフのときには，基準ノード/優先ノードの相対世代番号をゼロに正規化するという処理が入るはずなので，その辺りの動作を確認しておく必要がある．どこかで系列優先仮ノードが冷泉院(0)から(1)に切り替わっている．冷泉院の仮ノードは4つ出ている．

1. #1230 冷泉院(0) 先祖=一院 関係=配偶者
2. #1628 冷泉院(1) 先祖=一院 関係=配偶者
3. #1629 冷泉院(2) 先祖=一院 関係=実子
4. #1648 冷泉院(3) 先祖=一院 関係=養子

MakeUpTreeでは実子の(2)が基準ノードとして選択されているが，その後，SelectBaseBoxで配偶者の(0)に切り替わっている．この選択は誤っている．配偶者(0)はBTWが成立して不可視となり，再度SelectBaseBoxが呼び出されて(1)に切り替わる．このノードでSetPotentialのエラーが発生する．⇒このエラーを取るのはかなり難しい．SelectBaseBoxで可視で非配偶者の仮ノードがすでに選択されていない場合には再選択しないように修正してエラーは解消した．これで一応解決したということにしておこう．

▲ZT BASICで源氏物語全系譜6.1.ZELの全体図を#3 桐壷の更衣で開いて，TRIBEBOX::adjustGenerationRangeで停止した．(tribelist()->ZentaiMax != baselist->MaxGeneration)エラーが起きている．NormalizeRelativeGeneration→ SetTribeMaxGeneでTRIBELIST：ZentaiMinとZentaiMaxは更新しているが，baselist->MinGenerationとMaxGenerationとは同期していない．

このエラーが起きているのは，TRIBELIST::buildgenelist 世代枠リスト構築済みフラグが立っているためだ．SetTribeMaxGeneでUpdateGeneListを実行しようとすると，今度はdomain不在エラーが発生する．おそらく，domainはBUILDGENELISTフェーズでBuildGeneListを実行することで設定されているものと思われるが，baselistの生成時に設定するべきではないのだろうか？

GENELISTは2つリンクを持っているが，どちらもべた参照だ．あまり芳しくない設計だが… 特に世代枠リストの中に基本世代枠リストへのリンクを持つというのは不適当だ．まず，これを廃止できるかどうかを見てみよう．⇒簡単に廃止できた．基本世代枠リストの所在を尋ねるのなら，その所有者に尋ねるのが順当だ．domainも廃止してしまおう．その代わりにDomain関数を使えばよい．Domainは『参照』を返す関数になっているが，書き込み不要なのでリンクを返すだけでよい．GENELIST::InitializeGeneListも丸ごと廃止できる．

SetTribeMaxGeneでUpdateGeneListを実行するようにしているが，エラーが起きる．MinGeneration，MaxGenerationはすでに設定されているが，まだ世代枠が生成されていないため，動作不良が起きる．⇒この関数の中で調整することも不可能ではないが，世代枠リストはGoDownStreamとMakeUpTreeが完了した後にBUILDGENELISTで別途構成するようになっているので，buildgenelistフラグが立つのを待つというのでよいのではないか？⇒対処した．

昨日の修正を一旦白紙に戻してバックアップから出直すことにする．TRIBEBOX::setPotentialが最初に掛かってくるのは，TribeRelocationのAFTERMARGSAMEGENEで実行されるCheckTribeVerticalPositionだ．グラフ検証系が作動しているときにはSAMEGENEMARRIAGEで重婚クラスタ図が生成され，絶対世代番号が確定している．それと同等のことをグラフ検証系なしでやるとすれば，各ノードが保持している相対世代番号Generationを正規化するということではないだろうか？

TRIBELIST::NormalizeRelativeGenerationという関数を作って，TribeRelocationの冒頭で実行するようにした．この関数では「優先仮ノードの世代番号をゼロになるように系列内世代番号をシフト」して，「系列世代枠リストの最小/最大世代番号を更新」する．これで，「ZTシステム構成図7.1.ZELの全体図を#33 baselist 基本世代枠でソートして，TRIBEBOX::SetPotentialで停止」という問題は解決した．

▲ZTシステム構成図7.1.ZELの全体図を#24 UNDOCHAINでソートして，TRIBEBOX::InsertRingで停止した．世代枠不在が起きている．NormalizeRelativeGeneration実行後，StackTribeGeneを実施しているループの中で起きている．NormalizeRelativeGenerationの中で何らかの手当てをする必要がある．#57 BASETABLE，#58 ARRAY，#82 SIMPLEGRAPHなどでも発生する．

障害ノードはMARGBOX #690：#795 longtable(0)＋#755 RecordList(0)→で，世代番号は[1]．所属系列はTRIBEBOX #913 先祖=#795 longtable(0)だ．系列世代枠リストのMinGeneration=-1, MaxGeneration=0で要素数は2．この関数はStackTribeGeneの冒頭MakeGringから呼び出されているが，その直後に実行されるGenerationBoundaryの中でsetPotentialを実行しているので，呼び出しが早過ぎる．また，GenerationBoundaryの中でもMakeGringを実行しているので，ここで実行する必要はないと考えられる．⇒対処した．

▲同上サンプルの直系血族図を#15 selectedcardでソートして，GENELIST::GetGeneBoxで停止した．引数の物理世代番号が負になっている．AFTERMARGSAMEGENEフェーズのTribeGhostNameで起きている．NAMEBOX::getPairlistは引数のindex=0で呼び出されているが，対象人名枠のNAMEBOX #719 treeview(0)の物理世代番号が-1になっている．所属は始系列のTRIBEBOX #905 先祖=#716 coupling(0)[1] 優先=#730 selectedcard(0)．

最古世代先祖ノードはNAMEBOX #716 coupling(0)で物理世代番号は-3になっている．最古世代先祖は始系列に属している．この関数が呼び出されるまで，一度もTRIBEBOX::setPotentialが呼び出されていない．⇒NormalizeRelativeGenerationの中ですべての系列の系統ポテンシャルを設定するようにした．

▲同上サンプルの直系親族図を#2 kakeizuでソートしてGenerationBoundaryで停止した．#202 NODULEでも起きる．また，Ｚ木家系図 基準ノード=#2 kakeizu，．#202 NODULEでも起きている．障害ノードはTRIBEBOX #907 先祖=#771 COUPLING(0)で，(!getGeneBox(minGeneration) || !getGeneBox(maxGeneration))という理由で停止している．minGeneration=-1, maxGeneration=0．

この2つの値はTRIBEBOXのプロパティで系列世代枠リストのMinGenerationとMaxGenerationに相当するものと思われるが，NormalizeRelativeGenerationの中では設定されていない．これらは，TRIBEBOX::setMinGene，setMaxGeneで設定されている．⇒NormalizeRelativeGenerationの中で更新するようにした．

ZTシステム構成図7.1.ZELの完全木テストが完了した．

悪くない数字だ．最近の修正をフックスしておこう．

1. MoveLowerMargTreeではTYW枠は移動しない＠20210215　1箇所
2. PAIRBOX：setSectionを廃止する＠20210218　7箇所
3. NAMEBOX：shiftedonceを廃止する＠20210218　5箇所
4. TRIBEBOX：brokenを廃止する＠20210218　11箇所
5. Boject：nobori，kudari，unequalを廃止＠20210218　8箇所
6. checkBrotherOrderで微細な移動を実行する＠20210219→ 廃止
7. KeitoMin，KeitoMaxを廃止する＠20210220　11箇所
8. 仮修正 6箇所，OBSOLETE ２箇所

この後のテストはVAIO2で行うことにする．ここで標準版をビルドして別アプリ用にリリースしておこう．

▲標準版：ZTシステム構成図7.1.ZELの全体図を#24 UNDOCHAINでソートしてTRIBEBOX::adjustGenerationRangeで停止．(tribelist->ZentaiMin != baselist->MinGeneration)が起きている．

▲標準版：TRIBEBOX::SetPotentialで(primary->getFloor() != start->getPotential()) が発生する．

▲BASIC版：源氏6.1.zelの全体図を#9 冷泉院でソートして，TRIBEBOX::SetPotentialで停止．(primary->getFloor() != pot)が起きている．

▲ZTシステム構成図7.1.ZELの全体図を#33 baselist 基本世代枠でソートして，TRIBEBOX::SetPotentialで停止．基準ノードの物理世代番号と系統ポテンシャル値が一致しないというエラーが起きている．障害が起きているのは，始系列のTRIBEBOX #905 先祖=#716 coupling(0)[1] 優先=#748 baselist基本世代枠(0)で，系統ポテンシャル値は4，基準ノードの物理世代番号は3になっている．AFTERMARGSAMEGENEフェーズ「重婚グラフ検定の事後処理」の中でCheckTribeVerticalPositionを実行しているところだ．最古世代先祖ノードは始系列に属する #716 coupling(0)，つまり，始系列は系統最古系列でもある．

基準ノード世代=-1 先祖ノード世代=-4で確かに世代差は3だ．つまり，基準ノードの物理世代番号3というのは数字的には正しい．そもそも，基準ノード世代=-1というのがおかしい．この値はNAMEBOX::listdata.Generationに格納された値で，系列内の相対世代番号を表す数字だが，基準となるのは「系列優先ノード」であり，始系列の場合は基準ノードに該当するものであるのだから，つねにゼロでなくてはならないと考えられる．かなりややこしい問題がある．

基準ノードのbaselistから先祖ノードへの経路は少なくとも2つある．距離（世代差）3の経路と距離4の経路だ．上流検定ではより小さい数値が適用されるので，先祖ノードの世代値は-4となり，下流検定で基準ノードの世代値に-1が設定されることになる．これをいじると，今度は世代差が出てきて世代計算の根底が崩れてしまうようになるので，この状態で収めることを考えよう．

▲ZTシステム構成図7.1.ZELの全体図を#24 UNDOCHAINで開いて，TREEVIEW::InvestigateVSplitsの垂直スプリットエラーが発生する．⇒物理世代1～4でスプリットとされるが，画面で見た限りでは起きていないように見える．TREEVIEW::InvestigateVSplitsでダンプしてみると，mingene=0 maxgene=12 maxgene-mingene=12で描画要素はNAMEBOX #903 nodule(0)のindex=0を除き，index=6～12の間に分布している．実際の画面出力は8世代分しかないので，どこかで4世代分の齟齬が発生している．indexの値はgetFloorで得た物理世代番号ーmingeneだが，mingene=0なので実質物理世代番号で見ていることになる．つまり，物理世代番号が間違っていると推定される．

これは結局系列ポテンシャル値が不正ということになるので，それを設定している場所を調べてみよう．AFTERMARGSAMEGENEフェーズのCheckTribeVerticalPositionの中でGetPrimaryGapに従って設定されている．これは優先実ノードと仮ノードの相対的な世代差によって調整するものなので，始系列のPotential値が正しいということが前提となっている．TRIBEBOX::setpotentialにはシグネイチャの異なる3種があるので，　①callSetpotential，②Setpotential，③setpotentiaのようにリネームして識別するようにした．

callSetpotential→Setpotential→setpotentia

のような関係がある．callSetpotentialは現在の系列優先実仮ノードを引数にSetpotentialを呼び出し，SetpotentialはGetPotentialで得た値を引数にsetpotentiaを実行する．callSetpotentialは19箇所，Setpotentialは3箇所，setpotentialも3箇所から参照されている．始系列のPotential値を設定しているsetPotentialを見てみよう．

この系図には2つの系統がある．①#905 先祖=#739 UNDOCHAIN(0)系統，②#957 先祖=#903 nodule(0)系統．nodule(0)系統のポテンシャル値は一貫してゼロだが，UNDOCHAINのポテンシャルは0, 2, 5, 8, … のような変動を繰り返している．どうも，TRIBELIST：SetTribeMaxGeneにはかなり問題がありそうだ．

SetTribeMaxGeneを全面的に書き換えて，上記のような変動は解消した．現行では系列の世代枠リストは伸張の方向にしか変化しないようになっている．系統ポテンシャルに関係するのは，KeitoMaxだけだ．まず，KeitoMin，KeitoMaxのアクセス関数を作っておこう．SetTribeMaxGeneではKeitoMin，KeitoMaxを無条件で更新している．従って，硬直しているのはTRIBEBOX::minGenerationと推定される．

TRIBEBOX::minGenerationの書き換え関数setMinGeneは以下の3箇所から呼び出されている．①GoDownStream(void) (TRIBELIST)，②InsertRing(MARGBOX * mbox) (TRIBEBOX)，③adjustGenerationRange(int min, int max) (TRIBEBOX)，④clean(void) (TRIBEBOX)．④は初期化しているだけなので無関係．①は先祖ノードの世代を直接格納しているので問題ない．②では系列の世代枠が持つ結婚枠リングに結婚枠を登録する際に系列世代範囲が拡大した場合のみ更新している．

③adjustGenerationRangeでは(PHASE < BUILDGENELIST)の場合は無条件で書き換えを実施しているが，フェーズがBUILDGENELIST以上ではUpdateGeneListを実行した結果を転記している．UpdateGeneListでは世代枠リストが上下に伸張する方向でしか書き換えを実施していない．世代範囲が縮小した場合には空になった世代枠を削除して最小/最大世代番号を更新すればよいというだけだから，修正はそれほど難しくないと思われるが，現状のままでもそれほど不都合はないとも考えられる．問題は使われていない世代枠が存在する状態をスプリットと誤認する点にあると考えられるので，まず，これに対処することにしよう．

TREEVIEW::InvestigateVSplitsでは最初にmingeneとmaxgeneを現物オブジェクトから取り出している．この中でnodule(0)が唯一物理世代番号0となっているため，これに引きずられて0～12というレンジになってしまっている．これを避けるためにはどうしても最古世代系列を世代枠リストの先頭に配置しなくてはならない．このようなことになってしまうのは，世代計算で物理世代番号を使っているためと考えられる．当初は系統内でのみ通用する常用世代番号を使っていたはずだが，「重婚クラスタ検定」の導入により「確定世代番号」が適用できるようになったため，物理世代番号で処理するようになったものと思われる．物理世代番号を使うようになったもう一つの理由がある．ノード対を管理している基本世代枠リストが物理世代番号で管理されているためだ．

系統最古世代ないし，系統最古世代先祖ノードが確定できれば現行論理をあまり変えずに何とか対処できるのではないか？いや，どちらにしても世代枠リストで前詰めしないことにはどうにもならないのではないか？⇒画面上は問題なく描画できているのだから，問題をスプリット検定の問題として限定すべきではないか？考えられる方策としては検定を系統単位に分解することが考えられる．

TRIBELIST：HeapTribeBoxesで系統ポテンシャル値を再設定している．ここで系統最古世代先祖ノードの物理世代番号がゼロとなるように系統ポテンシャルを設定することで解決した．ただし，TRIBEBOX：setPotentialでKeitoMinと設定値が一致しないというエラーが出る．⇒「系統最古世代先祖ノードの物理世代番号がゼロ」というのが系統ポテンシャルの本来の定義なので，TRIBEBOX::SetPotentialをその趣旨で書き換えてみよう．⇒問題なさそうだ．

KeitoMinという値は，系統ポテンシャルを決定するときしか使われていないので廃止できるのではないか？というのは，系列世代枠リストは系列内の世代のみを扱い，基本世代枠リストは系統より広域な全域世代枠を扱っているからだ．一度バックアップを取ってから試してみることにしよう．⇒うまくいったようだ．

▲ZTシステム構成図7.1.ZELの全体図を#33 baselist 基本世代枠でソートして，TRIBEBOX::SetPotentialで停止した．基準ノードの物理世代番号と系統ポテンシャル値が一致しないというエラーだ．

▲源氏物語全系譜6.1.ZELの直系血族図 #318 右大弁（桐壷）で三極検定レッドラインオーバーが起きた．これはかなり信じ難い動作だ．右大弁（桐壷）は親なく子なく妻もなしなので，直系血族図には本人カード1枚しか残らないはずだ．それがエラーになるとは何かが「狂って」いる．REDLINE値がゼロになっている．現在この変数には「結婚数」が設定されている．⇒1よりも小さい値にならないよう修正した．

▲同上の傍系親族図を#5 紫の上（若紫）で開いて，TRIBEBOX：StackTribeGeneで停止した．completeの状態にある系列枠の検査でCheckMaximalSegment不合格になっている．この検査では「インター系列シンメトリ婚の場合は他系列での移動が配置に影響する場合がある」ため除外されている．障害が起きているのは，TRIBEBOX #1548 先祖=#1231 一院(0)[6] 優先=#1673 朱雀院(1)→#1347 源氏宮(0)で，主系列は主系列#1540:先帝だ．

StackTribeGeneではsetcompleteでCheckMaximalSegmentの検査を通している．セグメントは3つに分離している．①#1231 一院(0)とその結婚枠#1055：#1231 一院(0)＋→#1648 桐壷院(1)，②#1685 八宮の母女御(1)，③それ以外だ．八宮の母女御は何も特別な属性を持っていないが，たとえば，BTW解除などのことが起きているのではないか？⇒そういう状況ではないが，結婚点不一致が起きている可能性がある．⇒八宮の母女御の子ども枠はTYWになっているため結婚点一致できない．承香殿女御 （桐壷院の）→四宮 （桐壷院の）もTYWになっている．麗景殿女御 （桐壷院の）まではセグメント[4]になっている．また，②つのTYW枠も[4]になっている．

八宮の母女御だけが[6]という理由が分からない．⇒TRIBELIST::CheckMargBoxChangedの中で何らかの変異が起きている．おそらく，微細な調整で無視されているようなものだろう．

MARGBOX::checkBrotherOrderで移動量-1の移動が実行されている．この移動は誤差の範囲なので戻り値では返されていない．微細な移動は実行しないか，ないし実行して結果を報告するかの2択しかない．「微細な移動は実行しない」というのがもっとも確実だが，おそらく描画はやや精度を欠くものになる可能性は避けられない．実行した場合には最悪処理が発散ないし循環してしまう可能性がある．とりあえず，実行するという方向で修正してみよう．⇒少なくともこの反例に関してはこの修正で収まった．これでしばらく様子を見ることにしよう．

八宮の母女御の子ども枠はTWY解除されて直下に収まっている．承香殿女御のTYWは残っている．

ZT BASICで源氏物語全系譜6.1.ZELの完全木テストが通った．

この続きはVAIO2でやることにしよう．⇒早速エラーが出た．ZTシステム構成図7.ZELの全体図：#24 UNDOCHAINで垂直スプリットが発生している．ただし，開発環境では再現しない．サンプルは同じZTシステム構成図7.ZELだが，VAIOにあるのはカード数が1少ない．それだけでここまでの差が出るのかどうか？開発機では別のエラーが出た．

▲ZTシステム構成図7.ZELの法定親族図：#7 topologyでMPLCループレッドラインオーバーが発生した．⇒昨日の修正を戻して解消した．やはり，「checkBrotherOrderで微細な移動を実行する」というのは無理がある．以下のように仕様変更することにした．

1. checkBrotherOrderで計算誤差範囲の移動が発生した場合：
   移動は実行するが，crushはインクリメントしない
2. 移動を実行した場合には，対象系列をincompleteとする

NAMEBOX::originateでは変位が計算誤差を超える場合には，CancelStackを実行して系列枠をincompleteにしている．これをつねにCancelStackを実行するようにした場合には収束しなくなる可能性が出てくるので現状のままとする．この意味ではcheckBrotherOrderでも微細な移動はすべて無視するものとし，StackTribeGeneではCheckMaximalSegmentで停止しないようにするというのが一番合理的であるような気もする．⇒そのように対処した．

VAIOのZTシステム構成図7.zelを7.1.zelにリネームして開発機にコピーした．このサンプルを開くと開発機でもエラーを再現できる．

▲ZTシステム構成図7.1.ZELの全体図を#24 UNDOCHAINで開いて，TREEVIEW::InvestigateVSplitsの垂直スプリットエラーが発生する．しかし，実際にはスプリットは発生していないように見えるので，事実誤認が疑われる．

PAIRBOXの関数setSectionと変数sectionを廃止した．これらの値はダイナミックに変化するので値がつねに正当であることを保証できない．

▲ZTシステム構成図7の全体図を#92 Bobjectで開いて，NAMEBOX：makePairBoxで(common && common->CheckSamePoint())で停止した．⇒これはエラーではない．まだ端点共有していないためsamepointがCOMMON_NOCOMMONになっているというだけだ．⇒commonが端点共有束でない場合を検査から除外した．

ZT BASICによるZTシステム構成図7.ZELの完全木テストが完了した．前回より若干遅くなっている．

使用していない変数などを削除した．①PAIRBOX：setSectionを廃止，②NAMEBOX：shiftedonceを廃止，③TRIBEBOX：brokenを廃止，④Boject：nobori，kudari，unequalを廃止など．

▲源氏物語全系譜6.1.ZELの全体図を#123 左大臣の女御で開いて，三極検定ループカウントオーバーが発生した．障害はTRIBEBOX #1542 先祖=#1231 一院(0)[2] 優先=#1754 冷泉院(4)→#1230 冷泉院(0)で起きている．⇒三極検定レッドラインオーバーが発生した場合には，「レッドラインでZTYW/TYW婚を１個づつ停止しながら続行する＠20210218」ようにした．ZTYW婚は当初14個あったものが，12個まで削減されるとループから脱出できた．ただし，TribeRelocationのSYMMETRICGEOMETRYフェーズでCheckZeroPositionにより5個削減され，最終的には7個だけが生き延びている．

▲同上サンプルの直系血族図 #318 右大弁（桐壷）で三極検定レッドラインオーバーが起きた．

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:一院に接続できるようになった．多分これが正解なのではないかと思う．

▲同上サンプルの全体図を#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システム構成図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のステージ【７.２】完全木検定：すべての系列を完全系列として正準化するで実行される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. 不可視ノード移動ｘ9件
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)ではないことが検出されている．⇒ここでは停止しないでダンプするだけとする．

重婚グラフ（多重グラフ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に論理ミスがあった．

これで正しい重婚クラスタ図を描画することができるようになったが，「先祖ノード絶対世代番号不一致」は相変わらず収まっていない．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でソートして三極検定レッドラインオーバーになった．