▲α^γ%Θ=Rで，マトリックス上の（αR行，γR列）の値がRと一致するはずだが，合わない．確かに．剰余計算は合っているが，γがΘを超えた後のγRの計算がおかしい．一つ多過ぎるのか，小さ過ぎるのか？Θが8のとき，γR=1でR=1となり，すでに合っていない．γ=7=Θ-1までは合っている．⇒どうも，かなりまずいことになってきた．完全な設計ミスだ．γRという値はまったく当てにならない．ということは，stripeの表示も間違っているということだろうか？⇒確かに間違っている．stripeはPsiFunctionでやっているように単独列として独自計算して出せば正しい数列になるとは思われるが，それとテーブルを対照させる「インデックス」はどう計算すればよいのだろう？
Θが素数の場合は，明らかにΘ-1という周期が横数列で発生する．従って，今の計算方式でも通用する．それ以外の場合にはまったく不明とするしかないのではないか？ということは，いま生成しているマトリックスも素数以外の場合には間違ったパターンが出力されているということになる．かなり困ったことになった．どうすればよいのだろう？BuildMatrixで表示されるテーブルそのものは多分間違ってはいないと思われる．問題はそれにどうアクセスするか？ということだ．つまり，テーブルの列インデックスをどのような形式で与えるか？行インデックスは現行通り，αRが適用できるはずだ．
- 行インデックス，cycleに関しては現行通り
- stripeは独自計算ルーチンを導入する
- 列インデックス，つまりγRは参考値とし，Θが素数でない場合には薄墨表示とする．
とりあえず，この３点で修正を入れてみよう．⇒GetResidueStripeという関数を新設した．ところが，すでに既設のMakeStripePatternという関数があった．ただし，この関数ではべき％(K-1)という計算を事前に実行している．明らかにこれは誤りだ．対処した．一応これで解決したことにしておこう．BuildMatrixのテーブルはつねにΘｘΘで生成されているので問題ないだろう．いや，それが誤りではないか？テーブルは指定サイズで生成されている．テーブルの左上セルはつねに(1,1)になっている．マトリックスではこれをシフトして使っているのではないか？確かにそのようだ．
▲α=123472，γ=2，Θ=38, β=20のとき，Ξは一見レピュニットになっているように見えるが，インジケータは立っていない．なぜか？⇒テキストボックスには1000文字までの1が入っている．
行をインデックス化する方法が一つある．すべての行の周期の公倍数を求め，その剰余を取れば正しい列が指定できる．ただし，このインデックスは各行の固定部より上でなくては適用できない．ともかく，テーブルに周期＝異種文字列数を出しておく必要がある．⇒CycleとDropという配列は存在する．これらの値はPowerResidueFuncで計算されたものをResidueFuncProで格納している．ValueChangedPro，TestMatrixとdivisor.ValueChangedでこれらの配列を初期化している．PsiFunctionではこの配列を参照してψ値を決定している．GetResiduCycleでもこの配列を初期化している．この２つの使い方はまったく違うので混同するのはよくない．ともかく，この値をDumpMatrixで出力してみよう．
▲MatrixTestを実行してどこかで例外が発生した．⇒DumpMatrix内だ．⇒配列の範囲外にアクセスしていた．
重要なことを発見した．剰余数列の周期を決めているのはφ(α)ではなく，φ(Θ)だ．φ(Θ)を取れば，素数でない場合もドンピシャで値が確定する．言い換えれば，φ(Θ)は剰余数列周期の公倍数である．別の言葉で言えば，＃ないしψ値はφ(Θ)の約数である．⇒実装してみたが，まったく問題なく動作している．EFAはこのことにまったく触れていないので，おそらく気付いていなかったのだろう．乗法剰余群の位数として知られる値がφ(Θ)の約数であることに触れた記事は読んだ記憶がない．
φ(Θ)が剰余数列周期の公倍数であるとすればγRはその剰余になるはずだから，Θが素数であるとかないとかの留保なしにインデックスを決定できるようになると思う．やってみよう．⇒完全に一致している．これでべき剰余数列の周期は完全に押さえられたと思う．⇒いや，まだ完結していないようだ．α＝123458，γ=30，Θ=8のとき，φ(Θ)＝４でγR＝２だが，stripeがマトリックスと一致しない．Cycle={1,0,2,0,2,0,2,0,}でこれらの項の公倍数は2だから，φ(Θ)＝４はその公倍数と言える．
不一致が発生する理由は固定部の存在であると思われる．この固定部の部分を除外すれば，完全にφ(Θ)の周期に乗るのではないか？いや，どこから初めてもそれほど違わないような気もするが…Drop={0,3,0,2,0,3,0,0,}なので，最小限３のオフセットが必要になるのではないか？どういう計算をしても γ mode φ(Θ)は2にしかならないが，インデックス2の縦数列に入っている値は固定部に含まれるため，その後は発生しなくなる数列であるので，不一致が生じると考えられる．Θの２倍のマトリックスを表示してその右半分にアクセスするようなインデックスを出力すれば安全だが，それもやり過ぎのような気がする．
一番安全なのは，γR+φ(Θ)を表示することではないだろうか？つまり，γR={γR mod φ(Θ)}+φ(Θ)ということになる．従って，マトリックスの全容を見たいのであれば，Θ＋φ(Θ)のマトリックスを拡げる必要があるということになるだろう．これでよいのではないかと思う．φ(Θ)＝Θ-1の場合には加算しなくてもそのままの値が使えるはずだが… このためには，φ(Θ)=Θ-1であることと，dropが存在しないことが同値であることを証明する必要がある．また，dropが発生する場合，その値はφ(Θ)を超えないことも証明されなくてはならない．ともあれ，これで一件落着なのではないかと思う．#=ψの等式も#=0の場合を除いて，完全に一致するようになった．これも#=0のときのψ値を０と定義すればよいというだけの話なので，ψ値はつねに決定可能ということになる．
α，Θ，Rの値が与えられたとき，γ値を逆算できるだろうか？もし，これができれば離散対数問題と呼ばれる課題を解いたことになる．原理的にはそれほど難しい話ではない．αとΘからαRが決まるので，αRのcycleを生成し，その中でRを検索すればよいというだけの話だ．cycleのサイズはたかだか，φ(Θ)ｘ２あればよいと考えられる．離散対数問題の対象はおそらく巡回群に限定されていたと思うので，固定部のことは考慮しなくてもよいとすれば，φ(Θ)で済む可能性もある．
ΘはInt64と定義されているので10進で1９桁を超えることはできないが，その範囲なら何とか計算できるのではないかと思う．
▲Θに16桁の数字を与えてエラーになった．
Θ=1234567890123456，α=123500, γ=33で起きた．エラーはGetResiduCycleで起きているようだ．