ゼルコバの木テント村

▲YGroup32.zelを開こうとしたら，MakePairListCleanで無限ループしてしまった．最初に以下のエラーが発生している．SUPPORTSIMPLEGRAPHをオンにしたためだろうか？

確かにそのようだ．オフにしたら描画できた．親子連結線の不良に関係があるかどうか見るためにオンにしたのだが，無関係のようだ．このオプションに関しては後日調べることにして戻しておこう．⇒YGroup.zelで不用な親子連結線が表示されている．これは少し気になるので，見ておきたい．画面右下の連結線はどこにもつながっていない．

この線はYGroupから出ているので，YGroupの子どもと考えられるが，hiddenとcheckcidの間には，printnamaeしかない．printnamaeは一世代下の箱に入っている．YGroupの子どもは13人だ．結婚点の位置もおかしい．⇒縦系図/横系図は，DrawObject.cppのbool reverseAxisで切り替えできる．結婚点などはその切替を行っていないのではないか？本来論理座標は一つであり，描画する側で対処する必要がある．reverseAxisはDrawObject.cppの中でしか参照されていない．

座標軸の変換関数として，reversePoint, reverseRectがある．_CDCというCDCの派生クラスにはこれらを使った描画関数のセットがある．_CDCを経由して描画していれば，間違いないはずだ．他の描画関数はほぼ対応済みと見られるが，Polygonは残ったままとなっていたものと思われる．⇒対処した．これで座標軸の転換は完結したものと見られる．

上記の不明な連結線の出所がわかった．

NAMEBOX::DrawLongTailでCheckYrouteのLDR垂線として描画している．しかし，CheckYrouteのLDRはYGroupの子どもとしてすでに描画されており，CheckYroute自身は実体を持っている．つまり，余分なノード対を持っているように思われる．何か操作しているときに誤って残してしまったのではないだろうか？このノード対は，CheckYroute(2)→ (1)を連結するものだ．本来の(1)→(2)はノーマルに描画されている．このようなノード対が発生していること自体問題だ．段数が2となっている．どうも，LongTailを作り損なっているのではないか？

NAMEBOX::DumpLongTail NAMEBOX::DrawLongTail > #1157 CheckYroute(2)
   1  dum#=1 #1157 CheckYroute(2)
   1  dum#=2 #1169 YRight(2)
   2  dum#=2 #1905 YRight(3)
NAMEBOX::DumpDummyChain NAMEBOX::DrawLongTail
   1  thread        #1157 CheckYroute(2) #1169 YRight(2)
   2  #1913 [結婚枠]：[2] #1905 YRight(3)

長いしっぽの構成を忘れてしまった．確か複合的なものであったような気はするが…YRightはYgroupの子どもであり，CheckYrouteとはつながらないような気がするのだが…⇒なぜ，複合構造になるかというと，LDRは複数のLDRが束ねられる場合があるからだ．確かにYRightはYGroupの子ノードであり，CheckYrouteと共通の親を持っているから，LDR束だ．しかし，YRightは親を２人持っていて，それがCheckYrouteだ．どうもかなりややこしい話になってきた．

出力ではYRightはYgroupの子ども枠の中にLDRはとして入っているように見える．結局，この線分は下図のように引かれなくてはならなかったものと思われる．

従って，描画していることではなく，描画している位置が間違っている，つまり，一世代下がり過ぎということになるのだろう．⇒できた！

かなりノーマルなモードに近づいた．バックアップを取っておこう．⇒TYW2ExtractBoxでは問題なく動作することが確認できたが，RestoreYoungWifeとどこが違うのかをチェックしておく必要がある．このために，関数の参照関係を洗い出そうとしたのだが，関数木の原本が見つからなくなってしまった．いや，その前にYGroup32.zelで出ていた部分図の障害を見ておこう．というか，この図面は相当乱れている．

いや，今度はノーマルに開けた．インストール版でテストしていた．修正の入った版では解決している．

▲YGroup32.zelで「人名枠線を表示する」をオンにしようとして，エラーになった．ResetTooYoungWifeだ．

(topology->TooYoungList->len() != ztywcount) が起きている．

ztywcountは-1で，TooYoungListのデータカウントはゼロだ．どこかで引き過ぎているのだろう．ztywcountはZTYWのカウントでTYWのカウントではない．この辺りで食い違いが生じているのでは？明らかに行き違いがある．TooYoungListに格納されているのはZTYWだけではない．それにしてもおかしいことはおかしいのだが…ztywcountをtywcountに統合するのではなく，別途tywcountをカウントすべきだろう．同様に，SymmetryCountも別途カウントすべきだ．つまり，システムの内部パラメータはつねに，２つの方法でカウントされなくてはならない．言い換えると複式でカウントされなくてはならないというのが原則だ．この考え方は徹底されなくてはならない．

1. 系列枠は個別にTooYoungCount, ZTYWCount, SymmetryCountを管理している　これに対応して大域的にtywcount, ztywcount, symcountを管理するものとする
2. これらのカウントはそれぞれの属性のセット・リセットを行うsetghostbits, resetghostbitsで同期を取るものとする
3. TouYoungList, SymmetryListへの追加，削除のタイミングで上記カウンタとの一致を確認する
4. 系列枠のカウンタを更新した場合にもそれらの合計と一致していることを確認する
5. これらの属性はすべて結婚枠の属性であるとする
6. TOPOLOGY::CountTooYoungWifeという集計関数もある

TopologicalSortの冒頭でTOPOLOGY::ResetExperimentが実行されている．このとき，3つのカウンタがリセットされているが，オブジェクトは温存されているためカウント不一致が発生する．⇒SymmetryList，TooYoungListの廃棄とtywcount，ztywcount，symcountのリセットはClearTableより後に実行することにした．ResetExperimentもそのタイミングでよいのではないだろうか？ただし，genelist, tribeListの初期化はClearTableに先行させる必要がある．

YGroup32.zelでは多重カードが３件出ている．これは削減できないのだろうか？あるいは，どこかで機能劣化してしまった可能性もある．

一番左のYGroup(♀)は祖父のYGroup(♂)の配偶者なので，多重となるのは避けられない．真ん中のCutBranch(♂)は娘のCutBranch(♀)の配偶者なのでやはり不可避だ．CheckYroute(♂)は親を3組持っているが，そのうちの一人は兄弟のCutBranch(♂)なのでやはり，避けられないということのようだ．これは，再帰ないし再入呼び出しを表現するための苦肉の策として取られた手段ではなかったろうか？

ゼルコバの木では血統循環を禁止しているため，婚姻関係を使って擬似的な血統循環を成立させていたのだと思う．⇒関数木では再帰的な呼び出しを，同名の子ノードを作りそれを親ノード（呼び出し先）と配偶させることで擬似的に表現している．再帰呼び出しは必ず血統循環を発生してしまうので，ゼルコバの木では禁止されているが，多重カードになることを許容するのなら，血統循環を許すという設計も（将来的には）考えられなくもない…

関数とその所属するクラスとの関係もある種の木を構成すると考えられるが，関数木ではクラスを部分図で代替している．ゼルコバの木では最大32個までの部分図しか登録できないが，ゼルコバの木の実装ではおおむねそのくらいの数のクラスしか扱わないので，ほぼカバーできるのではないかと思う．⇒部分図自体を一つのオブジェクトとしてその包含関係を明示できれば，部分図木のようなものを構成することも可能となるが，現在の実装では部分図は単純な集合であり，必ずしも順序関係を定義することはできないので，多分実装は難しいと思う．（関係グラフのようなものは構成できるかもしれないが…）

TYWに関係する処理の見直しを進めているところ．基本的には，「moveがゼロのときはZTYWとしない」という方針だが，障害が発生する原因は突き止めておかなくてはならない．また，衝突回数上限を決めるMAXCRUSHCOUNTと処理終了するまでの時間が必ずしも比例するものではないという点に関しても調べる必要がある．現行では，ZTYWに制限を掛けていないため，衝突回数オーバーですべてのTYW婚を解除するAbortAllFloatingBoxが発動しているが，にも関わらず障害が止まらないという問題がある．

このとき，①Yリスト上位ノード不在，②TYW婚の吸収合併成功，③NAMEBOX：CheckUnerasable 結婚枠不在のような事象が大量発生している．従来論理ではAbortAllFloatingBox→ StopTooYoungWife→ TYW2ExtractBoxでTYW→抽出枠転換していたが，現行では暫定的にRestoreYoungWifeを使っている．この理由は，TYW2ExtractBoxでは抽出枠が残存してしまうが，RestoreYoungWifeなら完全に元の状態に復元できると考えたためであるが，どうもどこかに不備があるような感じだ．⇒TYW2ExtractBoxを復活させれば正常動作可能だ．

TYW2ExtractBoxではZTYWの場合は，RestoreErasedYoungWifeが実行される．RestoreErasedYoungWifeではRestoreErasedYoungWifeで消去された仮ノードを取り出して，RetrieveGhostでそれを復活させている．従って，この処理にはぬかりはないと言える．逆にRestoreYoungWifeではそれが不十分な動作になっているように思われる．この辺りは，一度整理してドキュメント化が必要だ．呼び出し関係だけでもチェックしたいのだが，その手始めとして「関数木.zel」を復活させるというのは悪いアイディアではない．どこかにあるはずだ．

デスクトップ 2020-02-11\テストサンプル\関数木グラフというフォルダがあった．ただ，一部関数のコレクションばかりで，全体木のようなものが見当たらない．フォルダ名は2020となっているが，中身は2017～18に作られているようだ．どこかにもっと大きなサンプルがあるはずなのだが…別の場所にもいくつか関数木という名前のファイルはあるが，NONファイルに変換されてしまっていて，名前が短縮されているものしか見当たらない．2018-02-04の記事には「血統循環関係の関数参照木を作って不用関数を整理」とある．

▲デスクトップ 2020-02-11\テストサンプル\関数木グラフ\AccidentalCollisin.zelを開こうとしてエラーになった．

エラーを無視して描画は可能．⇒開発環境ではエラーにはならない．対処済みと思われる．

もっと大きな網羅的な関数木を作っていた記憶があるのだが，残っているのはどれも，特定の処理に関するコレクションばかりだ．もっとも大きなYGroup32.zelでも58点しか入っていない．

▲ YGroup32.zelで部分図 Bobject を選択して，(topology->TooYoungList->len() != ztywcount)で停止．図面もおかしい．カード数6と表示されているが，実際には7点あり，親子連結線もおかしい．⇒いや，カード数は６で正しい．多重カードが出ている．多重カードの解消機能が十分動作していないように見える．

ここでリリース版を起こしておこう．⇒インストールしたが，動作がおかしい．古い版が残ってしまっている．アンインストールして再インストールで正常動作するようになった．

仮修正が少し残っているので，フィックスしておこう．

1. BCMDTABLE::BCMDTABLEの仕様変更：呼び出し時の引数を追加　⇒　現状でフィックス
2. TRIBEBOX::HorizontalSegment：セグメント数=1のとき，CheckMaximalSegmentで再検査→廃止　⇒　フィックス
3. TRIBEBOX::HorizontalSegment：出口でCheckMaximalSegmentの再検査→廃止　⇒　現状でフィックス
4. TRIBEBOX::MinimumContactDistance：すでに検定完了している場合は停止するようになっていた→停止しない　⇒　FIXED
5. TOPOLOGY::ClearTable：MARGBOXの初期化でdataCleanを使う　⇒　FIXED
6. ClearTableでlookupを使う＠20230214　⇒　FIXED

▲COUPLING::TopologicalSortでEraseTreeViewを呼び出さないようにしたところ，系統並び替えを実行しようとして，ClearTable→ NAMEBOX::CLEARで停止した．TRIBELISTのgetstarttribeが空を返している．tribelistはすでに廃棄されているが，基準ノードは始系列の優先ノードなのでSelectBaseBoxで参照が掛かっている．⇒startが空のときは処理をパスするようにした．

これでEraseTreeViewを実行しなくても，処理を継続することができるようになった．ClearTableを止めるのは無理のようだ．現在，系統並び替えでは13.7秒掛かっている．うち，ClearTableの消費時間は407msだ．サンプルBではClearTabledeだけで20秒掛かっている．その後のステージ９：Decomposition，ステージ11:GODOWNSTREAMもかなり掛かる．⇒CheckMaximalSegmentの出口で行っていたCheckMaximalCompactionの再検査を止めてかなり高速化した．それでもサンプルBの系統並び替えでは253秒で４分以上掛かっている．とりあえず，今のところパフォーマンスについてはここまでとしておこう．

◎現在開発機にインストールされているのは，V2.2.2.008 REL 2022-04-26 でカードテーブル上限は8192だが，サンプルAを読み込んでもまったく表示できない．現行バージョンのリリース版を起こしてみよう．

▲リリース版をビルドしようとして，STOPマクロでエラーが出ている．Dump関数をCObject::Dumpと取り違えている．なぜだろう？CObjectはMFCライブラリの基底クラスなので，我々も使ってはいるが… ヘッダはafx.hだ．DrawingObject.hはいつも最後に読み込まれるので，それ自身は他のヘッダをまったく参照していない．_WIN32_WINNT not defined. Defaulting to _WIN32_WINNT_MAXVER (see WinSDKVer.h)という警告が出ている．⇒DrawingObject.hではCDCの派生クラスを定義している．おそらく，この辺りでMFCのクラス定義が持ち込まれているのだろう．

意味がわかった．_CDCはCDCの拡張クラスなのだから，その中から呼び出すとすれば，当然その系統のメンバー関数になる．ということは，当然_CDCの中からNODULEクラスの関数を呼び出すことはできないということだ．しかし，どういう訳かデバッグモードでは動作しているので切り分けておくことにしよう．QUICKDBでもエラーが出ている．コードは変化していないはずなのだが…⇒いや，PickRecordは今回新設した関数だ．_STOPなら使える．

IsAinstanceOfで_mbscmpの代わりにstrcmpを使うようにした．

▲nodule::CheckSansyoCountでSTOP文野中で，Dump「静的でないメンバー関数の呼び出しが正しくありません」エラーになった．⇒CheckSansyoCountは確かに静的関数として宣言されている．⇒_STOPなら問題ないようだ．

▲SetupTitleBox.vb(3274,24): error BC30451: ‘CommandLine’ は宣言されていません。アクセスできない保護レベルになっています。⇒CommandLine As Stringは以前はWindows.vbでpublicとして定義されていたのだが，現在はMDIForm_Loadのローカル変数になっている．UnlockTitleではスプラッシュウィンドウをクローズするための判定に使っているが，UnlockTitleの中でスプラッシュウィンドウを操作するというのはおかしいので，止めておくことにしよう．

なかなかいい感じだ．リリースモードではサンプルAを５秒以内に開くことができる．サンプルBの系統並び替えが55秒だ．悪くないと思う．バージョン番号を更新しておこう．現在のバージョンは2.2.2008だが，2.3まで上げてよいのではないだろうか？⇒インストールに成功した．

▲パッケージにはテーマファイルは入っているが，サンプルがまったく入っていないような気がする．配布パッケージの添付ファイルを置くとしたらドキュメントフォルダがもっとも適していると思われるのだが… どこかの時点で外してしまったのだろう．⇒対処した．

▲タモリさんちの超複雑な家系（拡張版）.zelをアイコンのダブルクリックで開こうとしてエラーになった．標準版のタモリんちは開けたが，横書きだ．

横書きと縦書きをオプションで切り替えられるようにする必要があるが，横書きでも違和感のないレイアウトになっている．ただし，描線にはあちこち問題がありそうだ．というか，現行では結婚線というのをまったく見ていないはず．ルーゴン・マッコール家系図でも同じエラーになった．

それに続いて，以下のようなエラーが出る．

軟体動物も開けたが，それ以外は全滅だ．

この原因として考えられるのは，記録データが取り込まれていないのではないか？という点だ．おそらくタモリんちと軟体動物には記録部への書き込みがまったくないのだろう．実際，コラッツで作ったサンプルは相当大きなものでも問題なく開けている．12146点のサンプルも問題なく開けた．ともかく，ここから再出発するしかない．

「ユーザの個人用データフォルダ」というのに格納するようにしたら，ドキュメントに入るようになった．バラバラで入れるのも何なので，「ゼルコバの木系図ファイル」というフォルダを作ってそこに入れるようにした．この問題は，まず，これで解決だ．

KAKEIZU::getcarddataでエラーが出ている．item[27]が空になっている．撮影日付だ．この部分は，QUICKDB::pickrecordを廃止して，PickRecordを新設しているが，論理は基本的に変わっていないはずなのだが…つまり，データが存在しない場合には空のままとしていたはずなのだが…実際の個別データはquickfile(“TAKE:8”)で取り出していたので，必ずポインタを渡すようになっていたのかもしれない．実行関数はquicktakeだ．以前は一件ごとにrespbuffというところを使って受け渡ししていたので，ポインタが空ということは発生する余地がなかったのだが…データがないときは空文字列を指すポインタを渡すというのでもよいが，それも煩わしい気がする．ポインタが空のときは無動作とするというのが早いのではないだろうか？文字列関数でエラーを出さないようにするということも考えられるが…

▲天皇家系図でエラーが出た．

MergeUpperSegmentでエラーが出ている．(head == mbox && mbox->realsons && !mbox->getCritical(FATALSTARTEND｜NOGOODSONEXIST) && mbox->NextSibling()) のような条件でmakeGoodSonを呼び出してgoodsonが特定された場合に停止するようになっている．停止しないようにして描画できた．那須記も描画できたが，かなりおかしなことになっている．

添付ファイルは一通り開けることだけは確認できたが，かなり悲惨なことになっている．一番惨めなのは源氏かもしれない．一見して相当緩くなってしまっている．これを締め直すのはかなり大変そうだ．もっとひどいのは，Ancestry.zelだ．これはほぼ壊滅と言ってよい．とりあえず，読み込むことができたというだけでもよしとするしかない．

「結婚連結線をサポートしない＠20220228」と「MakePairListCleanを一時止める＠20220215」を止めてかなりまともな図面が出てきた．連結線がところどころ切れているのと，ゴミ粒のようなものが散らばっているのを除くと，ほぼまともな図面に戻ったと言ってよい．

▲天皇家でかなりひどいスプリットが出ている．

▲53直系血族図.ZELを開いて，TRIBEBOX::SolveMargboxCollisionで衝突検定ループカウントオーバーが起きている．986個のTYW婚を廃棄したとしているが，衝突は収まらない．「コラッツ特注版ではTYW婚不用＠20211217」を復活させたら収まった．

どうも失敗してしまったようだ．ClearTableには２種類ある．一つはBASETABLE用で，もう一つがいま問題のTOPOLOGY用のものだが，取り違えていた．間違え易いのでリネームしておくことにする．BASETABLEの方をResetTable変更した．

QUICKDBを大幅に書き直してKAKEIZU::getmarriageとgetcarddataでレコード全体を取り出すように修正したところ，データベースのロード処理が劇的に高速化した．これまではかなりの時間待たなくてはならなかったところ，ほとんど瞬時に完了するようになった！1万点を超えるサンプルをそこそこの時間で開けるようにしたいのだが，まだまだ手が届かない．ボトルネックになっているのはセグメント検定だが，それ以外では，ClearTableにかなりの時間を浪費している．

いや，その前にステージ７リンクの検証，ルックアップテーブルの生成にかなりの時間が掛かっている．ここでやっているのは，①CheckDataLink，②MakingLookUp，③NameSortだけだ．⇒どうも重いのは，③NameSortのようだ．改善の余地はあるだろうか？

53直系血族サンプルで，CheckDataLinkの所要時間は1.6秒，MakingLookUpは0秒，NameSortは344msだ．CheckDataLinkはZELファイルを読み込んだ場合ではパスしてもよい．Collatz4000X.ZELでは，NameSortで14.3秒掛かっている．⇒NameSortはlookup.tableを直接操作しているが，ループの中で前詰めを実行しているので，余分な手間が掛かっているのではないだろうか？書き直してみよう．

どうも，大した効果は得られなかった．13.953秒なので300msくらいしか短縮されなかった．いや，そもそも，どちらのサンプルもlookupには穴が空いていないので，前詰めによる時間浪費はミニマムなものでしかない．とりあえず，時間短縮するならNameSortをやらないようにするしかないだろう．これは仕様の問題であり，そう決めればよいというだけの話だ．⇒対処した．

ClearTableは後から見ることにして，三極検定，中でもセグメント検定の効率化が可能かどうかを見てみよう．⇒checkをオンにしただけなのだが，どこか壊してしまったのだろうか？動作がおかしくなってしまった．セグメント検定用のツールが壊れている．それにしても，checkを入れただけで副作用が発生するというのは考えづらい．⇒関数の実行に掛かる時間を測定・表示するために挿入したコードが誤動作していたようだ．GetTickCountで取り出した値はULONGLONGで，printfの書式の説明では%dでlong longを表示できるように書かれていたのだが… 誤動作を避けるため，引数でulong(xxx)で型変換するようにして収まった．

セグメント検定の実行ルーチンであるHorizontalSegmentは小さい方のサンプルでも600msくらい掛かっているが，その中から呼び出しているCheckMaximalSegmentが一回の呼び出しで200ms掛かり，それを3回実行しているので，HorizontalSegmentの実行時間のほとんどはCheckMaximalSegmentが費やしていることになる．従って，CheckMaximalSegmentの処理時間を短縮できれば，それだけHorizontalSegmentも軽くなるということになる．

しかし，その前に３回も実行する必要があるのかどうかもチェックしておく必要があるだろう．⇒３回を入口検査の１回だけに削減した．これだけでもかなり高速化した．トイレに入っている間に大きい方のサンプルが描画できるところまで来た．ここまで来ればそこそこ実用になる．大きいサンプルではHorizontalSegmentを１回実行するのに2.6秒くらい掛かっている．このうち，CheckMaximalSegmentが2.3～2.4秒で大半を占めている．CheckMaximalSegmentはもう少しダイエット可能だと思われるが，その前に系統並び替えに入ってから三極検定に移るまでに掛かっている時間コストを調べておこう．

系統並び替え全体では，サンプルA(1931点)で14秒，サンプルB(12243点)で316秒≒5分だ．まず，バックアップを取ってから始めよう．TOPOLOGY::ClearTableではlookupを使っていない．これはかなり不利だと思う．書き直してみよう．⇒57秒掛かった．修正前の時間を測っていないので，改善しているのかどうかは分からないが，ClearTableだけで1分というのはやはりかかり過ぎのような気がする．なぜだろう？結婚ではlookupを使わないことにしたのだが，かなり疎なテーブルになっている．結婚リンク数が1393のところ，テーブルは3578で3倍近くある．

確かに飛び番になっている．復活させるのはそれほど手は掛からないと思うが…サンプルBでは逆のことが起こっている．PDB，MDBとlookupのカウントが完全に同じだ．つまり，テーブルは最初から密に詰まっている．おそらく，これは以前保存するとき，基準ソートされた状態で保存していたのだろう．基準ソートするとテーブルは完全に前詰めされた状態になる．現在もそういう仕様になっているかどうかは分からない…いずれにせよ，サンプルBに関してはlookupを使っても効果はまったく出ないということになる．LINKTABLE：CheckIfMargValidという検査ルーチンはNOCHECKDATALINKで止めておこう．