ゼルコバの木テント村

▲α=8, ε=2023, γ=54でマトリックスを表示しようとしてColoringStripeでエラーになった．

.Rows(topn).Cells(leftn).Style.BackColor = colでセルの背景色を設定しているところだ．topn=6, leftn=2006が入っている．maxrowsは34，maxcolumns=34だから，明らかにレンジを逸脱している．mat.ColumnTopの2006という数がそのまま適用されている．どこかで修正ミスを冒しているのではないか？おかしい．この論理は元々は .Rows(i).Cells(j).Style.BackColor = colのようになっていたはずだ．⇒確かにこれでエラーは発生しなくなったが，カラーリングがおかしい．

かなりややこしい．難しい論理になっている．一応動作するようになった．多分これで間違いないと思う．

さて，いよいよ最後の課題に掛かることにしよう．縦数列のセグメントを半分に折ってそれぞれを着色するという課題だ．これを行えば，異なる数列で和が一致してしまう場合を分離することができる．また，副次効果として回文の見える化にも寄与するはずだ．かなり面倒な仕掛けだが，やってできないというほどのものではない．また，やるだけの価値はあるものと思われる．現行のstripeカラーはそのまま温存したいので，このカラーリングは追加ということになるが，問題は管理パネル上の余白が乏しくなっていることだ．

このカラーリングをとりあえずsegmentカラーリングと呼んでおく．ボタンを止めて，リスト化するという方法も考えられる．というか，それしかないのではないか？ボタンの方が素早く切り替えらえられるという利点はあるが，この機能は必要に応じて使われるような種類のものなので，許されるのではないだろうか？リストは以下のような構成になる．

1. Color off
2. Color on
3. Color cycle
4. Color stripe
5. Color segment

最後のColor segmentというのが，これから実装しようとしているセグメントカラーリングだ．γの周期性に関わるパラメータX, Y, Zはこれまでchi, upsilon, zetaとしてきたが，間違い易い/書きづらいので，X, Y, Z　に統一することにする．Xの値はLambdaFunctionが返す周期#の最大値である．⇒カラリングの切り替えをラジオボタンからコンボボックスに変更した．それほど違和感は感じない．

セグメントを細分割する際の手掛かりとして，異種文字数１の行というのを考えてみたが，どうもうまく割り切れるようには見えないので，当初予定通り単純に２分割するという方向で進めることにする．手順は下記のようなものになる．

1. Yが奇数の場合は，最下行の０行を除外すると偶数になるので，２頭分して個別に色分けする
2. Yが偶数の場合は，最下行を含めてそのまま２分割して色分けするか，ないし最下行と中央の行を除外して残りを色分け表示する

γ=18の場合，Y=6で偶数だが，ほとんど同色で塗りつぶされている．なぜか？{1,4,9,16,7}=37，{1,8,9,10,17}=45，{1,16,9,4,13}=43，{1,14,9,16,11}=51でそれぞれ値は異なるのにほぼ同じ色に見えてしまう．⇒色々調整してみたがなかなかうまくゆかない．異種文字数がまったく異なるのに同じ色になってしまうというのは納得ゆかない．むしろ，異種文字数を基準にした方がよいのではないか？

異種文字数は列に属する値でセグメントと１対１対応していないが，異種文字数の４倍を加算することで分離できるようになった．母数を大きくしないでオーバーフローしたときは360の剰余を取るようにしてかなり解像度は高くなったのではないかと思われる．

いろいろ検討してみたが，セグメントカラーリングは取りやめることにする．ある程度色で識別できるようになったので，しばらくはこのまま運用してみることにする．あとはマニュアルを書くだけだ．

▲α=15, ε=4，γ=12のときの異種文字数がおかしい．上から見てくると，α=7で{7, 1, 7, 1,}が1となり，その次の{8, 4, 8, 4, }が3，{9, 9, 9, 9, }が2，{10, 4, 4, 4, }が1と軒並みおかしい．12行目では{0, 0, 0, 0, }で2となっている．異種文字数のカウントはBuildMatrix，それを読んでBuildPowerGridでマトリックスに表示しているはずだが，どちらが間違っているのだろう？

配列の内容はcharNVが{0, 12, 4, 9, 4, 0}，charNHが{0, 1, 3, 2, 1, 2, 2, 0}となっているので，配列の中身がそのまま表示されている．つまり，配列の内容が間違っている．ただし，charNV(1)=12はマトリックスでは9と表示されているので，食い違いがある．charNHとcharNVの値はGetCharNumHとGetCharNumVで取り出している．⇒原因はわかった．縦数列では横数列のように周期で区切ることができないという点が見落とされている．つまり，セグメントというのは単なる区切りであり，周期ではないということがよく理解されていない．言い換えると縦数列の検定では検定区間をγより短くはできない．別の言葉で言えば，縦周期Yが区間と誤認されている．

いまの場合はγ=12でY=6だが，縦周期Yで繰り返されるという仮定で動作している．これは誤りだ．

BuildMatrixとBuildPowerGridで区間γに対応するよう修正した．これで概ね異種文字数の表示は正しくなったように思われるが，まだ二三不審な点がある．γ=12のマトリックスで最下行の異種文字数のうち最左の９というのはおかしい．0～11までの数字が現れるのだから，１２でなくてはならない．また，１２行目と２４行目の最初の数字は0になっているにも関わらず，異種文字数は2となっている．

charNV(1)=12となっているのに，表示が９となっているのはなぜか？かなり微妙な問題だ．charNV配列の長さはX+Zで事例ではX=2, Z=1となっている．BuildPowerGridではこの標準配列を使ってテーブル上の任意の矩形領域を表示しようとしているため，列番号から標準配列のインデックスへの変換を行っているが，この論理の中に列番号がゼロになった場合はXに読み替えるという処理が入っている．この辺りで誤動作しているものと思われる．

マトリックス先頭列＋ｊの値がXより小さい場合は変換しないで直接適用するように書き換えておこう．⇒解決したようだ．事例ではγ=12となっているので，αが12の倍数であれば剰余は０でなくてはならないから，１２行目，２４行目の最左ノードが０であるというのは正しい．従って，異種文字数が２となっている方が間違っているように思われる．⇒上記と同様な仕組みになっている．行がγの倍数のときはYで置き換えるようになっている．Yでなくて，γでなくてはならない．

修正して動作するようになった．これで異種文字数に関しては整合するようになったのではないかと思う．upsilonつまりYを参照しているところはすべて点検しておく必要がある．⇒一応OKのようだ．

▲57428571880/142857143を計算しようとして，どこかでハングしてしまった．GetDivisorsで手間取っている．yakusu=288でO(288^2)だが…ラムダ関数が反復呼び出されているためだ．⇒DispModPowではi=1 to γ でラムダ関数を実行しているが，γ={142857143}なので，途方もない時間が掛かっている．ここでやっているのは，X, Y, Z値の計算だ．現在i={1683067}なのでまだまだ停止しそうもない．γが大きいときにはここはパスした方がよい．

MAXPOWERINDEX=65535 べき乗指数の上限を限界としておこう．⇒上限まではループを回すようにした．上限で打ち切られた場合には値は不正確なものになる可能性はあるが，出ないよりはましなのではないだろうか？⇒MAXPOWERINDEXでは大き過ぎる．MAXSQUARESIZE=32767まで落としてみた．上の事例ではXとZには値が入り，Yは空欄となった．⇒Yには0を出すようにした．⇒いや，Y=0というのはおかしい．不定という方がましだ．

MatrixにsumR, charNV, charNHという配列を設置して事前に異種文字数とセグメント和を格納しておくようにした．sumRは横周期X・セグメント数，charNVは横周期X，charNHは縦周期Yという大きさになっている．Xは横周期，Yは縦周期なのでこれ以上小さくはできないが，横周期の場合には固定部というのがあるので，もう少し広げておく必要がある．この値はzetaに入っている．

▲マトリックスに異種文字数が表示されない．⇒「異種文字数をカウント」をBuildMatrixに移しただけで，表示の方は手当てしていない．これから整備する必要がある．⇒従来論理を復活させたら，「色相の値が不正」というエラーになった．maxcol=153で, sumR=408, col={255, 255, 255, 255}になっている． maxcolは=γ * (γ +1) / 2で計算しているが，sumR<maxcolでなくてはならないはずだ． γ ^ 2 としておこう．いや，それでもまだ足りない．max=289に対しval=408だ．γ=17だから，24個以上加算されたことになる．

わかった．同じ位置にダブって書き込まれているのだろう．セグメント和を計算しているのはGetCharNumVだが，ここでは１～maxcolumsまでのすべての行が対象となっている．

▲α=8，γ1=1のとき，BuildMatrixでゼロ除算エラーが起きた．Y(upsilon)が不定になっている．⇒DispModPowでΩがゼロのときは，upsilon=γとした．γ値はゼロにはならないので安全だ．

▲ゼロ行の異種文字列がゼロとなっているが，これでよいのか？０は１桁の周期列とみなすということにしたはずなのだから，異種文字数１でなくてはならないのではないか？仮にゼロ行に関しては異種文字数０でよいとしても，γ=2のとき，縦数列で０と１が混在しているのにゼロになっているのは明らかに誤りだ．もし，０もカウントするとすれば，ここでは２になっていなくてはならない．

γ=3のとき，１列目は{1, 2, 0}で3となっている．２列目は{1, 1, 0}で０，以下同じで異種文字列の行は{3, 0, 3, 0, }のようになっている．γ=4のとき，3行目は{3, 1, 3, 1}で１，{1, 1, 1,,}でも１だ．γ=5では，{1, 1, 1, 1,}の列が0になっている．

まだいろいろあるが，かなり整って来たことは確かだ．ゼロ行の異種文字数がゼロという問題を片付けておこう．「異種文字数のカウントからあらかじめ固定部を除く」という提案があるのだが，これはどうか？横数列と縦数列で異種文字数の合計が一致するという予測がある．特に，番外の固定部の異種文字数合計は一致しなくてはならない．⇒ゼロ行の異種文字数は０でもよいような気はする．これはある種のセパレータになっているので，０が表示されていた方が区切りが見つけ易いのではないか？０は固定部にはカウントされないという規則はすでに確立している．異種文字からも除外するというのはそれほど変則ではないのではないか？むしろ，縦数列で{1, 1, 1, }が0となっている方が問題だ．ただし，縦数列ではどうも０をカウントに入れているようにも思われる．γ=17で異種文字数17という列があるのだから間違いない．

▲縦数列の異種文字数カウントでループが回っていない．yoko = X+Z = 16+0になっている．つまり，周期の境界線が外されている．⇒というか，Xの剰余がゼロになってしまう．Xの剰余ゼロのときはXを使うように調整した．これで縦数列で{1, 0, 1, 0,}の場合は異種文字数２ということになった．0をカウントしないとすれば，１になるが，話がややこしくなるので，シンプルに０もカウントするということに決定しよう．⇒横数列で0がカウントに入らないのも上と同じ理由だ．つまり，Yの剰余がゼロになっている．⇒調整を入れた．これで完全に整った．

「異種文字数のカウントからあらかじめ固定部を除く」という件に関しては取り敢えず保留とする．まだ，縦・横の異種文字数の関係が完全に解明されていないので，もう少し詳しいことがわかってからでも遅くはないだろう．これで縦数列のカラーリングはひとまず落着したことになるのだが，もう一つだけ懸案がある．数列の内容は異なるのに合計が一致してしまうという問題だ．たとえば，γ=7の場合，縦数列は{1, 1, 1, 1,}を除いて2色で塗り分けられているが，実際には４パターンあり，合計が一致しているために２種に縮退している．

{1+2+3+4+5+6}={1+1+6+1+6+6}＝２１，{1+4+2+2+4+1}={1+2+4+4+2+1}=１４．これを弁別するためにセグメントを半分に分割して着色するというアイディアがある．こうすると，①パターンの異なることが明白になる，②回文になっていることも色で推定できるようになる，という利点がある．もし，これを実装するとしたら，全セグメントカラーと半セグメントカラーのオプションを選択できるようにする必要があるだろう．ここまでできれば，とりあえず当初予定したレベルには達したと言えるのではないだろうか？かなり込み入った話にはなってくるが，やってみるだけの価値はあると思う．

この検定で興味深いところは，Yが偶数のとき，中央の境界線では異種文字数１になるのではないかと予測されているからである．異種文字数１という行の典型は０行と１行だが，それ以外の数字でも起きる場合があり，これは特異なパターンとして注目されてよい現象と思われるので，それを際立たせるという意味からも意義があるように思われる．ただし，Yが小さい場合には細分化されて細切れ様になってしまうため図柄的に分かり辛いもになってしまうというところもあるのだが…

▲どうもまだ異種文字数カウントにバグが残っているようだ．α=15, ε=4，γ=12のとき，α=7の横数列{7, 1, 7, 1,}が１,{8, 4, 8, 4,}が３，{9, 9, ..}が２など数字がまったく合っていない．固定部を持たない０行が２になっているところもある．

べき剰余数列に現れる０の扱い方が間違っていた．一度０が発生するその後は０が続くことになるので，当初は０という一字だけの最短の周期列とみなすという立場を取っていたのだが，どこで切り替わったのかよく覚えていないが，いつの間にか０は周期列に入れない，つまり，周期列を持たない固定部だけの数列ということになってしまった．しかし，一文字だけ連続するというのは０に限った話ではなく，マトリックスの一行目は必ず{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カラー表示では同様のことをやっているのだが，かなりインチキな代物で「数値のカラーコード化」とはかけ離れたものだ．

縦数列の解析は難しいが，以下のようなカラーリングが考えられる．

1. ０行と０行の中間にある縦数列をセグメントとする
2. 各セグメントのR値の和を求め，その値をカラーコード化してそのセグメントを塗りつぶす
3. 横方向の周期性は確立しているから，一般にこのカラーは（セグメント幅の）縦縞のパターンになる．
4. 縦方向に繰り返しがある場合には縦縞は複数段に続くことで反復していることが可視化される
5. 回文はこの方式では同一カラーに塗りつぶされるが，接続していることは把握可能だ
6. 一つのセグメントが回文化している場合にはこの方式では弁別できない

不十分なものではあるが，ある程度まで縦数列のパターンを可視化することは可能なのではないだろうか？

▲道具箱右下の(φ, @)の表示はあいまいだ．φの引数を明示すべき．なし，Bブロックにφ(α)とその約数リストを移動すれば，AブロックとBブロックの関係が見易くなるのではないか？Aブロックではα^ε%γ，Bブロックではβ^e%αの関係が見えてくる．⇒移動してみた．

やや唐突感はあるが，αとβの関係がγとαのような関係になっていることが見えるのではないだろうか？

▲γ=32のマトリックス：stripeカラーでほとんど同色になってしまう．現行方式ではある程度同色になるのは避けられないが（むしろそれによってパターンが見えてくる）一様に同じというのはおかしい．

「縦数列でも固定部を含むところは横数列のように濃色表示したい」という提案があるが，意味があるだろうか？縦数列では縦方向の固定桁というのは存在しないから，異種文字数と周期が不一致という状況はそもそも存在しない．しかし，異種文字数を見ると，冒頭の部分には明らかに変異があることが見て取れる．

上図で見ると，異種文字数に変異が出るのは０行で０が始まる位置までということが言えそうだ．固定部があっても０にならない場合というのはあり得ると考えられるが，offsetの最大値とすれば間違いはない．ここまでをイレギュラーな領域としてよいのではないかと思う．その後の異種文字数はX値の周期で巡回している．

BuildPowerGridで異種文字数をカウントしている．X値（横周期），Y値（縦周期）を計算するところでZ値として固定桁数の最大値を求めておけばよいのではないか？まず，これをやっておこう．

▲どうも，やはり，０は周期に入れなくてはならないようだ．０を固定部に組み込むと数字が合わなくなる．単数で連続するものは０の他にもいくらでもあるので，０だけ特別扱いにする理由がない．この修正は慎重にやらないと失敗する．明日の仕事に回した方がよいのではないか？