MakingLookUp 問題がひとまず片付いた

MakingLookUpの呼び出し:現行ではNameNarabekaeではMLUは実行されていない.新規ファイルの場合はCOUPLING::OpenFamilyBaseで実行している.通常は,InitLinkTableで一度だけ実行される.CommandEndでTopologicalSortの直前に実行されるMLUは暫定的に停めてある.CommandEndでTOPOLOGY::RebuildCardListを実行している.この中でNameSortが実行されlookupが逆順になっている.lookupを並び替えるのがNameSortの役割であり,それ以外の仕事はない.

NameSortでテーブルに穴が開いている.⇒論理修正した.⇒これで一応穴を塞ぐことはできたが,RebuildCardListでテーブル並び替えを実施する必要はあるだろうか?RebuildCardListでは各種のリストを再構築している.lookupは一覧表の順位に関係するので,つねに同期を取っておくというのが正しいのではないだろうか?であるとすれば,初期オープンの場合もそうする必要があるような気がする.

NameNarabekaeはそれ自身一つのコマンドだが,その中で,BuildNumlistとRebuildCardListを実行している.RebuildCardListの引数でコマンドを渡しているので,NameSortが重複実行されることはないようだが…

@23を削除した後,Undoすると一覧表が逆順になる.⇒解決

どこかでNAMESORTを初期化している.COUPLING:CloseFamilyBase→ Cleanですべての下位クラスがリセットされるような動作になっている.TREEVIEWがやっているようにdoCleanを上書きして,必要なパラメータを保全するか,ないし,レジストリに退避して再読み込みする必要がある.NAMESORTのパラメータはレジストリで保全しているので,InitLinkTableでMakingLookUpの実行後,SortNameを実行する直前に読み直すことにした.これで上記の一覧表が逆順になったりする現象は解消した.

  1. MakingLookUpはInitLinkTableでのみ実行される
  2. InitLinkTableではMakingLookUpを実行し,レジストリからNAMESORTのパラメータを取り出した後,NameSortを実行する
  3. テーブルソート時のリナンバーは実施しない(基準番号はパーマネント変数として原則として変更されないものとする)
  4. 一覧画面では基準番号を表出しない その代わり形式的な行番号を表示する(レコード中には保持されている) ⇒ 現行のまま表示
  5. テーブル並び替えはlookupの並び替えとして実装される lookupの並び替え時には前詰めが実行される

これまではカード番号と呼んできたものが一覧画面の行番号になるとしたら,カード画面に表示される番号はどうなるのだろう?⇒基準番号がユーザから見えないようにするというのは悪いアイディアではないが,カード番号との整合という問題もあり,直ちに実装は難しいような気がする.この点に関しては現行のままとして,しばらく様子を見ることにする.⇒この問題は前々からの懸案事項だったが,ようやく一件落着としてよいと思う.ここで一度バックアップを取っておこう.

世代番号の問題はすでに解決済み.NAMEBOX::getGenerationGapという再帰関数を新設し,TRIBELIST::GetTheEldest,getGenerationGapでは動的に系列ポテンシャルを計算するようになっている.

▲垂直系線の状態がおかしい.YGroup.zelで文字数ないしフォントサイズを変更したら縦系線が伸びてしまうようになった.⇒文字数ではなく,フォントサイズの影響のようだ.文字数など別のパラメータを調整すると正常描画に戻る.⇒フォントサイズを小さい方に変更して,MARGBOX::Drawで(rect.Height() > metrix->geneHeight)のエラーになった.⇒人名枠設定パラメータを操作すれば正しい状態になる.

どうもフローがおかしくなっているようだ.UpdateDiagramもTopologicalSortも掛かってこない.フォントサイズの変更ではトポロジーは変化しないので,UpdateDiagramが

物理世代番号の問題を最終解決してしまおう

物理世代番号の計算を最終的にクリアしてしまおう.系列ポテンシャルを決定する途中計算で物理世代番号を参照しているというのがそもそもの間違いなのではないか?これを回避するためには,やはり動的に系列ポテンシャルを決定する仕組みが必要なのではないかと思う.系列木は木構造になっていて,その頂点に始系列があるという構成になっているが,最古世代系列は必ずしも始系列とは限らないため多少ややこしい話になっている.この辺りを整理する必要がある.

  1. getpotential potentialを返す
  2. GetPotential 系列枠のポテンシャル値(設定すべき値)を取得
  3. getPotential 系統(始系列)のポテンシャル値を取得
  4. getMax 系列最大物理世代番号取得
  5. getMin 系列最小物理世代番号取得
  6. getGeneration 系列枠の(最小)常用世代番号
  7. DEV2LOG 物理世代番号→論理世代番号
  8. LOG2DEV 論理世代番号→物理世代番号
  9. DEV2GEN 物理世代番号→常用世代番号
  10. GEN2DEV 常用世代番号→物理世代番号
  11. MakeTribesPotential 系列を系統に分解し系統ポテンシャル値を設定→使われていない
  12. callSetpotential 系列枠のポテンシャル値を設定
  13. Setpotential 系列枠のポテンシャル値を設定
  14. setPotential 系統ポテンシャルを設定する
  15. TRIBELIST::setStartPotential 
  16. TRIBELIST::SetAbsolutePotential 絶対世代番号系と物理世代番号系を一致させる

子ども一人の結婚枠では結婚枠背景色が描画されていない.→TYW婚は結婚リンクを持たないので,MARGBOX:Drawでは描画されない.

一番の問題はTRIBELIST::GetTheEldestの中でgetFloorを使っている点ではないだろうか?最古世代の検出に物理世代番号を使わない方法を編み出す必要がある.⇒実装した.

▲TRIBELIST::CheckAbsoluteGeneは実行されていない.TRIBEBOX:CheckAbsoluteGeneではsetnodegeneでCARDLINKの絶対世代番号を設定している.つまり,絶対世代番号は確立されていない.⇒絶対世代番号は多重カードクラスタ検定の中で計算されている.この計算には抽象グラフ検証系が必要であるため,暫定的に停止してある.

▲最小反例307.zelで@23のカードを削除してTRIBEBOX::MakeUpTreeのエラーが発生する.同じカードにMakeUpが重複して掛かっている.その後, (nbox->hideflag == HIDE_UNKNOWN)というカードが検出されている.これは,MakeUp重複ノードと同一カードだ.該当ノードは#4213@31で@47の子ども.カードテーブル上では先祖ノードの@35よりも前にある.どうも,ClearTableでリセットされなかったのではないか?という気がする.子どもを3人持っているが,親は@47だけの普通のカードだ.⇒確かに初期化がパスされている.

CARDLINKは#1522だ.このリンク自体が無視されている.ClearTableに入る前にMakingLookupが実行されていない.MakingLookupはCommandEndで実行しているのではなかったろうか?CommandEndでTopologicalSortの直前にMakingLookupを実行するようにして動作するようになったが,カード削除ではlookupでアクセスできなくなるというのはやや不審だ.⇒カードテーブル上の位置は不変だが,lookup->countが減っているのではないだろうか?

初期状態ではlookup[1]の位置に入っている.更新するとlookup[0]になる.つまり,削除されたカードはlookup[0]にあったものだ.どうも,lookupの操作に何かバグがあるのではないだろうか?⇒かなりおかしい.逆順になっている.どこかで並び替えしているのだろうか?

RepairCommonEndPointないし,RepairPairBoxが動作していない

どうも,世代番号の問題をクリアしておかないと先に進めないという状況になってきたので,じっくり,この問題に取り組むことにする.⇒どうも,いま出ている不良ノード対は世代番号とは無関係のようだ.こちらを先に見ておこう.⇒いや,もしかすると関係あるかもしれないノード対は基本世代枠リストで管理するため,物理世代番号が確定していることが必要だ.⇒いや,そのチェックはやっているようだが…

端点一致でsamepointゼロや左端点共有で種別不一致はそれほど致命的な不良という訳ではないが,回復できないという点に問題があるように思われる.これはやはり,後回しの課題なのではないか?⇒RepairCommonEndPointないし,RepairPairBoxが動作していない.これは解決する必要がある.

左下に真っ白い三角形のような奇妙な図式

YGroup.zelを開くと,左下に真っ白い三角形のような奇妙な図式が現れる.初期画面ですでにこの現象が発生する.⇒_CDC::Polygonの論理にミスがあった.⇒解決

関数木グラフというフォルダはバックアップに5個残っている.ZELファイルでは姉妹婚関数木.zelがもっとも大きく81.9KB,その次が関数参照木.zelで76.9KB.関数参照木はすべて匿名化してしまっている.姉妹婚関数木.zelには名前が残っているが,収録点数が41点しかない.このサンプルでは姓にクラス名,名前に関数名が入っている.関数参照木.zelには87点入っているが,残念ながら短縮名になってしまっている.⇒もう一度,一から作り直すしかなさそうだ.⇒いや,もっと大きなサンプルがあった.デスクトップに置いた関数木グラフフォルダには144点というファイルがあった.ただし,これを開くとSUWになる.

TRIBELIST:setStartPotentialという関数を新設し,MainExperimentの冒頭で呼び出すようにして物理世代番号エラーは解消した.SUPPORTSIMPLEGRAPHを止めてあるのが原因である可能性もある.しかし,SUPPORTSIMPLEGRAPHのTRIBEBOX::SetPotentialは少し仕様が異なるので,SUPPORTSIMPLEGRAPHを復活させるときには,この点もチェックする必要がある.⇒いや,物理世代番号が負というエラーは続いている.ただし,これはsetStartPotentialを呼び出す前だ.NAMEBOX::getFloorという関数は物理世代番号を返すべき関数なのだから,負値になるというのはやはりおかしい.

TRIBEBOX::getPotentialでは始系列のPotentialを取り出している.従って,この値をもっと早い時期に確定するか,ないし,動的に取得するかのどちらかが必要だ.⇒TribeRelocationでHorizontalArangementの直後にsetStartPotentialを実行するようにしたところ,PAIRBOX:RepairCommonEndPointでCheckPairBoxのエラーが発生するようになった.⇒setStartPotentialから呼び出されているGetTheEldestの中でNAMEBOX::getFloorが使われているというのはかなり問題だ.

系列は多段継承になっているはずだが,その計算を省略するために物理世代番号を参照するような作りになっているのではないか?絶対座標系変換前は相対世代番号から物理世代番号が割り出せるようになっている必要があるが,そうなっていないように思われる.⇒取り敢えず動作しているので,世代番号の見直しは一時保留して先に進むことにする.

HorizontalArangementの後にsetStartPotentialを実行すると却って事態を悪化させる.CheckPairBoxで左単点共有で種別不一致が発生して収束できずSUWになる.これを外すと,端点一致でsamepointゼロという不良は発生するが,一応収拾して描画まで進むことができる.とりあえず,この状態で先に進むことにしよう.

同上サンプルで氏名文字数を増加させたら,UpdateDiagramでエラーが発生した.BudleStringで(PHASE < MAKEUPTREE)で(!OnCancelBetweenTwo && !OnRetrieveGhost && !OnmergeCardLink) により停止した.UpdateDiagramでフェーズをTOPOLOGICALSORTに落としているためだ.⇒Update中はフェーズエラーを無視するように修正した.

▲同上で人名枠幅を増加させたら停止した.(pdc->GetMapMode() == MM_TEXT)というエラーが起きている.⇒暫定的にエラーを無視.

氏名を数値でソートしているためだろうか?並び替えが効かない.⇒オプションを停止して,効くようになった.

▲MergeCard5.zelを開こうとして,CheckPairBoxのエラーが大量発生して停止しない.その後も,TRIBEBOX:CheckMargBoxChangedで無限ループしている.⇒SUPPORTSIMPLEGRAPHを復活させてみたのだが,却って裏目が出ている.やはり,物理世代番号のところを一度整理しないとダメかもしれない.

テーブル並び替えで系統並び替えが発生するのはおかしいのではないか?⇒対処した.

来訪者カウントが10万人を超えている.

image

中々気持ちがいい.

メールサーバーとの接続が切断されました

2月11日にThunderBirdをVAIOに引っ越しして以来,ロリポップのメールが受信できない状態になっている.受信しようとすると,「サーバーとの接続が切断されました」のようなメッセージが出て中断してしまう.ロリポのサポートに以下のようなメッセージを送ってみた.

「メール受信用のPCを2月11日に現在の機種に変えてからメールの受信ができない状態が続いています.メールを受信しようとすると,「サーバーimap.lolipop.jpとの接続が切断されました」のようなメッセージが出て受信できません.従来の機種では現在もエラーは起きていません.設定は旧機種の設定をエクスポート→インポートしているので,まったく同じです.実際,旧機種と新機種の設定を開いて目視で確認しましたが,異なるところは見つかりません.旧機種は廃棄を予定しておりますので,よろしくお願いします.」

ロリポのアカウントでは何度か事故が発生しているので,ほとんど使っていないのだが,まるきり使えないというのも具合が悪い.もう一つAYANETでも以下のようなエラーが起きているが,続行で処理できるので,とりあえず放置してある.

image

カスペルスキーはこのあと,以下のようなメッセージを表示している.

image

カスペルスキーの証明書というのもインストールしてみたが,解消しない.ゼルコバの木の出力も大分整ってきたので,修正をフィックスできるところはフィックスしておくことにしよう.仮修正が19件ある.

  1. 座標軸の転換:
  2. コラッツ対応版応急措置@20211219
  3. MAXIMALGRAPH::MergeUpperSegment:goodson不在の代表枠
  4. CheckMaximalCompactionの実行抑制
  5. NAMEBOX::CheckUnerasable:結婚枠不在でフェーズ不正
  6. NAMEBOX::EraseGhostName:
  7. NAMEBOX::RestoreYoungWife:RestoreExtractBoxでOnTYW2ExtractBox
  8. TRIBEBOX::StopTooYoungWife:RestoreYoungWife → 保留
  9. TYWカウントなどに関する修正
  10. 参照ヘッダファイルの調整
  11. IsAinstanceOf → 廃止

TYWの操作関数

  1. MARGBOX::ResetTooYoungWife
  2. MARGBOX::TYW2ExtractBox
  3. NAMEBOX::MakeTooYoungWife
  4. NAMEBOX::RestoreExtractBox
  5. NAMEBOX::MakeZeroTYW
  6. NAMEBOX::RestoreYoungWife
  7. NAMEBOX::ExtractBox2LDRsub
  8. NAMEBOX::ConvertZTYW2TYW

新規ファイルを開こうとして例外が発生した.⇒KAKEIZU:readFamilyBaseではファイルが存在しない場合は,ERR_FILENOTEXISTを返しているが,新規ファイルの場合は0を返しているため識別できない.仮のファイル名「ゼルコバの木.zel」が返るようになっている.⇒InitLinkTable→getmarriageで例外が発生する.通常の手順で結婚データを取りに行って,空のテーブルが返されるため最初のitem[0]をatolに渡したところで例外が起きている.この項目では空ポインタをチェックしていなかった.⇒atolを呼び出している箇所をすべて点検して,空ポインタをチェックするようにした.

▲極小反例307.zelを開いてエラーが発生した.GENELIST:GetGeneBoxでgnum=-4という値が与えられている.この関数は物理世代ベースなので,gnum>=0でなくてはならない.getFloor関数が負値を返しているようだ.⇒始系列のPotentialが設定されていないためではないかと推定される.エラーを無視して描画できるようなので,この件に関しては後日調べることにする.⇒世代枠は物理世代番号0以上であることが必須になっているようで,ノード対リストが確保できない状態になっている.

また,上のサンプルを開いて,カラー設定を変更してファイルを上書き保存しようとしてエラーになった.⇒別アプリでファイルを開いていたためだ.何か適切なメッセージを出す必要がある.⇒CFile:Openを呼び出すときに,CFileExceptionを渡してエラーステータスを取り出せるようにした.エラーが発生した場合にはメッセージを出して復帰する.⇒障害が再現できなくなってしまった.CFile:Openは別のところでも使われている.点検して整備する必要がある.

初期起動→新規ファイルのフローで,LoadDefaultThemeの実行…→UpdateDiagramdeで(prewidth == 0 || preheight == 0)で停止した.⇒系統並び替えがまだ一度も実行されていないためと思われるので,TRUEで復帰するようにした.

▲極小反例307.zelを開いたあと,YGroup.zelを開いたところ,下図のような奇妙な図面が出てきた.これは前にも一度出たことがある.

image

どうやったらこのような図面が出てくるのか?想像も付かない…このような図形が出るとしたら,ポリゴンしか考えられないので,マークを表示している箇所を調べる必要がある.

縦系図と横系図の切り替えをサポートする

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

image

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

image

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

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

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

image

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は親を2人持っていて,それがCheckYrouteだ.どうもかなりややこしい話になってきた.

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

image

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

image

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

image

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

image

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

image

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

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

  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では多重カードが3件出ている.これは削減できないのだろうか?あるいは,どこかで機能劣化してしまった可能性もある.

image

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

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

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

TYWに関係する処理の見直しを進めている

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を開こうとしてエラーになった.

image

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

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

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

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

moveがゼロのときはZTYWとしない

MakeZeroTYWで「moveがゼロのときはZTYWとしない@20230219」として,描画できるようになった.155件のTYWが成立している.ZTYWはゼロだ.TYWは世代差がある場合にのみ適用されるのではなかったろうか?だとしたら,TYW存在すること自体おかしいということになるのだが… ⇒こんな感じになっているようだ.

image

2601と5203は別々の箱に入っているので,兄弟枠内の間隔よりも離れている.このため,この2つの子ども枠を結婚点一致させようとすると衝突が発生してしまうという理由でTYWになっているのではないだろうか?ただし,これはTYWではなくZTYWではないかという気がするのだが…⇒TYWを止めるとどうなるかを見てみよう.⇒確かに,ルール通りの動作になっている.

image

従って,動作的には問題ないと言えるのだが…TYWのリセットが頻発しているのはなぜか?⇒結婚枠の衝突には許容上限があり,TYW枠がMAXCRUSHCOUNTを超えると抽出枠に落とされるようなルールになっている.たとえば,@4067のTYWはリセットされている.TYWがリセットされるとTooYoungListからも外されて,リセットされたノードがZTYWの場合はそこで処理が終了する.従って,生き延びたTYWはそのまま残存しているということにはなるが,ZTYWカウントがゼロというのはなぜか?

ZTYWは系列枠ごとに集計しているZTYWCountを合算したもので,CheckMultiCardsで集計している.この数が当てにならないのではないか?大域変数 ztywcount は人名枠属性を設定するところで直接カウントするべきだろう.ただし,この値はMARGBOXのIsZtywBoxを見ていることに注意.IsZtywBox では,(ERASEDYOUNGWIFE|TOOYOUNGWIFE) を見ているが,ここではERASEDYOUNGWIFEだけを見ることにする.

方式変更してZTYWが173と表示された.ただし,TYWが155で数が少ない.基本的にこのサンプルではTYW=ZTYWとならなくてはならないはずだ.どこでこの食い違いが生じているのだろう?MARGBOX:ResetTooYoungWifeでは,TOOYOUNGWIFEはリセットされているが,ERASEDYOUNGWIFEは放置されている.⇒対処した.これでTYWとZTYWのカウントが一致した.つまり,ZTYWが173個生成され,うち18個が解除されて155個残ったということにになる.

赤色表示しているはずのTYW本人ノードがまったく見えないのはなぜか?⇒おそらく,TYW本人ノードというのは不可視になっている方だろう.⇒TOOYOUNGWIFEを含めていなかった.⇒出てきた.

image

これで見ると,なぜTYWになるのかがよく分かる.これでよいのではないか?結婚枠衝突の上限はもっと小さくてもよいのではないだろうか?現行ではMAXCRUSHCOUNTはMAXCHANNELFAILUREにそろえてある.MAXCHANNELFAILUREは現在20だ.MAXCRUSHCOUNTはいろいろなループの上限として使われているが,直観的には10回くらいで十分であるような気もする.

MAXCRUSHCOUNT=10という設定ではTYWは129まで減少する.系統並び替えの所要時間は104秒.従来の設定に戻すと,時間はむしろ短縮して73秒になった.ほぼ無制限=100という設定では,処理時間が相当長引くほか,「不可視ノードの座標補正」というのが入って停止しなくなる.どうも,やはりある程度の歯止めがないと無理なようだ.MAXCRUSHCOUNT=30でも抜けて来なくなる.どうも,この値はかなりクリティカルだ.この場合もやはり,不可視ノードの座標補正というのが入る.「不可視ノードの座標補正」というのは,ほぼ検定に失敗したことを意味している.とりあえず,ここは現行のママとしておこう.

ここで,moveがゼロのときはZTYWとしない@20230219を復活させてみよう.⇒衝突検定でループカウントオーバーになる.事後の後処理中,NAMEBOX::RestoreYoungWifeで(!getghostbits(ELDERWIFE|ERASEDYOUNGWIFE))のエラーになる.これは論理的におかしいので,調べておこう.TooYoungListに記載されたノードで属性を持たないものが検出されたというエラーだ.RestoreYoungWifeは結婚枠と同期を取っているので,結婚枠と本人ノードに不一致が生じていることになる.つまり,本人ノードのELDERWIFE|ERASEDYOUNGWIFEをリセットするときに,結婚枠の属性が放置されたままになっている.

MARGBOX::ResetTooYoungWifeの他に,NAMEBOX:RestoreExtractBoxでもリセットしている.この中でもIsTooYoungWifeの場合は,ResetTooYoungWifeを呼び出しているのだが… 衝突回数オーバーなどでなにかイレギュラーな操作を行っているのではないだろうか?しかも,このケースではtywboxを削除までしているので,リストに残っている可能性はゼロだ.

ERASEDYOUNGWIFEはMARGBOX::ResetTooYoungWife,NAMEBOX:ExtractBox2LDRsub,NAMEBOX::ConvertZTYW2TYWでもリセットしている.ResetTooYoungWifeではTYW婚をリセットしているので,結婚枠もリセットしなくてはならない.⇒いや,それはやっている.ExtractBox2LDRsubでは抽出/TYW枠のチェーンをLDRの長い尻尾に転換している.この関数の中でもResetTooYoungWifeが実行されている.ConvertZTYW2TYWではTYWをZTYWに変換している.この場合はTYWはリセットされないので問題ないはずだ.

TRIBEBOX::StopTooYoungWifeの修正に誤りがある.仮修正@20230217だ.従来論理ではTYW2ExtractBoxでTYW→抽出枠転換していたものを,RestoreYoungWifeで廃棄するように仮修正しているが,呼び出しの主語が誤りだ.⇒修正して動作するようになったが,別のエラーが出てきた.①衝突検定ループカウントオーバー,②Yリスト上位ノード不在,③TYW婚の吸収合併成功,④NAMEBOX:CheckUnerasable 結婚枠不在,⑤多重カードが怒涛のような嵐となって吹き荒れている.それでも,エラーを無視して描画できた.

続きをやろうとしたら,初っ端からエラー

昨日の続きをやろうとしたら,初っ端からエラーに見舞われた.

▲サンプルAを開いて,RestoreYoungWifeのエラーで停止した.

image

昨日の修正で作り込んだエラーだ.バックアップに戻ろうとしたが,昨日の修正がまったく入っていない.昨日の修正はかなりボリュームがあるので,やり直しだけは勘弁してほしい.⇒TYWに関係する部分なので,「コラッツ特注版ではTYW婚不用@20211217」をオンにすれば戻ると思ったが,オンになっていた.どういうことだろう?かなりおかしい.⇒いや,違う.いま見ているのはバックアップの方だ.

「コラッツ特注版ではTYW婚不用@20211217」で描画できるようになった.タモリさんちの拡張家系図や渋沢一族なども(概ね)問題なく描画できている.そうなると,TYW婚というのは不用なのではないか?という気もしてくる.TYW婚の起源まで遡るのは難しいかもしれないが… どういう事情で導入することになったのか?その経緯が知りたい.

2021/01/21の記事に,弘徽殿女御がTYWになっているという記録がある.源氏には複雑な関係が多いので,その加減かもしれない.

▲部分図の選択解除という操作がないのは仕様的に問題だ.源氏6を開いた状態→新規部分図でエラーが発生した.また,このサンプルでは多重カードが11件発生している.特に光源氏と冷泉院は3重カードになっている.⇒TYWオフになっているためだろうか?⇒TYW婚をオンにしても多重は解消しない.ただし,源氏と冷泉院の3重カードというのは出なくなった.血族婚が存在する場合には多重は不可避だったような気がするので,11件のうちのいくつかはそれに該当するのではないかと思われるが…「異世代多重反復カウントオーバー」というのが出ている.

いずれにせよ,TYWという機能は必要と思われるので,コラッツサンプルでなぜ多量のTYWが発生するのか?また,TYWを停止しても収束できないのはなぜかを突き止めなくてはならない.

▲TRIBEBOX::StopTooYoungWifeの中で停止する.TooYoungListに記載されているノードでELDERWIFE|ERASEDYOUNGWIFE属性を持っていないものがある.

V.2.3.0.000 R.2023-02-17 をリリース

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

  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秒掛かっている.その後のステージ9:Decomposition,ステージ11:GODOWNSTREAMもかなり掛かる.⇒CheckMaximalSegmentの出口で行っていたCheckMaximalCompactionの再検査を止めてかなり高速化した.それでもサンプルBの系統並び替えでは253秒で4分以上掛かっている.とりあえず,今のところパフォーマンスについてはここまでとしておこう.

◎現在開発機にインストールされているのは,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を5秒以内に開くことができる.サンプルBの系統並び替えが55秒だ.悪くないと思う.バージョン番号を更新しておこう.現在のバージョンは2.2.2008だが,2.3まで上げてよいのではないだろうか?⇒インストールに成功した.

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

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

image

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

image

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

image

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

image

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

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

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

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

image

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

image

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

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

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

image

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