マイクロソフトが系図作成ソフトを販売している！やられたかな？開発元はIW Technologies LLCという（怪しい）ところで多分2011年にはすでに発売されていたのではないかと推定される．販売価格580円！価格的にはゼルコバの木に勝ち目はないが，スクリーンショットで見ると下図のようなシンプルなものなので，まだ当分の間リードを保つことはできるだろう．お手頃価格なので当所の財政でも購入可能だが，評価はもう少し手が空いたときにやることにしよう．
いや，これは「マイクロソフトストア」で販売しているというだけでマイクロソフトが開発したものではない．この手の系図作成ソフトは掃いて捨てるほど存在する．昨日見たのはこれではなかったような気がする．Windows 10の新機能というポップアップから誘導されたところにあったと思う．⇒出てきた！この画面だ．
よく見るとこれらはすべて「テンプレート」だ．つまり，Excel, Word, PowerPointなどを使ってこれくらいのことができますというお手本．確かにこれは頭のよいやり方かもしれない．特別な系図作成ソフトを使わなくてもそれなりに見栄えのするコンパクトな系図図面が出力できるというのは結構需要がありそうだ．「Buy Microsoft 365」というボタンが表示されている．Microsoft 365はサブスクリプションで個人用でも年間1万3千円掛かる．確かにOfficeは有用なアプリなのでそのくらいの値打ちはあるかもしれない…こういう汎用性（なんでもできるという万能感）のあるソフトというのはわたしの好みだ．
Shirley（ミニノート）へのVisual Studio 2017のインストールは完了している．ツール→拡張機能と更新プログラムでMicrosoft Visual Studio Installer Projectsをインストールしてからソリューションを読み込んだところ，VBを除く3つのプロジェクトがすべて（利用不可）になってしまった．これはエンタープライズ版を立ち上げたときと同じ状況だ．32ビットCPU機のShirleyにVisual Studio 2017をインストールすること自体は成功しているので，64ビット機（のVS2017）で構成したプロジェクトは32ビット機（のVS2017）環境では動作しないということになる．32ビット環境でプロジェクトを構築し直せば多分使えるものができるのではないかと思われるが，手が掛かりそうなのでしばらくは置くことにして本線に戻ることにしよう．
天皇家で垂線がブツブツに切れているという問題がある．これほど「派手な不具合」が長期間見過ごされてきたということは考え辛いので，VS2017に移行したことによって発現した不良であると考えてよいのではないかと思っているが，真偽のほどはいまのところわからない．バージョンパネルやカード画面の下部が切れてしまうという事象もVS2017で初めて起きていると考えられるのでVisual Studioの生成するコードに何らかの変異が起きていると考える方が素直なのではないかと思う．
描画がこの程度に壊れていれば目視で確認することも容易だが，ごく一部の線分が切れていたりなどのことがあったとすれば見落としてしまうこともあり得る．正しく描画できているか否かの検査は目視で行うしかないが，テストサンプルは膨大でしかも包括テスト中はめまぐるしい速度で画面が更新されるのでその中で不良を目視で発見するというのはかなり難しい．ここから目視に頼るのではなく，論理的に不良を検出できるようにしておくべきだという教訓を得て，線分の接続関係をグラフの連結性の問題として抽象化するという方針を立てた．
作業は順調に進んでいるが，テスト環境を構築する前に昨日提示した2つの改善項目を片付けてしまうことにする．実際これらを片付けてしまわないと思わぬところで不測の事態が発生するリスクがあるので先行して解決しておかなくてはならない．課題は2つあるが，分節すると，①SIMPLENODEにリスト構成用のスロットを増設する，②LISTクラスを拡張して任意のスロットを用いたリストを構成できるようにする，③NODULE::nodegeneをSIMPLENODEに移管する，④nodegeneを参照しているタスクでは枝グラフ生成時に値を設定するのようになる．
このうち①，②，③は比較的簡単な話だが，④については少し考えておく必要がある．有限半集合を推移簡約表示したものというのがハッセ図の定義だが，ここで使っているハッセ図という用語はもう少し特殊なものだ．系図は親子関係を半順序関係とする有向非循環グラフと考えることができるから，それを推移的に簡約した配置を求めることが系図作成のための図法であると言ってもよい．ゼルコバの木では結婚枠ないし人名枠を「世代」によって階層表示しているので，平面描画可能なハッセ図を生成するためにはどうしても世代を考慮しなくてはならない．
重婚同類循環グラフ検定では重婚同類グラフ1, 2, 3という3つの枝グラフを使用している．ここでハッセ図と呼んでいるものは内部的には重婚同類グラフ2と呼ばれるものに等しい．この処理をアプリケーションから切り離して完全に抽象化するというのは難しいというより不可能と考えられるが，SIMPLEEDGEには類似概念としてgenerationというのを扱っているので，これがどういう動作になっているのかを見てみたい．generation→_generationと改名して出現箇所をチェックしてみる．
この値は，SIMPLEGRAPH::addで設定されているが，参照されている気配がない．おそらく「このパラメータは現在使われておりません」という状態になっているものと思われる．不用なものが入っているのは望ましくないので廃止しておこう．「SIMPLEEDGE_generationを廃止＠20201020」を定義してコンパイルオプションで切り分けることにする．⇒廃止した．ここで一応バックアップを取っておこう．さて，nodegeneをSIMPLENODEに移すことができるかどうかを見ることにしよう．問題はこのパラメータをどこで設定しているか？にある．
この値は基本的にハッセ図を扱うところでしか参照されていないのではないかと思うのだが…⇒値はnodule::setnodegeneで設定されている．初期値0を与えているところを除外すると，以下の関数でsetnodegeneが呼び出されている．
- NAMEBOX::MakeExtractBox
- TOPOLOGY::TestInevitableMultiZeroのステージ【18】
- TRIBELIST::AdjustTribeGeneration
- SIMPLEGRAPH::TightenHasseDiagramのステージ【７】
- SIMPLEGRAPH::DownStreamHasse 3箇所
- SIMPLEGRAPH::UpStreamHasse
- TREEVIEW::UpdateDiagram
setnodegeneの逆関数getnodegeneの出現箇所を見てみると68箇所もある．ファイル単位ではInevitableMultiCard.cpp，Potential.cpp（検査用），SimpleGraph.cppの3本で基本的には枝グラフ処理の内部処理ないしその関連と考えられる．
TestInevitableMultiZeroとAdjustTribeGenerationはTRIBELISTのTribeRelocationの中で一回だけ実施される．前者はステージ【５】重婚同類グラフ検定，後者は【５.１】で実施されている．UpdateDiagramは描画フェーズの中でしか実行されないので，操作不要と思われる．SIMPLEGRAPHクラスの関数ではすでにグラフは生成済であるはずだから，内部の値を参照することは可能と考えられる．つまり，nodegeneはTribeRelocationの中で設定され，グラフ検定の内部で操作されているものと推定される．重婚同類グラフ検定の概略手順は，
- TOPOLOGY::TestInevitableMultiZero
- TOPOLOGY::VerticallyTightenHasseDiagram
- TRIBELIST::AdjustTribeGeneration
のようになっていると見てよい．MakeHasseDiagramは最初のTestInevitableMultiZeroの中で実行されているので，少なくともnodegeneのスコープは重婚同類グラフ検定中と見て間違いないと思われる．ただし，最後のAdjustTribeGenerationはグラフ検定によって決定されたnodegene（絶対世代番号）に従って構成要素の再配置を実施しているはずなので，この時期までは関係する枝グラフが存続していなくてはならないと考えられる．しかし，その修正を一時に導入するというのはリスクが高過ぎる．nodegeneが必要となるオブジェクトはCARDBOXとMARGBOXだけなのだから，むしろその上位クラスであるBobjectに預けるというのが順当なのではないだろうか？
HasseDiagramに関連する関数はSIMPLEGRAPHのクラスメンバーということになっているが，ここで扱っている図式は数学的に定義された純粋なハッセ図ではなくむしろその応用と考えるべきであり，その意味ではこれらの関数が応用クラスであるBobjectを参照しなくてはならないという構成の方がより論理的であるように思われる．つまり，SIMPLENODEにnodegeneを持たせるという仕様はSIMPLEGRAPHに不純な要素を持ち込むということに他ならない．これで方針は決まった．
tamo2さんからコメントが入っていた．i5のVAIOノートを送って下さるという．このパソコンではゼルコバの木ver.1.99999が走っているという．ありがたい！これがあれば鬼に金棒だ．さて，修正に取り掛かることにしよう．③と④は③’NODULE::nodegeneをBobjectに移管するということになる．この修正はキャストをちょこっと直すだけだから，すぐにでも終わる．「NODULE：nodegeneをBobjectに移管する＠20201020」を定義した．
まずい．一つ勘違いしていた．CARDBOXではなくCARDLINKだ．CARDLINKの親はnoduleでBobjectではない．ではMARGBOXはどうなるのか？少し混乱があるような気がする．いずれにしてもCARLDINKとCARDBOXの対応は1対多だが，MARGBOXとMARGLINKの対応は1対1だから，このまま進めることにしよう．やや変則的になるが，CARDLINKとMARGBOXの両方にnodegeneを置いてみる．
少しややこしい話になってきた．COMPLISTでもnodegeneを使っている．なぜだろう？COMPLISTというのはグラフの連結成分リストで純グラフ理論的なオブジェクトであるはずなのだが…どこかで必要になるのだろうか？かなり面倒くさい話だが，現在のロジックを壊す訳にはゆかないので，COMPLISTにもnodegeneを持たせるしかない．これでは結局SIMPLEGRAPHの内部に外部要素を抱え込むことになってしまうのだが…NAMEBOXでもnodegeneが存在することを予定したコードがある．この論理は少しおかしいのでコメントアウトしておく．場所はNAMEBOX::AbsoluteGeneGapだ．
Dドライブの空き容量がゼロになってしまった．Eドライブにはまだ151GBの余裕があるので少し空けてみよう．バックアップフォルダはZELKOVA_2021とする．テストサンプルも相当大きいのでCドライブに移すことにしよう．⇒エクスプローラのドライブの残量表示バーがすべて青になった．Dドライブは37GBの空き，Cは64GB，Eが129GB，外付けのGが926GBとそれぞれ適当な空き領域を持っている．これだけあれば，しばらく遊べるだろう．
CARDLINKにはcleanという関数がないのだが，いいのだろうか？MARGBOXにはある…TESTABSOLUTEGENERATIONというオプションは一時的に止めておくことにする．⇒どうも訳が分からなくなってきた．nodelist の中にCOMPLISTが入っている．どういうことになっているのだろう？「予定が狂った」というのはこのことだ．nodelistには181個のノードが入っている．⇒ハッセ図を扱っている重婚同類グラフ2の節点はCOMPLISTだ．これはキャストをCARDLINKからCOMPLISTに変えれば対応できる．
どうもどこか壊してしまったようだ．SIMPLEGRAPH：TightenHasseDiagramのステージ【７】移動対象となる人名リンクの絶対世代番号を設定するで停止してしまう．(MINMOV == _INT_MAX)になっている．ループの中ではまともな値を取っているのにループ外にでて突然初期値の_INT_MAXに戻ってしまっている．マネージド デバッグ アシスタント ‘ContextSwitchDeadlock’ という障害まで起きている．確かにどこかでハングしているような気配はある．⇒一度開発機を再起動してみよう．
デバッグアシスタントでは止まらなくなったが，状況は変わらない．「SIMPLENODEsLINKを廃止＠20201019」をオフにして動作を確認してみよう．⇒やはり同じだ．つまり，どこかを不用意に壊してしまったということのようだ．一度バックアップに戻るしかないが，バックアップが動作していることをまず確認する必要がある．⇒確かにこの版はまともに動いている．WinMergeをインストールして比較してみよう．
- nodule::getnodegeneとsetnodegeneがコンパイルオプションを付けずにまるごと削除されている⇒ただし，このコードはRingLink.cppに移されている．
- SimpleGraph.cppのSIMPLEGRAPH::TightenHasseDiagramでコンパイルオプションがネストしているところで記述を誤っている⇒ただし，このコードは検査用コドなので動作には関係しない
- ．．．