マニュアルを現状に合わせて修正しておこう

まず,マニュアルを現状に合わせて修正しておこう.横数列の循環単位はφ(γ),縦数列はγであるとする.Λは横数列の「短周期」に関係し,ゼロ行の周期は縦数列の「横縞幅」に関係する.γの因数分解と横縞幅を出力パネルにダンプするようにしておこう.Λもダンプしてみたい.

少し分かってきた.横数列が0になる場合の固定桁数が縦数列の周回数つまりΩ数だ.このような観点からすると(縦横の対称性から),横数列が0となる場合の最大桁数をΛとするのが適当であるように思われる.固定桁の後に周期数列が続く場合というのは存在するだろうか?

DispResidueCycleで固定桁数不一致が発生する.offset=1 <> drop=0 α=1 γ=14 Λ=1.⇒前回修正でγ=1のときoffset=1で復帰するようにしているが,α=1と共有の出口なので誤動作している.α=1のときはoffset=0としなくてはならない.なぜか?α=1の場合,Rはつねに1でこの値は反復されるから周期数列{1}になる.これに対し,γ=1の場合は,つねに割り切れて,R=0となり,これを反復するので{0}となるが,この0は0*で固定部に含まれるので,固定桁1が正しい.

DispResidueCycleでΛ周期不一致が発生する.i=2 γ=1 Λ=1 cycle=0 drop=1 stop=False.i=2となっているが,α=1,つまり,α=1, γ=1のケースだ.1÷1=1…0 だから,{*0}であり,これはγ=1のケースに入るべきものだ.⇒LambdaFunctionを修正してエラーは発生しなくなったが,Λ値不定のはずが,1と表示されている.これはΛ_Nというテキストボックスだ.MakeRecurringDecimalの中で記入している.α=1のケースでは,phi_N.Text = “1”とΛ_N.Text = “1”を実行している.これはどちらも余分な操作のように思われる.⇒これで大体筋が通ったのではないかと思う.

ゼロ行数=固定桁数ではないかという予想が出ているのだが,果たしてどうか?2023/06/25には,「固定桁がゼロでないことと異種文字数と桁数が一致しないことは同値だ」とある.また,固定桁数は位相のずれに関係する.ラムダ関数では固定桁数と周期を返すようになっている.

固定桁と周期がどちらもゼロでないという事例が出てきた.α=15 γ=18 Λ=1.出してみよう.縦周期Ωは6だ.このサンプルの場合は,異種文字数不一致はゼロ行だけでなく,9行というのもある.α=3,15で起きている.9でも{9, 9, 9, …}という並びになるが,最初から9なので異種文字数不一致にはなっていない.

Tak Maki氏の用語を使って,同じ数の連続を idempotent と呼ぶとすれば,このサンプルでは4種のidempotentが発生している.1,9,10,0だ.これらもグレーに塗りつぶすということも考えられなくはないが,いまのところはゼロ行だけで十分だろう.却ってややこしくなる.課題は2つある.

  1. ゼロ行をどうやって検出するか?ラムダ関数はoffsetを計算しているので,ここで検査できるのではないか?
  2. ラムダ関数はαとγを引数とする二項関数だが,γだけを引数とする単項関数に変換する必要がある.
  3. 現行ラムダ関数を温存し,αのすべての値についてこの関数を呼び出して,ΛとΩの最大値を探すしかないのではないか?

ResidueFuncでもzeroとoneのチェックはやっていたような気がする.⇒DispResidueCycleでカウントしている.DispResidueCycleには,ResidueFuncProで計算した剰余の入った配列Rが渡されている.

Rαの表示を単純にα%γ=Rとするのではなく,α\γ=q…r とすればよいのではないか?つまり,(q, r)ないし q – r という対で位置を示すというアイディアだ.これならば Rを指定するのと実質同じであるし,stripeもごく短いもので済む.この方式なら,縦数列のすべての実相が解明されていない段階でも対応できるはずだ.また,逆にこのように表示することで見えてくるものもあるのではないだろうか?ただし,修正量はかなり大きなものになり,ほとんどのロジックが書き直しになるおそれもある.それでもやる価値はあるような気がする.しかし,その前にまず,ゼロ行がどこまで通用するかを確認しておく必要があるだろう.

作業に着手する前に,現行のコードの中でΛの文字を割り当てているところをすべて小文字のλに書き換えておくことにしよう.大文字のλはM(γ)全体で通用する値とし,λは#とλの中間の値という位置付けだ.このλはordとほぼ一致するのではないだろうか?⇒いや,それよりはずっと緩いものになるはずだ.ordの場合はγが素数であるか,ないしαとγが互いに素であることが要求されるが,Λの場合は,そうでないケースも含まれる,もっと一般的な場合に成立する関係だ.

ΛとΩはγに属するので,ResidueFuncで計算するしかないのではないか?ResidueFuncProは内部でPowerResidueFuncを呼び出している.この関数はべき剰余数列と循環小数の両側をカバーするものになっている.となると,ΛやΩをそこまで拡張するという話になるのだろうか?⇒おそらく,そこまで飛躍した話にはなrないのではないかと思われるが,一応そのことは念頭に置いて取り掛かる必要がある.

マニュアルの記述と実際の動作が合わない

▲マニュアルの記述と実際の動作が合わない.マニュアルでは,「列インデックスとは長さγ-1のべき剰余横数列内の相対位置を示す0~γ-2の整数」としているが,γ=15のとき,列インデックスは0~7までの値になっている.⇒εR値は ε Mod (φ) で計算されている.このφはφ(γ)だ.行の場合はγが除数になっている.つまり,タイルの横幅はγ-1ではなくφ(γ)だ.タイルという発想はマニュアルの中に初めて出てくる用語だが,この発想は2023/06/25のログに出てくる「小ブロック」というアイディアに近い.ただし,このときは最後まで追求せずに終わってしまっている.縦数列の周期と一致しないためだ.

  1. 横周期はφ(γ)より小さい場合がある γ=200のときφ(γ)は80だが,最長周期は20のように見える 実際異種文字数は20を超えていない.
  2. 横周期はΛの最大値としてよいのではないか?この事例ではΛ={10, 20, 20, 2, 1, 1, 20, 20, 10, *}で,いずれも20の約数になっている
  3. 縦周期では0行というのが出てくるので,これを分割単位とするのが分かり易い.γ=200のとき,周期10でゼロ行が発生している
  4. 縦周期の場合の異種文字数は若い列では200という数字も出てくるが,周期に乗った時点では最大105, 25, 22などとなっている.
  5. ゼロ行が発生する周期は#が0,つまりΛが不定となるタイミングなので計算すれば取り出せるのではないか?
  6. ただし,横数列は完全な周期性があるが,縦数列ではそうではないので,インデックスとしてこの値を採用するのは問題がある.

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で固定桁数不一致

DispResidueCycleで固定桁数不一致が発生している.α=3, ε=4,γ=1のときに起きている.offset=0でdrop=1となっている.このoffset値はLambdaFunctionが返したものだ.LambdaFunctionまちがっていると考えるしかないだろう.いや,違う.べき乗剰余列は{0*}で固定桁1が正しいはずだ.drop=1は正しいのだから,間違っているのはLambdaFunctionの方だ.LambdaFunctionは冒頭でαないしγが1のときは復帰しているが,offsetの既定値が0になっているため,その値が返されている.既定値を1に変更しておこう.

▲マニュアルの記述と実際の動作が合わない.マニュアルでは,「列インデックスとは長さγ-1のべき剰余横数列内の相対位置を示す0~γ-2の整数」としているが,γ=15のとき,列インデックスは0~7までの値になっている.これはタイルの横幅が8であることを意味すると考えられる.αとγのGCM=3となっているので,おそらく元リックスを既約とするための操作によってそうなっている可能性があるが,この辺り精査する必要がある.φ(γ)=8なので,おそらくこの数字が適用されているのだろう.cycleカラー表示してみるとそのことがはっきり分かる.

この辺りの動作をマニュアルに反映する必要がある.この辺りの操作はまだきっちり定式化されていないのではないだろうか?アルゴリズム自体見直す必要があるかもしれない.

▲ラムダ関数にどういう表現を与えることができるか?を考える必要がある.⇒内部的にはすでに決着しているつもりなのだが… また,原始根の定義についても再確認しておいた方がよい.

▲カラー表示をstripeからcycleに戻すと,0の行の色が残ってしまう.なぜか?color offに切り替えれば元の表示に戻る.

RowTopがとり得る値には上限はない

喜内道具箱のマニュアルを書いているところだが,マトリックス操作でおかしな点が出てきた.α=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 に設定されている.十分な長さのように思われるのだが… 8万文字に増加させてようやく冒頭のエラーメッセージが見えるようになった.この小さいパネルにそんなに多くの文字が詰まっているようには見えないのだが,wordwrapオンにしても大したボリュームには感じられない.エラーで戻ったときの動作を一通りチェックしておこう.

  1. ERROR_STOPBUTTON_PRESSED 中止ボタンが押された PowerResidueFunc→
  2. ERROR_TOBCD_OVERFLOW ToBCDで配列サイズがMAXARRAYSIZEを超えた ToBCD→
  3. ERROR_MAKERECURSIONUNIT_ABORT 桁数オーバーでアボート MakeRecursionUnit→
  4. ERROR_MAKERESIDUCYCLE_OVERFLOW 桁数がMAXARRAYSIZEを超えた MakeResidueCycle→
  5. ERROR_POWERRESIDUEFUNC_OVERFLOW  除数Θ上限オーバー PowerResidueFunc→

完全とは言えないが一応整備されたことにしておこう.

α=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中の情報をダンプした方がよい.また,砂時計がテストの途中で落ちてしまう.

Bブロックが動作していない

Bブロックが動作していない.α=9223372036854775807のとき,β=10の10進数表記の数が,23になっている.かなりおかしい.ちなみにε=1.γ=23という設定だ.→数が大き過ぎて表示できないのではないだろうか?だとしたら,少なくとも「*****」のような表示にならないくてはならない.この値が入っているのはnotationだが,DispNotationでは直接この領域に書き込みを行っている.DispInvertFunc→ DispNotationが呼び出されていない.⇒InvertFuncが負値 ERROR_POWERRESIDUEFUNC_OVERFLOW を返している.

起動時にはウィンドウは一つだけ開くようになっていたはずだが… ボックスとパネルが開いている.⇒勘違いだったかもしれない.⇒タスクバーのアイコンから開くと2つ出る.⇒一旦ピン留めを外して再設定したら動作するようになった.原因は不明.

αが巨大数でもgcm(α, β)は計算できるはずだが,更新されていない.この値はgcm3だ.⇒DispInvertFuncで表示しているためだ.βの因数リストfactor_BもDispNotationで出しているので同じだ.⇒計算できるところはできるだけ表示するという対応の仕方も考えられるが,Bブロック全体が無効ということでよいのでは…

▲αに9223372036854775807を入力したあと,デクリメントして少し小さい数にしたらどこかでハングしてしまった.⇒一応計算完了して出てきた.Bブロックは更新できない.αを8桁まで落として数字が出るようになった.ただし,U, aU,Ξは不明のままだ.⇒出力パネルにはオーバーフローが発生していることを表示するべきだ.

喜内道具箱のマニュアルを書いている

喜内道具箱のマニュアルを書いているところだが,おかしな数字が出てきた.φ(γ)と#の最大公約数(φ(γ), #)の値がおかしい.φ(γ)=16で#=4なのに0になっている.かなりまずい.この値はgcm2に入っている.⇒更新ボタンで画面を更新したら4という値が入った.この値はResidueFuncProで計算し,その場で格納されている.この計算はPhi_γを参照しているので,Phi_γがまだ確定していなかったのではないか?⇒比較的最近,ValueChangedProでResidueFuncProとValueChangedの順序を入れ替えたのが敗因だ.⇒ResidueFuncProの前にValueChangedを実行するようにした.

大体仕上がったので,出荷の準備に入ろう

大体仕上がったので,出荷の準備に入ろう.以前一度VAIOにリリース版をインストールして試したことがあるが,今回は,サブノートに載せて動作確認することにしよう.EXEだけでは動かなかったような気がするので,実行するのに最低必要なファイルを確定しておく必がある.

BlackHawkにコピーして実行させようとしたが,EXEだけではまったく反応しない.binの下のnet5.0-windowsに入っているEXEを起動して以下のパネルが出た.

image

ともかく,.NET 5.0をインストールしておこう.これで一応実行できる環境にはなった.EXE+DLLで実行できるかどうか試してみたが,やはり無理なようだ.net5.0-windowsフォルダの中身がそっくり必要なようだ.配布版はパッケージにしてZIPで配布するしかない.配布パッケージ名はPowerGridということにしておこう.これは通常は「電力網」という意味で使われる用語だが,このツールの目玉はなんと言っても「べき剰余マトリックス」なので,適切な名前ではないかと思う.

どうもやはり,BlackHawkは足絡みになってしまうので,落としておくことにしよう.落としては見たものの日本語入力の具合がよくない.画面の左端に変換候補がちらちら現れて使い勝手がよくないだけでなく,反応が遅くていらついてしまう.平常通り,機内モードオン・VPNオンに戻して状態は戻ったが,変換候補が左に出るというのは変わらない.ただし,普通の速度でキーが打てるのでこの程度ならそれほど支障はない.どうも機内モードではファイル共有できないようなので,ファイルの受け渡しはUSBでやることにしよう.

起動時の初期画面でウィンドウが2つ開くというのはやはりノーマルではないので,パネルの方はアイコン化した状態で開くことにした.タスクバー上でホバリングすると「久留島喜内の置き土産」というアイコンが出てくるので,これをクリックするとパネルを開くことができる.タスクバーにピン留めしていなくても,タスクバー上に歯車アイコンが出ているときには,右クリックでアプリを開くことができる.

公開するとすれば,簡単な取説は必要だ.以前のCollatz Tree Generator のマニュアルにならって同系統のものを作ることにする.まず.最終版のCollatz Tree Generator の保管場所を確保しなくてはならない.コラッツではマニュアルは別フォルダで管理している.フォルダがここにあるということは,開発も開発機を使っていたものと思われるので,それも踏襲することにしよう.

マニュアルには図版が大量に入るので,やはり別建てで管理した方がよさそうだ.コラッツマニュアルにはPDF版とHTML版がある.PDF版の方が詳細なので多分こちらの方が新しいバージョンなのではないかと思う.多分最初はOpenOfficeのテキスト文書(*.ODT)として編集し,それをPDFとHTMLにエクスポートしたのではないかと思う.OpenOfficeにはHTML文書ドキュメントの編集機能はあるが,テキスト文書からHTMLにエクスポートする機能は見当たらない(PDFにはエクスポートできる).マスタードキュメントというファイル形式もあるようだが… 名前を付けて保存のところでHTMLが選択できる.従って,通常のODTファイルとして編集するというのでよいと思う.

今回のマニュアルは久留島喜内の仕事の継承という意味合いから日本語ドキュメントとして編集することにする.です/ます調(敬体)にするか,だ/である調(常体)にするかが問題だ.論文調ということであれば,だ/である調ということになるのだが… 導入部などではです/ます調,本文ではだ/である調ということでよいのではないか?いや,最初からである調でいくことにしよう.

開発機にはOpenOfficeはインストールされていない.ドキュメントのバックアップは外付けHDなので,多分VAIOで開発したのだろう.こうなると,やはり無線HDDが欲しくなる.と言っても,いまの環境ではいろいろ手間の掛かる部分もある.機内モードをオフにしなくてはならないとか… VPNもオフにする必要がある.⇒ファイル共有はできた.しばらくはこの態勢でやることにしよう.

これ以上付け加えるものはもうほとんどない

縦数列の周期は捉え難く,それをカラー表示することはかなり難しいので,その代用としてマトリックスのRの値を色コードに変換して直接表示してみることにしよう.⇒できた!

image

ごちゃごちゃし過ぎているが,こんなものだろう.R=0とR=1は特別扱いで黒と白で塗り分けている.これを小ブロックの境界を示す線で区切ることができれば,メッセージ性も多少は出てくるのだが…,ここから何かを読み取るのは難しい.色がどぎついので,透過色を使いたかったのだが,DataGridViewでは背景色を透過にすることはできないようだ.色のアルファ値を指定することまではできたが,描画されない.やむを得ず,色の明度を上げることでそれを代替することにした.

image

まぁ,こんなものではないだろうか?これならば,上よりはだいぶましと言えると思う.しかし,これでは何が何を意味するのかがまったくわからない.何か方法はあるだろうか?

ColoringStripeで算術演算オーバーフローが発生した.⇒コーディングにミスがあった.

こんなのはどうだろう?満開の桜というイメージで悪くないと思うのだが… ただし,意味不明という意味では同じだ…

image

この辺りが無難なところではないだろうか?

image

これだと,ある程度までパターンの形状が見えてくるので,周期性を考えるときの手掛かりにはなる.一応これで完成したということにしておこう.あと,やっておくとすれば,異種文字数と桁数が一致しない場合,識別できるようにしておくことぐらいだ.異種文字数=固定桁=桁数なので,固定桁がゼロでないことと異種文字数と桁数が一致しないことは同値だ.固定桁数が分かれば設定は難しくない.BuildPowerGridでは異種文字数はGetCharNumV,GetCharNumHで直接拾っている.BuildMatrixでは桁数の計算は一切行っていない.いや,ColoringCycleの中ではLambdaFunctionを呼び出している.色分けするのには周期が必要になるからだ.⇒横周期を出す時点で色で表示するようにした.

image

これで十分だと思う.異種文字数の縦と横の総和は表示されている範囲では一致しないので,表示していない.これを一致させるにはマトリックス全体の文字数をカウントしなくてはならない.さて,付け加えるものはもうほとんどなくなってきた.あと,何かあるだろうか?

さて,次は縦数列周期のカラー表示だ

さて,次は縦数列周期のカラー表示だ.方針としては,マトリックスを小ブロックに分割し,それぞれの矩形を塗り分けることで代用するというつもりだが,そのためには,ブロックの分割数,つまりサイズを決定しなくてはならない.⇒横数列周期カラー表示にブロック表示を上書きしてみた.イメージとしては,これに近いものになる.

縦数列周期カラー

このマトリックスはγ=200でα=100.横周期Λは不定だが,α=108のとき最大値20を取る.φ(γ)の値は80だが,小ブロックの周期はもっと小さい.明らかにブロックと認識される矩形サイズは10x10だ.この10という数字がどこから来るものかを知りたい.明らかに言えることは,この区切りは横に0が並んだ行であることだけは間違いない.従って,ゼロ行の発生機序が分かればおそらく小ブロックのサイズを確定できると思われる.これは多分それほど難しくないとは思われるが,試行錯誤なしで式から直接導出できるかどうかが問題だ.しかし,よく見ると,どうもこのパターンはかならずしも理論通りになっていないようにも見える.縦数列のブロックが個々に異なるのはよいのだが,横周期は少なくとも1つ置きには一致してほしい.⇒横周期のカラー表示がまだ収束していない可能性がある.もう一度確認する必要がある.

γ=200のマトリックスでα=94,ε=79 のとき,周期#は10で周期列は{94*,36*, 184, 96, 24, 56, 64, 16, 104, 176, 144, 136}のようになっている.つまり,先頭項は184だ.後半部はおおむね正しく表示されているように見えるが,横インデックスが64より前の部分ではカラー表示が崩れているように見える.どうも,まだ仕上がっていない気配だ.⇒まだいろいろあると思われるので,まず,ともかくマトリックスに異種文字数を出しておくことにしよう.これは,マトリックスに表示される値なので,BuildPowerGridで計算するというのでもよいのではないか?⇒この計算は確かTestMtrixでやっていたはずだ.

TestMatrixでやっているのは,基本的に異種文字数カウントだけだ.BuildPowerGridは独立に呼び出される可能性があるので,別物としておいた方がよい.TestMatrixではs1(), s2()という2つの配列に異種文字数カウントを入れて返している.とりあえず,BuildPowerGridの中からこの関数を呼び出してみよう.

TestMatrixを実行して,System.IndexOutOfRangeExceptionが発生した.work(MT(i, j)) = work(MT(i, j)) + 1でエラーが起きている.workのサイズはγだ.maxにはγ=200が入っている.⇒BuildMatrixにはモードがある.通常はノーマルモードで表示される範囲のマトリックスのためのテーブルを生成し,フルサイズモードの場合のみγ全体をカバーするテーブルを生成している.しかし,異種文字数をカウントするだけならフルサイズのテーブルがなくても間に合うはずなのだが…

つまり,一サイクル分を計算すれば十分なはずだ.ということは,TestMatrixの論理は大幅な書き換えが必要ということではないだろうか?横数列に関してはLambda関数で代用することはできる.縦数列の場合はそれに相当するものがない.GetResidueStripeという関数はある.この関数は文字列を返すようになっているが,改造して配列を返すようにすればよい.グリッドに表示されている範囲だけを計算し,その関数の中で異種文字数をカウントすればよいと思う.つまり,縦数列異種文字数カウント専用ルーチンということでよいのではないだろうか?横数列用も作ることにしよう.一応できたようだ.

image

ただし,BuildPowerGridでは,表示されている範囲の異種文字数しかカウントしていないので,横数列と縦数列で異種文字数の分布が一致するか否かの検定を行うことはできない.とりあえずは,これで十分だ.さて,もう一度マトリックスの不備の問題に立ち返ることにしよう.

どうも,行ヘッダに出す数宇を間違えてしまったようだ.ここにはやはりインデックスが出ていた方がよい.表面には出ていないが,通し番号は行ヘッダ部に表示されている.

横数列の異種文字数カウントには固定部文字数が入っている.このため,桁数ないしΛと一致しない.調整した方がよいのだろうか?調整した値を表示するとすれば,これは剰余数列の周期そのものになり,Λとも一致する.だとすれば,単純にΛ数ないし桁数を直接表示してしまった方が早い.⇒ここでは保留としておく.

α=94で周期の乱れが発生するのは,数列中に1が現れないためと見られる.このため.数列の末項が見つからず,おかしな形に繋がってしまっているものと思われる.⇒初項が検出された場合には必ずモードを切り替える用に修正した.⇒これで正しい表示になったものと思われる.プリントして小ブロックに区切ってみよう.

マトリックスγ200-α94

大体正しい図になったように思われるのだが,厄介な問題が一つある.周期は完全一致していると言ってよいように思われるが,位相に微妙なずれが発生する.これは,行によって固定桁が異なるためだ.従って,位相のずれは避けられないと思われるのだが,それが縦数列にどう影響するのかがまだよく分かっていない.⇒いや,均等にずれるのだから,その影響は無視できるのではないか?仕上がりは,下の図版から横数列のカラー表示を抜いたようなものになると考えられるのだが…

マトリックスγ200-α94-2

イメージとしては,概要,下図のようなものを想定しているのだが…

マトリックスγ200-α94W

この図版はγ=200を64x64で出力したものだが,縦数列の周期が10なので,200÷10=20のパターンが出現することになると考えられる.いまのところ縦数列に関して分かっていることは回文になる数列が存在するということくらいしかない.上のような色付けならある程度機械的に処理できると考えられるので,このくらいで手を打ちたいというのが本音のところだ.⇒同じ番号を同色で塗りつぶすという手も考えられる.この場合,横一列に0行と1行が並ぶので縦数列の特異性が多少なりとも見えてくるのではないだろうか?

これは試してみる価値のある実験であるとは思われる.固定部を切り捨てて,強制的に位相をそろえたらどういうことになるのだろう?それもまたおもしろい実験になりそうな気はするのだが…小ブロックのタイルを敷き詰めるというのは意味のある操作であるとは思われるが,背後になんらかのパターンがないと,ほとんど意味が通じない.意味もなくただ,ダンダラに塗り分けたようにしか見えない.