まだいろいろあるが,かなり整って来た

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だが,ここでは1~maxcolumsまでのすべての行が対象となっている.

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

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

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

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

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

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

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

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

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

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA