月: 2023年5月

べき剰余マトリックスで「冪剰余算の九九表」を出せるようになった．かなりおもしろくなってきた．この表には付加情報として，φやψ値，異種文字数，(n, k) などを出せるようにしたい．昨日のログではB進数表記は横数列にのみ関係するとしているが，ｋの剰余を取るということはｋ進数を考えることに相当するので，縦数列にも関わってくるのではないか？横数列はいわゆる剰余群に関連する．縦数列も同様の周期性を持っているが，この方面の周期性に関してはあまり言及されていないような気もする．横数列の一行は１個の剰余類に相当するが，縦数列をなんと呼べばよいのだろう？

冪剰余算の九九表はｋ－１ｘｋのサイズで十分と考えられるが，ｋが素数でない場合の状況をもう一度確認しておきたいので，２ｋｘ２ｋのテーブルを出せるようにしてみたい．これが動くようになったらネット上で公開することを考えてもよいのではないか？ロリポでは一応クラウドが使えるようになっているので，そこに置くのが順当だろう．（使い勝手はいまいちだが，使っているうちにある程度慣れるのではないか？）

いまのところ，べき剰余マトリックスの主機能はBuildMatrixで九九表を出力することだけなので（ある範囲の包括テストも実施できるようにはなっているが），既存の久留島喜内ツールにボタンを１個追加するだけでもよい．このボタンを押すと現在のｋ値に従った九九表を表示するというので十分だ．これは結局，現在デバッグコンソールに出している情報をすべてGUIで出力するようにするということに相当する．

①久留島喜内の道具箱，②べき剰余マトリックスという２つのプロジェクトを１本に統合するという方向に進もうと考えている．①は内部的には（A)循環小数の循環節周期，（B）べき乗剰余数列の周期性の２つのプロジェクトが合体したものだ．特に（B）べき剰余周期数列は②の横数列に対応するので，ほとんど同一視できるように思われる．従って，全体を内容に従って区分すると，（a）循環小数の周期，（b）べき乗剰余横数列，（c）べき乗剰余横数列の３つになると考えられる．

（a）とそれ以外を区分するもっとも大きな理由は（a）では進数表記が問題になるのに対し，（b）（c）にはそれが出てこないという点がある．結局，これらを結びつけているのは，ψ数なのではないだろうか？トーシェント関数φが関係していることは言うまでもないが…従って，このプロジェクトの主たる目的はこのψ数（剰余類群の位相）の特性を明らかにすることになるのではないだろうか？

いましばらくは２つの独立のアプリとして，マトリックスを使ってもう少し遊んだ方がよいような気もする．マトリックスのどこがどうべき乗剰余周期列に対応しているのかを見極めた方がよい．⇒grid.icoをアイコンに指定して，リリース版を起こし，タスクバーにピン留していつでも開けるようにした．このVBアプリでGridViewのテーブルを扱えるようにしてみよう．⇒大体動くようになったが，k=1000で例外が発生する．

列のFillWeightとは何だろう？⇒列の幅と見てよいのではないか？その合計が65535，つまり整数の範囲を超えられないということのようだ．⇒FillWeightには値が設定できるので，1を格納してやると65535まで列を拡張できる．ただし，Columns(j).FillWeight = 1のように初期化しただけでは効果がないので，ColumnAddedのイベントハンドラでセットするようにして問題は解決した．ただし，描画までに時間がかかり過ぎるので，実用範囲はかなり限られている．また，仮に65535までは描画できたとしても，我々が興味がある3, 5, 17の次に大きい完全回文数＝2^16+1=65537には届かない．

行ヘッダに数字を表示したいのだが，うまくゆかない．この値は.Rows(i).HeaderCell.Value = (i + 1).ToStringで設定できるはずなのだが，効果がない．RowPostPaintイベントのハンドラで描画するようにしてみたが，やはり出てこない．ただし，行ヘッダの部分にカーソルを置くとホバリング状態で表示される「ヒント」のようにその数字が出てくるようになったので，まぁよしとすることにする．⇒いや，これはRowPostPaintイベントで描画しなくても同じだ．

２５７ｘ２５６のテーブルを描画するのに７分以上掛かっている．この辺りが実用限界と思われるので，ｋがそれ以上の場合はパスすることにしておこう．⇒一応動くようになったが，出ている数字がおかしい．ｋ＝１０のサンプルだが，最右列に１０以上の数が現れている．

おかしい．再現しなくなってしまった．⇒大きいｋでテーブルを作った後にk=10に戻すと再現する．i 行 j 列のとき，0< i ≦ k-1，0< j ≦ k で j の方が 1 大きいところが，反対になっているのではないか？

どうも，プロジェクトを壊してしまったようだ．マシンが落ちていたので電源オンで再起動したのだが，「修復しますか？」を無視したところ「プロジェクトが見つかりません」になってしまった．昨日はかなり修正が入っているので，復元するのは大変だ．動くものとしては，昨日の始業時バックアップしかない．⇒昨日の修正は主にテスト時のダンプに関わるもので，論理的修正はほとんどなかったような気がする．おそらく，ほとんどそのまま使えるはずだ．修正が必要な箇所が見つかったら，その場で対応すればよい．

復元できた！久留島喜内とべき剰余マトリックスという２つのプロジェクトが進行しているが，これを一つに統合したい．特にべき剰余マトリックスとべき乗剰余周期列は共通部分が多いと思われるので一つに統合できると思う．①循環小数の周期数列と②べき乗剰余周期数列を対置する形に整えるのが分かり易いと思う．最初は，これら２つを完全分離して別々のタブで操作できるようにしてみたい．かなり大掛かりな工作になるが，どうやればよいだろう？別のフォームを作って，そこにパーツを個別に移動するというのが一番安全であるような気はするが，同じフォームにタブを載せてそれに移動するということは可能だろうか？

べき剰余マトリックスに関しては，GridViewを使ってテーブルを直接表示できるようにしたいのだが…GridViewを使うとすれば，それ自体を１個の独立したフォームとした方がよいのではないか？べき乗剰余周期数列ではB^K%Nという式が使われている．これに対し，剰余マトリックスはI^J%Kという構成だ．うまく（意味のある）すり合わせができるだろうか？Nというのは任意の整数でかなり大きな数になる．というか，巨大数を想定しているが，Kはたかだか整数範囲に収まることを予定している．最終的には巨大数を用いずにすべて剰余演算として整数範囲で計算が完結することが目標となるが，まだ，その段階にはほど遠い．

いや，ちょっと勘違いしていたかもしれない．B^K%Nというのは，画面上のN, B, Kという設定を転用してBが基数となるようにアレンジするためのボタンだ．小数の循環節はB進数表記を基準とする循環だが，マトリックスの周期には進数は関わりがない．PRP(Power Residue Period)には進数は関わりがないので，マトリックスと完全に同一平面にあると考えられる．２つのアプリを比較しながら，もう少し考えた方がよい．マトリックスというのは，いわば，小さな土俵であり，外部世界における計算をすべてこの小世界の枠内に収めることができるという原理だ．土俵というより，リング（環）と呼ぶ方がより適切かも知れない．