どうも完全に仕上がったのではないだろうか

一応循環単位数Uを表示できるようにはなっているが,まだだいぶ問題がありそうだ.というか,この過程で肝心の桁数の計算もおかしくなっている気配がある.総合的な点検が必要だ.

N=3,B=10のとき,Uが空になっている.固定部1循環部1という数字で,k循環節も/A:0.3&0/のようになっている.1/3=0.3333なのだから,/A:0.&3/でなくてはならないはずだ.str3の表示も0.3000…のようになっているので,間違いだ.つまり,固定部0,循環部1でなくてはならない.⇒とりあえず,強引に収めた.

N=7, B=10のとき,固定部5, 循環部6でUが700000となっている.これは明らかに間違いだ.1/7=0.1428571428571428…で循環節は142857でなくてはならない.つまり,固定部は0のはずだ.⇒IT(j)=0を見る,つまり,初項に一致した場合はfixed=0で抜けるようにした.

N=14, B=10でnUが9999990となるが,これはどういうことか?⇒循環節Uが714285となるのは正しい.714285✕14=9999990となるので,計算は合っている.N=15の場合も,U=6で6✕15=90となり,末尾に0が付いてくる.N=24の場合,U=6でRepunitは144となる.1/N=0.0416666666…なので固定部は.041の3桁,循環部は6で1桁となるから,U=6で正しい.従って,6✕24=144という計算は合っている.N=28のとき,U=571428となっている.これも数字は合っている.従って,571428✕28=15,999,984は正しい.

一見した限りでは正しく動作しているように思われる.B=10の場合には,①nUが99999…のようなレピュニット型になる場合,②99999…の末尾に0が付く場合,③それ以外の3パターンに区分できる.これらのパターンが発生する条件については,別途調べることにして先に進もう.

PowerResidueFuncで新旧不一致が発生している.N=7, B=10でValueChangedPro→ResidueFuncPro(n, K, False)を実行しているところだ.⇒明らかにこれは改訂版の方が間違っている.従来版では周期4だが,改訂版ではゼロになっている.⇒初項をRT(max)に格納するというのは余分だったようだ.この論理を外して動作するようになった.

どうも完全に仕上がったのではないだろうか?⇒MakeRecursionUnitというのはかなりコストの掛かる処理だ.Uが巨大数になってしまう.N=12345678のとき,桁数は335616もある.10進100桁でも十分大きいのでとんでもない数だ.⇒Nが10桁まではそこそこに出せるようになった.11桁ではさすがに時間が掛かる.現行ではMAXARRAYSIZE = &H7FFFFFFとしている.InvertFuncで処理する数の上限を決めた方がよい.⇒除数が10進で10桁を超える場合はエラーで戻るようにした.

これで12桁くらいまでは処理できるようになったが,FactoringSubで呼ばれるTotientFuncがネックになっている.この関数のアルゴリズムは十分効率的ではあるが,対象数が大きくなるとかなり厳しい.TotientFuncは素数判定のために使っているのだが,何かもっと効率的な方法はないものだろうか?⇒現状では12桁というのが限界のように思われる.過去(2023/04/28)には20桁のサンプルをテストしていたこともあるのだが…何が原因でこれほど重くなってしまったのか?⇒Bの大きさにも関係している.Bが素数である方が有利に作用する.

現在時間が掛かっている処理は,φの約数を取り出す処理なので上限を設けるか打ち切ってもよいのではないか?⇒あれこれやりくりしてかなり速くなった.こんなものではないだろうか?

コメントを残す

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

CAPTCHA