InvestigateVSplitsで垂直スプリット

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で停止した.基準ノードの物理世代番号と系統ポテンシャル値が一致しないというエラーだ.

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA