異種文字数のカウントにやや問題がある

▲異種文字数のカウントにやや問題がある．異種文字数はBuildPowerGridの中でカウントしているが，この方法だと計算を誤る可能性がある．生成されるマトリックスは必ずしもγ全体に及ぶとは限らないのでカウントされない部分が出てくる可能性がある．異種文字数の計算は少なくともBuildMatrixの中で実施して，BuildPowerGridではその結果だけを使うというようにしないとまずいと思う．また，固定部桁数は別途計算できるので，異種文字数のカウントからあらかじめ固定部を除くようにした方がよい．ただし，マトリックスのカラー表示は現物のマトリックスを対象としているので，その点注意する必要がある．

GetCharNumVとGetCharNumHはテーブルを使わずに直接計算している．ただし，内部で使っている作業用配列は最大MaxOutput=32767だ．これをMAXARRAYSIZEまで拡張しておけばよいのではないか？TestMatrixの中にも異種文字数をカウントしているところはある．ここでは配列上限はMAXSQUARESIZE=32767だ．BuildPowerGridではGetCharNumVとGetCharNumHを呼び出しているので，現状で問題ないのではないか？一応この問題はこれで落着ということにしておこう．

▲R値はテーブルから取り出しているが，セグメントがテーブルの境界をまたいでいる場合には計算できない．⇒セグメント値の計算もGetCharNumVのように直接実行するということは考えられる．GetCharNumVではすべてのR値を現物計算しているので，そこでセグメント単位に加算すればよいはずだ．GetCharNumVでは１～γまでのR値を計算しているので，その中でR=0となる位置を区切りとして集計すればよいのではないか？計算結果を配列に格納しておいて呼び出し側に渡してやれば，なんとかなるのではないか？それほど面倒な話ではないはずだ．セグメントを２つに分割するという話も出てきているが，それはこの工作が終わってから考えることにしよう．

セグメント数をどこで計算していたか見ておこう．この値は現在Y(upsilon)として表示されているものだ．Yはλの固有値でDispModPowで計算している．また，この値はBuildMatrixで転記されてマトリックスのupsionに格納されているから，いつでも使うことができる．とりあえず，matrixにSumR()という配列を置くことにしよう．⇒一応動き始めてはいるが，方式的な欠陥がある．

BuildPowerGridでは最初にGetCharNumVを実行した後，ColoringMatrixを実行しているが，これではsumRを取り出すことはできない．sumRは列毎に異なる値を取るので，格納するとすれば二次元配列が必要になる．一次元で間に合わせようとするのなら，GetCharNumVと並行してカラリングしなくてはならない．GetCharNumVは共通処理，ColoringMatrixは個別処理なので分離しておきたい．とすれば，二次元配列を使うしかない．

横数列は完全周期を持っているので，それほど大きな配列にはならないだろう．幅はXで高さがγ￥Yだ．⇒逆にGetCharNumVの過剰動作が起きている．GetCharNumVはBuildPowerGridから呼び出されているため構築されたマトリックスの範囲のデータを揃えようとしているが，Xがそれよりも小さい場合は過剰動作となる．むしろ，この処理はBuildMatrixに移して標準動作とした方が効率はよいのだが… 現行のまま進めるとすれば，すでに書き込まれた部分はパスするように作らなくてはならない．かなり厄介な話だ．

処理をBuildMatrixに移し，必要な最小サイズの配列を生成するようにする．配列はMatrixに格納しておけばよい．BuildPowerGridではこれをスープストックとして伸ばして使えばよい．⇒しかし，これでもまだ厄介な点は残る．横数列は巡回するとは言え，冒頭の固定部は無視できない．最低でも固定部＋周期列の長さは必要だ．剰余を格納しているMTは実際に生成されるマトリックスに合わせている．