ゼルコバの木テント村
とりあえず，数値から色コードへの変換はできるようになった．縦数列のカラリングは列単位に実施する．⇒おおよその実装は終わったが，いくつか問題がある．
縦数列はγを周期として循環しているので，γ^2のテーブルがあればセグメント値を計算することはできる．多少ややこしいが，それをやるしかないのではないか？あるいは，テーブルを生成するときセグメント境界まで膨張させたテーブルを作るか？
項１に関してはセグメントを２分割することが考えられる．２分割して計算すると，回文になっている部分は上下で同じ値になるが，和が同じになる数列を分離できる可能性がある．多分この方が少しわかり易くなるのではないかと思う．
セグメント数Yはγの奇偶によって奇偶が変わる
▲γ=20で奇妙なパターンが現れた．α=7．ε=4で真ん中のセグメントだけ縦縞が出ている．
メールボックスをずっと放置していたが，久々にアクセスしてアーカイブしようとしたところ，メモリ不足で処理できないというエラーになった．フィルタを調べてみると中身が空っぽになっている．それどころかメールボックスのフォルダ自体が161MBしかない．つまり，ほとんど空っぽになっている．バックアップを見ると26GBくらいあるので完全に空になってしまったと言ってよい．なぜこんなことになってしまったのか？ほとんど見当がつかない．
ネットアクセスに関してはいろいろと問題が起きているので，どこかの時点でハッキングされている可能性は高い．最近はメールボックスのバックアップをほとんど取っていなかったので，直近のバックアップは2022-03-20というのしかない．それでも空よりはましなので差し替えておくことにしよう．⇒なんとか完了した．未分類メールが大量発生しているが，あとで始末することにしよう．
いよいよ，縦数列のカラーリングに入ることにしよう．まず，一般的に数値を色コードに変換するルーチンを作る仕事がある．これが結構難しい．整数をRGG６桁の16進数にエキスパンドないし圧縮すればよいのだが，適当に散らばらせるためにはビット操作するしかないように思われる．多分，圧縮の場合は（事実上）考えなくてもよいのではないかと思われるので，エキスパンドの方法について考えてみることにしよう．
数値から直接RGBに変換するというのは難しい．むしろ，HSVを使った方がよさそうだ．Hは色相，Sは彩度，Vは明度だ．Hは0≦H≦360，S,Vは0≦S,V≦100だが，数値をHに変換し，SとVは固定でもよい．これなら簡単に実装できる．HSVからRGBへの変換は以下の式で行える．⇒以下のサイトからコードを拝借した．
https://dobon.net/vb/dotnet/graphics/hsv.html
ちょっと派手目な色になってしまうが，仕方ないだろう．あとは縦縞を描くだけだ．こちらも少し面倒くさいがなんとかなるだろう．
べき剰余数列に現れる０の扱い方が間違っていた．一度０が発生するその後は０が続くことになるので，当初は０という一字だけの最短の周期列とみなすという立場を取っていたのだが，どこで切り替わったのかよく覚えていないが，いつの間にか０は周期列に入れない，つまり，周期列を持たない固定部だけの数列ということになってしまった．しかし，一文字だけ連続するというのは０に限った話ではなく，マトリックスの一行目は必ず{1,1,1,1,…}となるし，１や０以外の数字が並ぶ{9,9,9,9,…}とか，{10,10,10,10,…}などというのも頻繁に出てくる．
異種文字数をカウントしてその行ないし列の異種文字数と周期が一致しないような場合を濃色で表示することにしているが，この場合，０を周期列にカウントしないと横数列の異種文字数例外と縦数列の異種文字列例外が整合しなくなってくる．縦数列では縦に集計した異種文字数はそれ自体が横数列としての周期を持っているが，その例外となるのは固定部を持った列のみであるはずなのに，うまく数字が合わなくなる．従って，{0}はそれ自体周期列であるとする以外にないと思われるが，修正はかなり広範に影響する可能性があるので，慎重に行う必要がある．どこから着手すればよいか？
固定部のoffsetを計算している箇所は多分２箇所と思われる．ラムダ関数とPowerResidueFuncだ．どちらもこのツールの要と呼ぶべき重要関数だが，まず簡単そうなラムダ関数の方から見ることにしよう．⇒この関数ではγ＝１のときoffset=１としているが，これでよいのだろうか？
▲γ=1でマトリックスを開こうとして例外が発生した．
ゼロ除算が起きている．α mod Xで起きている．マトリックス先頭行の指数のインデックスを表示しようとするところだ．γが１ということはすべての値が割り切れるはずだから，すべての行が{0,0,0,0,…}のようになるはずであり，固定桁=0，周期1となるのが正しいように思われる．この場合，X=1でなくてはならないのではないだろうか？この値XはBuildmatrixで計算しているので，そちらを修正する必要があるが，暫定的に1を強制しておこう．⇒こんな図になった．
周期ゼロなのだから，横インデクスがすべてゼロというのは正しい．Zも１になっているが，これでよいのだろうか？Zは縞周期と呼ばれる横縞の幅でγ/０行数だが，いまの場合は0行数=γだから，Z=1でよいと思われる．いや，間違えた．それはYのことだ．Y=1はよいが，X＝０は間違っている．BuildMatrixではX値を計算していない．表示されている値を数値化しているだけだ．この値を計算しているのはDispModPowだ．この関数はLambdaFunctionの返す値を見ているだけなので，やはり，LambdaFunctionから修正する必要がある．
▲ValueChangedで例外が起きた．
DispParametorでエラーが起きている模様だ．DispModPowの中でΩがゼロになっている．今回の仕様変更によってすべての行はなんらかの周期列を持つことになったのでこの方式ではΩ数をカウントできなくなったが，ともかく例外が発生しないようにしておこう．
α=1，γ-2では問題なくマトリックスを開けた．X=1，Y=2，Z=1となっている．このｚは0でなくてはならないものと思われる．なぜなら，縦数列の異種文字数はすべて２で，周期１の単純な周期列になっているからだ．⇒LambdaFunctionを修正してR=0が検出されたとき，offset=i-1を返す用に修正した．
▲DispResidueCycleで固定桁数不一致が発生する．λ＜＞周期 不一致も起きている．⇒この不一致はPowerResidueFuncとLambdaFunctionの間で起きているので，PowerResidueFunc側にも対応修正を入れる必要がある．LambdaFunctionではoffset=1, λ=0となっているのに対し，PowerResidueFuncはdrop=1, period=0を返している．
▲DispInvertFuncで停止した．α=7, β=10, ε=4，γ=2．理由はR2 <> 0．R2はｎU mod β-1． PowerResidueFuncは逆数モード（Bブロック）でも使われているので，上の修正が影響している可能性はある．nU=40，β-1=9．⇒Bブロックについては後で確認することにする．
一応修正は一通り入ったはずだが，点検に入る前に異種文字数例外の濃色表示をモードに関わりなく出せるようにしておこう．⇒大体できた．とてもわかり易くなった．
X, Y, Zがマトリックスの形状を決定していることがよく分かる．Xは横周期，Yは縦周期，Zがオフセットだ．上の図ではX=2, Y=2, Z=2となっているが，横周期は２，ゼロ行の周期は２，左下の変則的な部位を示す濃色部は２桁になっている．これらの例外部位を除くと，異種文字数にも完全な周期性が確認できる．横数列の場合，最右列を見ると，{1,3,2,2,2,3.2,1}のようになっているが，固定部を例外として除くと，{1,1,2,1,2,1,2,1}であり，これは{1,1}{2,1}{2,1}{2,1}のように読み替えることもできる．縦数列の最下行を見ると｛5,2,5,2,…}で完全な反復になっている．まだ完全に解析できた訳ではないが，縦横数列の規則性がはっきり見えてきたのではないか？
▲どうも，このZという数は1, 2, 3などのごく小さい数しか現れてこないような気がする．本当にそうだろうか？だとすれば，この数はもっと注目されてよいような気がする．γが2^kの場合はZ=k-1になる．おそらくこれが最大値ではないかと思われる．どうもこの値はγに含まれる素因数2の個数-1であるような気がする．たとえば，γ=448=2^6×7なのでZ=5で間違いない．２以外の素因数は関係していないようだ．
ここまで来れば，縦数列をセグメントで色別表示することもできるだろう．現行のstripeカラー表示は存続させて，新たに処理を追加することにする．⇒数値をカラーコード化するのはかなり難しい．既存のstripeカラー表示では同様のことをやっているのだが，かなりインチキな代物で「数値のカラーコード化」とはかけ離れたものだ．
縦数列の解析は難しいが，以下のようなカラーリングが考えられる．
不十分なものではあるが，ある程度まで縦数列のパターンを可視化することは可能なのではないだろうか？
▲道具箱右下の(φ, @)の表示はあいまいだ．φの引数を明示すべき．なし，Bブロックにφ(α)とその約数リストを移動すれば，AブロックとBブロックの関係が見易くなるのではないか？Aブロックではα^ε%γ，Bブロックではβ^e%αの関係が見えてくる．⇒移動してみた．
やや唐突感はあるが，αとβの関係がγとαのような関係になっていることが見えるのではないだろうか？
▲γ=32のマトリックス：stripeカラーでほとんど同色になってしまう．現行方式ではある程度同色になるのは避けられないが（むしろそれによってパターンが見えてくる）一様に同じというのはおかしい．
「縦数列でも固定部を含むところは横数列のように濃色表示したい」という提案があるが，意味があるだろうか？縦数列では縦方向の固定桁というのは存在しないから，異種文字数と周期が不一致という状況はそもそも存在しない．しかし，異種文字数を見ると，冒頭の部分には明らかに変異があることが見て取れる．
上図で見ると，異種文字数に変異が出るのは０行で０が始まる位置までということが言えそうだ．固定部があっても０にならない場合というのはあり得ると考えられるが，offsetの最大値とすれば間違いはない．ここまでをイレギュラーな領域としてよいのではないかと思う．その後の異種文字数はX値の周期で巡回している．
BuildPowerGridで異種文字数をカウントしている．X値（横周期），Y値（縦周期）を計算するところでZ値として固定桁数の最大値を求めておけばよいのではないか？まず，これをやっておこう．
▲どうも，やはり，０は周期に入れなくてはならないようだ．０を固定部に組み込むと数字が合わなくなる．単数で連続するものは０の他にもいくらでもあるので，０だけ特別扱いにする理由がない．この修正は慎重にやらないと失敗する．明日の仕事に回した方がよいのではないか？
Tak Maki 氏のヒント（べき等という概念の導入）から全面書き直しということになった．要点を拾ってみよう．
γの素因数リストはValueChagedProで出すようにした．Xα，Xεもここで出すようにしておこう．Xα，XεはDispModPowで出しているので，γの素因数リストもここで出すのが適当かもしれない．Λの計算はどこでやればよいだろう？この計算はResidueFuncPro→ PowerResidueFuncで行うのが順当だが，いまのところPowerResidueFuncのロジックはいじりたくないので，別途新設する．効率的ではないが，ValueChagedProの中でLambdaFunctionを1～γまで呼び出すことで取得するようにした．一応問題なく動いているように思われる．
これで見ると，従来のλは廃止してもよいように思われる．あとは，XαとXεだけだ．いや，まだある．Ρが出力されていない．⇒λを廃止し，Λをλにリネーム，Ρはωにリネームした．まず，Χαを出してみよう．Xεはこれまで通り，ε mod φ(γ)なので修正するところはない．Χαを出すためにはまず，ωが必要だ．これはどうやって計算すればよいだろう？ゼロ行＝周期数列なしだから，λ=0を見ればよいのではないだろうか？⇒できたようだ．セグメント長が正確に計算されている．
実装に移る前にもう少し調べる必要がある．縦数列の周期は思ったより複雑だ．γ=15のとき，ω=15となり，ε=1, 3, 5, .. で一つ置きに尽数列になるが，それ以外では異種文字数は4と6が交互に発生している．このうち，4となるのはε=4, 8, 12, 16などでここでは[1,1,6,1,10,6,1]の回文が発生している．また，異種文字数=6の場合，{1,4,9,1,10,6,4}の回文になっている．明らかになんらかの規則性は認められるのだが…
γ=16ではω=2だが，異種文字数（以下Δとする）は先頭のオフセット部を除いて，2,9,3,9, の繰り返し（λ=4）になっていて，Δ=2の場合は，{0,1}の反復，Δ=9では{1,0,3,0,5,0,7,0,9,0,11,0,13,0,15,0}，Δ=3では{1,0,9,0,9,0,1,0}のような回文の反復になる．γ=7の場合は，Δ=7, 4, 3, 4, 7, 2,のようなλ=6の周期になっているが，Δ=7で{1,2,3,4,5,6,7}の尽数列，Δ=4では{1,4,2,2,4,1}という０で区切られた回文の繰り返し，Δ=3では{1,1,6,1,6,6}の繰り返しになっている．Δ=2では0で区切られた{1}の反復になっている．
ωという区切りは明瞭で意味があると思われるが，0行に挟まれた部分をセグメントと呼ぶのはよいとしても，それをアドレッシングの単位にするのはやや無理があるような気がする．むしろ，従来通り，Xα=α mod γとしておいた方が扱い易いような気がする．
▲λとωのラベルを入れ替えた．つまり，縦周期（ゼロ行間隔）がλ，横周期が（最長横周期）ωとなる．縦軸インデックスでは縦周期は無視され．つねにγ-1の剰余となるが，横周期はφ(γ)ではなく，より短いωのインデックスになるべきである．⇒もう一度変えてみよう．横周期をX，縦周期をYとする．ギリシャ文字で言うと，chiとupsilonだ．その上で，RαをYα，RεをXεとした．これなら読み間違えることはないだろう．
▲縦数列でも固定部を含むところは横数列のように濃色表示したい．このためには，どの桁に固定部が入っているかを見なくてはならない．結構手間が掛かりそうだ．固定桁の最大数が除外される部分ということになる．⇒現行では異種文字数の着色はcycle カラー表示の場合に限定されているが，オプションと無関係に表示すべきだろう．
まず，マニュアルを現状に合わせて修正しておこう．横数列の循環単位はφ(γ)，縦数列はγであるとする．Λは横数列の「短周期」に関係し，ゼロ行の周期は縦数列の「横縞幅」に関係する．γの因数分解と横縞幅を出力パネルにダンプするようにしておこう．Λもダンプしてみたい．
少し分かってきた．横数列が０になる場合の固定桁数が縦数列の周回数つまりΩ数だ．このような観点からすると（縦横の対称性から），横数列が０となる場合の最大桁数をΛとするのが適当であるように思われる．固定桁の後に周期数列が続く場合というのは存在するだろうか？
▲DispResidueCycleで固定桁数不一致が発生する．offset=1 <> drop=0 α＝1 γ=14 Λ=1．⇒前回修正でγ=1のときoffset=1で復帰するようにしているが，α=1と共有の出口なので誤動作している．α=1のときはoffset=0としなくてはならない．なぜか？α=1の場合，Rはつねに１でこの値は反復されるから周期数列{1}になる．これに対し，γ=1の場合は，つねに割り切れて，R＝０となり，これを反復するので{0}となるが，この0は0*で固定部に含まれるので，固定桁1が正しい．
▲DispResidueCycleでΛ周期不一致が発生する．i=2 γ=1 Λ=1 cycle=0 drop=1 stop=False．i=2となっているが，α=1，つまり，α=1, γ=1のケースだ．１÷１＝１…0 だから，{*0}であり，これはγ=1のケースに入るべきものだ．⇒LambdaFunctionを修正してエラーは発生しなくなったが，Λ値不定のはずが，１と表示されている．これはΛ_Nというテキストボックスだ．MakeRecurringDecimalの中で記入している．α=1のケースでは，phi_N.Text = “1”とΛ_N.Text = “1”を実行している．これはどちらも余分な操作のように思われる．⇒これで大体筋が通ったのではないかと思う．
ゼロ行数＝固定桁数ではないかという予想が出ているのだが，果たしてどうか？2023/06/25には，「固定桁がゼロでないことと異種文字数と桁数が一致しないことは同値だ」とある．また，固定桁数は位相のずれに関係する．ラムダ関数では固定桁数と周期を返すようになっている．
固定桁と周期がどちらもゼロでないという事例が出てきた．α＝15 γ=18 Λ=1．出してみよう．縦周期Ωは6だ．このサンプルの場合は，異種文字数不一致はゼロ行だけでなく，９行というのもある．α=3，15で起きている．９でも{9, 9, 9, …}という並びになるが，最初から９なので異種文字数不一致にはなっていない．
Tak Maki氏の用語を使って，同じ数の連続を idempotent と呼ぶとすれば，このサンプルでは４種のidempotentが発生している．１，９，10，０だ．これらもグレーに塗りつぶすということも考えられなくはないが，いまのところはゼロ行だけで十分だろう．却ってややこしくなる．課題は２つある．
ResidueFuncでもzeroとoneのチェックはやっていたような気がする．⇒DispResidueCycleでカウントしている．DispResidueCycleには，ResidueFuncProで計算した剰余の入った配列Rが渡されている．
Rαの表示を単純にα%γ=Rとするのではなく，α\γ=q…r とすればよいのではないか？つまり，(q, r)ないし q – r という対で位置を示すというアイディアだ．これならば Rを指定するのと実質同じであるし，stripeもごく短いもので済む．この方式なら，縦数列のすべての実相が解明されていない段階でも対応できるはずだ．また，逆にこのように表示することで見えてくるものもあるのではないだろうか？ただし，修正量はかなり大きなものになり，ほとんどのロジックが書き直しになるおそれもある．それでもやる価値はあるような気がする．しかし，その前にまず，ゼロ行がどこまで通用するかを確認しておく必要があるだろう．
作業に着手する前に，現行のコードの中でΛの文字を割り当てているところをすべて小文字のλに書き換えておくことにしよう．大文字のλはM(γ)全体で通用する値とし，λは#とλの中間の値という位置付けだ．このλはordとほぼ一致するのではないだろうか？⇒いや，それよりはずっと緩いものになるはずだ．ordの場合はγが素数であるか，ないしαとγが互いに素であることが要求されるが，Λの場合は，そうでないケースも含まれる，もっと一般的な場合に成立する関係だ．
ΛとΩはγに属するので，ResidueFuncで計算するしかないのではないか？ResidueFuncProは内部でPowerResidueFuncを呼び出している．この関数はべき剰余数列と循環小数の両側をカバーするものになっている．となると，ΛやΩをそこまで拡張するという話になるのだろうか？⇒おそらく，そこまで飛躍した話にはなｒないのではないかと思われるが，一応そのことは念頭に置いて取り掛かる必要がある．
▲マニュアルの記述と実際の動作が合わない．マニュアルでは，「列インデックスとは長さγ-1のべき剰余横数列内の相対位置を示す0～γ-2の整数」としているが，γ=15のとき，列インデックスは0～7までの値になっている．⇒εR値は ε Mod (φ) で計算されている．このφはφ(γ)だ．行の場合はγが除数になっている．つまり，タイルの横幅はγ-1ではなくφ(γ)だ．タイルという発想はマニュアルの中に初めて出てくる用語だが，この発想は2023/06/25のログに出てくる「小ブロック」というアイディアに近い．ただし，このときは最後まで追求せずに終わってしまっている．縦数列の周期と一致しないためだ．
▲cycle カラー表示の場合にも，ゼロ要素はグレー表示するというのでよいのではないか？このような表示に変えても横数列の周期性には影響しない．というか，現行ではcycleカラーではゼロ要素には色を与えていないように見える．⇒対処した．こうしておけば，縦数列がなぜストライプと呼ばれるかが伝わるかも知れない．
ゼロ行がどこで発生するのか？その機序を突き止める必要がある．γという周期のストライプが入るのは確かだが… γ=123では入らない．122でも同じ．121では周期11のストライプが入る．γ=120では30でストライプが入る．どういうルールになっているのか？いまいちつかめない．γの因数分解も表示しておいた方がよいかもしれない．⇒とりあえず，ダンプすることにしよう．γ=124のストライプは62だ．
▲γ=120，α=1，ε=4のとき，DispResidueCycleで固定桁数不一致が出た．offset=1 drop=0．表示ではoffset=0, #=1となっている．最上行は{1, 1, 1,…}だから，offset=0, #=1が正しい．このoffsetはラムダ関数が出しているものだ．γ=124, α=1でも出る．
▲α=154，ε=4，γ=113のとき，ResidueFuncProで停止した．num <> CType(value_α.Value, BigInteger) これは，αが処理中に書き換えられたことを意味する．
▲DispResidueCycleで固定桁数不一致が発生している．α=3, ε=4，γ=1のときに起きている．offset=0でdrop=1となっている．このoffset値はLambdaFunctionが返したものだ．LambdaFunctionまちがっていると考えるしかないだろう．いや，違う．べき乗剰余列は{0*}で固定桁1が正しいはずだ．drop=1は正しいのだから，間違っているのはLambdaFunctionの方だ．LambdaFunctionは冒頭でαないしγが1のときは復帰しているが，offsetの既定値が0になっているため，その値が返されている．既定値を１に変更しておこう．
▲マニュアルの記述と実際の動作が合わない．マニュアルでは，「列インデックスとは長さγ-1のべき剰余横数列内の相対位置を示す0～γ-2の整数」としているが，γ=15のとき，列インデックスは0～7までの値になっている．これはタイルの横幅が８であることを意味すると考えられる．αとγのGCM=3となっているので，おそらく元リックスを既約とするための操作によってそうなっている可能性があるが，この辺り精査する必要がある．φ(γ)=8なので，おそらくこの数字が適用されているのだろう．cycleカラー表示してみるとそのことがはっきり分かる．
この辺りの動作をマニュアルに反映する必要がある．この辺りの操作はまだきっちり定式化されていないのではないだろうか？アルゴリズム自体見直す必要があるかもしれない．
▲ラムダ関数にどういう表現を与えることができるか？を考える必要がある．⇒内部的にはすでに決着しているつもりなのだが… また，原始根の定義についても再確認しておいた方がよい．
▲カラー表示をstripeからcycleに戻すと，0の行の色が残ってしまう．なぜか？color offに切り替えれば元の表示に戻る．
喜内道具箱のマニュアルを書いているところだが，マトリックス操作でおかしな点が出てきた．α=775807，ε=17，γ=6117でBuild Matrixボタンを押したとき，Rα=5065，Rε=17となっているが，表示されたマトリックス（34×34）には行インデックスとして，2148～2181の区間しか表示されていない．RowTopは32733になっている．これは，おそらく配列サイズの上限に引っかかったためだろう．しかし，γ=6117なのだから，配列サイズは6116×6117であり，十分保持できるサイズであるように思われるのだが…
RowTopの値はBuildPowerGridではなく，BuildMatrixで決めている．⇒BuildMatrixで行っている調整はまったく不要だ．RowTopがとり得る値には上限はない．⇒修正した．
▲更新ボタンが押されたときの出力には基本パラメータ情報がすべて含まれるべきだ．
いよいよ，「久留島喜内の道具箱」公開の機は熟しつつあるが，マニュアルの方はさっぱり捗っていない．そろそろ散歩も始めなくてはならないのだが… あまり暑くならないうちに始めないとワゴンに乗り損なってしまう… 原始根の個数というのが出てきた．φ(γ-1)という数になっているようだ．原始根の列挙と並んで取り上げてもよいかもしれない．ともかく，レンジオーバーでBブロックが処理できない場合のエラーメッセージを出せるようにしておこう．エラーコードはInvertFuncで出している ERROR_POWERRESIDUEFUNC_OVERFLOWだ．
いや，メッセージはInvertFuncですでに出しているはずだ．いや，違う．このエラーを出しているのはPowerResidueFuncだ．出力パネルに残しているテキストの長さが短か過ぎる．⇒MaxOutput は現在 30000 に設定されている．十分な長さのように思われるのだが… ８万文字に増加させてようやく冒頭のエラーメッセージが見えるようになった．この小さいパネルにそんなに多くの文字が詰まっているようには見えないのだが，wordwrapオンにしても大したボリュームには感じられない．エラーで戻ったときの動作を一通りチェックしておこう．
完全とは言えないが一応整備されたことにしておこう．
▲α=9223372036854775807という設定でSeed Testを実行しようとして，エラーが発生した．どこでオーバーフローしているのかがはっきりしない．ループ変数 i が整数型のためと思われる．⇒BigIntegerに変更した．問題なく動作するようになった．⇒ResidueTestにも同様の問題があるので，修正しておいた．
▲上記設定でResidueTestを実行して例外が発生した．α値の上限_MAX_INT64を越えようとしたためだろう．⇒動作範囲を_MAX_INT64に限定するようにした．
▲BuildMatrixでオーバーフローが発生した．⇒RowTopに行先頭番号を入れようとしてオーバーフローしている．⇒MAXSQUARESIZEを超えないように調整した．
中止ボタンが押されたときにはメッセージを出すことにしてみよう．PowerResidueFuncのERROR_STOPBUTTON_PRESSEDに仕掛けてみたが効かない．⇒中止ボタンが押されたタイミングで出すことにする．
▲Matrix Test で何も出力されていない．⇒verboseで止めてあった．silentに切り替えたが，ダンプ量が多いので一部verboseに戻す．出力テキストは一定の文字数で折り返すようになっているので，WordWrapオフでも行数が増えてしまう．また格納文字数を増やすと出力が極端に遅くなるので，32767という現状のままとする．MaxOutText定数でこの設定の数字を超えても効果がない．BuildMatrix中の情報をダンプした方がよい．また，砂時計がテストの途中で落ちてしまう．