昨日から走らせている1281のInvertがまだ終わらない．ψ関数を書き換えて，対数を使って近似値を求め，厳密値を再計算して一致することを確認するという論理にして見たのだが，やけくそ時間が掛かるようになってしまった．この方式では b^x ≡ 1 mod n を与える最小の x を求めるのに，b^x=ny+1 の両辺の対数を取って，x=log(ny+1)/log(b) {y=1→b^n}を計算しているが，まだ，x=10のところを延々とやっている．これで見ると，既存方式の効率の良さが分かる．まぁ，これは見込みないので停止して次に進むことにしよう．⇒やはり，打ち切りボタンは必要だ．⇒元の論理を復活させたら，瞬時に処理完了した．
現行のpsi関数は対象数値が大きくなると時間を消費するものになる．主要な原因は剰余テーブルが大きくなってスキャンに時間が掛かるようになるためだ．Rの大きさはまちまちで順序不定のため頭から全数走査している．もう少し効率的な管理法はないものだろうか？一番簡単なのはハッシュを使うことではないか？ヒットしない場合には多少余分のコストは掛かるが，何もしないよりはましであるような気がする．いや，Rは重複のないユニークな数であるはずだし，R<Nなのだから，単純にT[R]=Rとしておけばよい．これなら相当早くなるはずだ．
いや，それだけでは不十分だ．ψ=i – j で計算されているが，このやり方ではjを決定できない．どこかにこの値を保持しておく必要がある．もう一つ配列を作るか，構造体を作って一緒に格納するか？⇒もうひとつ配列を作ることにした．⇒すでに書き込まれたRというのが出てきた．これはかなりおかしい．対象ｎは1281で出力ではpsi=60となっている．⇒このテーブルは生成時に初期化されていないのではないだろうか？いや，初期化しても同じだ．
計算は合っている．周期列の桁数は60でψは60になっている．同じRが現れているのにゲームオーバーにならないのはなぜだろう？これらは，冒頭のi=1, 2, 3 で書き込まれた分だ．FORループでは，x=x*bを実行して，bのべきを生成しているが，x≧nになるまでは除算は実行されない．XとRを交換した場合も同じだ．つまり，除算はつねにx≧nに達した時点で実行されるようになっている．多分論理的にはこれで正しいのだろう．問題は重複が発見されたときのインデックスを書き込むかどうか？という点だ．ψは最小である必要があり，そのためにはｉから減ずるｊは大きい方がよいので，多分書き込むというのでよいのだろう．
「すでに書き込まれたR」が発生するのは，つねにループの冒頭部分だ．これはこれでよいのではないかと思う．⇒修正で相当な効果があるかと思ったのだが，実質ほとんど変わらなかった．12813をテストして，どちらの方法でも約30秒くらい掛かる．テーブルのサイズは2134くらいなので，CPUパワーからすると問題にならないのかもしれない．もう一桁増やして128131を試してみたが，有意差は出なかった．どちらも1分５秒位掛かっている．numが128131に対し，i=3468なので，相対的にはやはりそれほどのものではないということだろうか？まぁ，処理の主要部分は除算なので影響は出ないのかも知れない．処理速度に大差がないとしたら，どちらの論理が優位というのも難しい．まぁ，走査しなくてよいという点では改訂版の方に多少分があるような気もするが…
▲どうも状態がかなりおかしくなっている．BigInteger.ToStringでおかしな動作が起きている．ゼロが書き込めなくなっていたが，それだけでなく，何も書けない（つねに２が出力される）ような状態になっている．応急措置として，VS2019の修復インストールを試みているところだが，訳が分からない．designerを直接いじるのはまずいということは知っているが，テキストボックスを削除したとき，名前が残っていて誤動作が起きるので削除操作している．しかし，それだけではこれほど具合が悪くならないと思うのだが… 単純ミスだった．すぐ後に置いたGCMの計算でテキストボックスに書き込みしていた．
入力ボックスでｎの値を変えると，自動的にφ，ψの値が更新されるようにしようと思ったのだが，少し無理がある．ｎの桁数が大きくなるとφないしψの計算に多大な時間が掛かるようになり，打ち切りボタンが必要になってくるので，やはり，スタートボタンは必要だ．せめて，φとψの並行計算というのは実施できないだろうか？FactoringSubでは素数判定にφ関数を使っているので，数が大きくなると動作が止まってしまう．