準備は整った．さて，ここからどういう方向に進むのかが問題だ．ストレートにラテン群表に舵を切るか，もう少し環境を整えてからじっくり進めることにするか？いずれにせよ，VS2019から2022に移行することが必要になることは目に見えている．この移行を滑らかに進めるためには，2019でできることをできる限りやっておくことではないだろうか？アリアドネの糸巻きは３年前に着手したプロジェクトだが，完成する前に中断した状態になっている．これを正当に継承することも必要なのではないか？その意味では，中間形態ではない完了形態としてアリアドネの糸巻きを仕上げておくということも必要なのではないだろうか？
それは悪いアイディアではないと思う．かなりの期間開発から外れていたので，いろいろなところがおぼろになっている．その辺りを突き固めるためにも有効なのではないか？Visual Studio には開発支援のためのさまざまなツールないし環境が提供されているが，まだ一度も使ったことがない．コード分析というのは中でも一番基本的なものであり，2022以降では必須ということになりそうな気配もあるので，まず，これを試してみることにしよう．通常のビルドではエラーは発生しない．
最後に一つだけ，「プロジェクトのプロセッサ アーキテクチャ “MSIL” と、”ElsieProject.dll” のプロセッサ アーキテクチャ “x86” の間には不一致がありました。」が出ているが，これはおそらくすべてのプロジェクトをx86に切り替えないと解消しないのではないかと思う．そうできるかどうかも不明だし，少なくともいまはその時期ではないだろう．
分析メニューの下にはコードのクリーンアップというのがある．プロファイル１と２があるが，どちらも中身は同じようだ．ドキュメントのフォーマットの自動整理のようなことをやっているのだが．．．これはお任せでよいと思う．さてコード分析だが，こちらはかなり大量の警告が出る．とりあえず，プロジェクト単位に片付けることにしよう．まず，その前に開始プロジェクトをバックアップしてから始めるとしよう．
▲なぜだろう？マウスは共有できているのに，キーボードの共有ができない．⇒今まで使えていたはずだが．．．⇒キーボードを開発機に繋ぎ変えて使えるようになった．理由は分からない．
▲警告 C6001 初期化されていないメモリ ‘bn’ を使用しています。 Ariadne100 D:\アリアドネの糸巻き\Ariadne100\Algorithm.cpp 87
GetStartPointという関数だ．確かにまったく初期化されていない変数bnをHB[i]に入れている．この関数は「ﾊｯｾ図を解析して，開始点を決定する」ものだ．何のハッセ図か？内部でSBとHBという２つのテーブルを構成している．その他に，グローバル変数としてSという２次元配列が使われている．このテーブルには「Shuffle convert table2」というコメントが付いている．その他にも一文字変数でF, D, L, R, G, H, PT, PSというのが使われている．意味がわかった．
bnはMakeHasseDiagramでbnを参照渡しで更新している．これがエラーになるとすれば，参照渡しという引数が使えなくなる．．．⇒これはとりあえず，変数を直接として渡すことにしよう．⇒いや，この対応は間違っている．単純にbn=0としておけばよいだけだ．
類似エラーとして，
▲初期化されていないメモリ ‘P’ を使用しています。⇒Pは配列で，ループの中で初期化されているが，意味が通じていないようだ．面倒くさいので最初に０クリアしておこう．int P[DMAX + 1] = { 0 }; でよい．
▲フォルダを「アリアドネの糸巻き」に指定したら，エラーが出た．
‘Microsoft.Common.CurrentVersion.targets’ を開こうとしたときに ‘その他のファイル’ でエラーが発生しました パス ‘C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets’ の一部が見つかりませんでした。
▲ 演算のオーバーフロー: 4 バイトの値に演算子 ‘*’ を使用し、結果を 8 バイトの値にキャストしています．ABORTLIMIT (NN*NN*0.5)というマクロだ．NNはintでx86では４バイトかもしれない．NNはグラフの頂点数で高々1000くらい．int()でキャストしたら収まった．
▲文字列 ‘s’ は 0 で終了しない可能性があります．⇒{0}で初期化．
▲初期化されていないメモリ ‘D’ を使用しています。⇒ループで初期化しているのだが．．．１発進がまずいのだろうか？⇒{0}で初期化．
▲index’ から無効なデータを読み取っています: 読み取り可能なサイズは ‘(unsigned int)bn*sizeof(int)’ バイトですが、’8′ バイトを読み取る可能性があります。⇒これは完全な誤読と思われるが，どう対処したらよいか？ソースファイル内で止めるという方法もあるらしいが．．．配列ではなく，ヒープを使っているために混乱している模様だ．メモリサイズをbn+1にしたら一応解消したが，if (index[i] > index[j]) でまた止まった．j=i+1としているので，iより大きいと思いこんでいるのだろう．実際は，j<bnで押さえているのだが．．．
同種のエラーが８箇所ほどある．あるいは，int *index に対し，index[i]のように配列としてアクセスしているのが気に入らないのだろうか？むしろ，配列として生成し，解法すればよいのではないか？というか，ローカル変数なのだから自動的に解放されるだろう．いや，どうも配列サイズは定数でなくてはダメなようだ．その代わり？vectorなら動的に生成できるようだ．どうもだいぶ込み入った話になってきた．これは結局 vector を使えという話ではないだろうか？
上では{0}でゼロで初期化としていたが，{} で初期化する方が安全なようだ．{a}とすると，aで埋め尽くすのではなく，最初の１個だけがa，残りは０ということになっているようだ．
std::vectorを使ってエラーは解消した．すべてこれで通すことにしよう．⇒すっきりと，全部消えた．これでよいことにしよう．
▲zeta = hugenum((N – u) + N * (N – v)); のエラーが取れない．どうキャストすればよいのか？hugenumというのは自前の関数のように思われるが，.upperにlong double の値を格納し，.lowerにはulongint の値を格納している．何をやりたいのかよく分からない．これはおそらくBigIntegerのようなものを自前で作りたかったのではないだろうか？
BigIntegerはこのプロジェクトでは３個所にしか現れない．Form2.vbのColoringStripeとColoringOn，ColoringCycleだけだ．BigIntegerを使っているのは，ModPowという関数が使いたかったためではないかと思う．計算結果はInt64に格納されている．2023/09/16にはhugenumの名前が出てくる．ここで，「matrixはhugenumの行列になっている．これをcpp_intに切り替えるか，ないしC#に持ち出してBigIntegerが使えるようにしなくてはならない．」という話が出てくる．
cpp_int というのは，Boost Multiprecision Library 入っているクラステンプレートで，任意サイズの整数が扱えるとなっている．つまり，BigIntegerと同等なのではないだろうか？結局この作業は中断して終わることになるのだろう．cpp_intでは固定サイズの int128_t とか，uint256_t などというのも扱えるようだ．boostより高速なGMPというのもあるようだ．C#にはBigInteger があるが，使われた形跡はない．
ElsieComeBack にはPsiNumbers.h というファイルがあり，多分このψ数というのが巨大数になるのではなかったろうか？ElsieProject というプロジェクトにはラッパーしか入っていないので，