メモリを使い切るとハング状態になる

FFFFを16進表記で65535と変換したまではよいが,そこでハングしてしまった.何かまだバグが残っているのだろうか?⇒notationを書き直したときには,一文字入力するたびに,Nを再計算して更新するようになっている.しかし,FFFFまで入力するとその後はカーソルが画面内に入らなくなってしまう.なにかバックグラウンドで作動しているような感じだ.convertflagというのがある.ConvertClickとConvertNum2Stringで使われている.ConvertClickはNをB進表記に書き直す関数で,ValueChangedから呼び出されている.これは,B進表記を更新した際の文法エラーを訂正するためのものだ.ConvertNum2StringはDispInvertとMakeRecurringDecimalから呼び出され,BCD変換を実行してbcdNumberを返す関数だ.

非常に奇妙なのはFFFFの4文字が入ると制御が効かなくなるという点だ.カーソルを置いたままで連続入力すればFFFFFのように先に進むこともできる.FFFFでは966桁になるので,かなり長くはなっているが処理できないというレベルではない.bcdNumberは大域変数のバイト配列だが,生成時に長さを指定していないので,ReDimする必要がある.この操作はToBCDの中でやっている.

どうも,MSは大きな計算をやろうとすると,それを並列実行化しようとしているのではないだろうか?どうも何か余分なことをやろうとしているような気がするのだが…⇒リリース版をショートカットから実行した場合にはこのような現象は起きない.一応アプリとしては正常動作しているように思われるので,これでよいことにしておく.⇒いや,どうもまだおかしなところがある.他のことをやっていて,元の画面に戻ろうとしたら真っ白になっていた.しかし,これもちょっと放置しておいたら元に戻った.⇒78645を入力してリターンで砂時計になってしまった.それほど時間が掛かる処理とは思えないのだが…それも一応収まった.7864という十分小さな数でも砂時計になる.確かにInvertの計算はコストが掛かるものではあるが…8桁くらいは楽にこなせていたような気がするのだが…123→リターンで砂時計だ.5桁しかない.

メモリ使用量がほぼ満杯状態になっている.16GB搭載で15.7GBとほぼ使い切っている状態だ.確かに,このアプリでは大きな配列を常駐させているので,立ち上げただけでメモリを消費するというのはあり得る話かもしれない.VSを落としても,まだ13GB使っている.やはり,現行方式には少し無理があるようだ.どうも,配列はその都度取るしかないのではないか?大きな数を扱うときにはそれなりの時間が掛かるのはやむを得ないが,小さい数を扱うときでも砂時計では問題がある.

どうも,アプリとして実行するより,開発環境で走らせた方がまだ速いような気がする.1234567891の結果がまだ出て来ない.どうすればよいのか?結局,inverseは表示されなかった.多分これは打ち切りになったものと思われるが,桁数も0, 0のままになっているというのが解せない.処理中はテキストボックスに入力できないようにするというのも必要かもしれない.とりあえず,すべての配列をサイズ未指定として,使うときにRedimするように書き直してみよう.

カーソルをChangeCursorを使ってプッシュ・ポップするように変更した.これでカーソル形状が途中で戻ってしまうという不具合はほぼ根絶したのではないかと思う.1234567890では逆数の循環小数表示は出ないが,1234567891なら出る※.ただし,素数のカラー表示が出なくなってしまった.いや,処理完了しているのに制御が戻らない.メモリの使用量も上限に張り付いたままだ.おそらく,外部に置いてもあまり意味がないのだと思う.むしろローカルで処理終了でリリースするようにした方がよい.⇒※これは話が逆だ.1234567890では計算完了していてその結果が残っているというだけだ.

今度は,1234567890でも逆数表示できた.結局,メモリ不足が不良の原因だったと考えられる.アイドリング時のメモリ使用量は7.5GBだ.QTとbcdNumberは外部にある.関数間の受け渡しがあるためだ.この程度はまぁよいのではないだろうか?かなりリラックスした感じがする.1234567891は素数ではないのではないか?実際,1,3,3,3607,3803,のような素因数を持っている.かなりまずい.確かにこの数は素数だ.どこかで処理を壊してしまっているような気がする.軽くなったのはよいが,誤動作するようになってはお終いだ.

なぜ,こんなことになってしまったのだろう?FactoringSubでは正しい答えを出している.もう一度計算したら正しい値になった.これはどういうことだろう?かなりまずいような気がする.素数インジケータもオンになっている.しかし,処理完了しているのに,メモリが解放されていない.カーソルはデフォルトに戻っているが,テキストボックスには入らない.まだ処理が完了していないのだろうか?メモリ上限に達するといずれ動作不良が起こるのは避けられないような感じだ.カーソルもいつの間にかビームになってしまっている.

1234567891はまだ一度も最後まで計算完了したことはなかったのではないか?2023/04/22のログでは,素数であることは確認されているが,「れ以上続けても埒が明かないので,一度中断しておこう」で中断している.iの現在値は{44396982}でnは{1234567891}だから,やはり,状況は同じだ.素数であることと循環節の長さの関係は調べておく必要がある.MAXARRAYSIZEを当初より16進一桁分だけ落としてみた.メモリ使用量は上限の半分くらいから徐々に増加する傾向にある.これでパスできなければ,この数は越すに越されぬ関門,つまり処理能力の限界ということになる.

QTというのは,もっと小さいテーブルでよいのではないだろうか?QT(i)<nだが,QT(i)<Bでよいはずだ.だとすれば,BYTE配列でもよいのではないか?実際,それをコード化したものが循環節なのだから…

DispParametorでは,nが素数であるか否かをφ数がn-1であるか否かで判定しているが,これは誤っている.nが素数ならφ(n)=n-1となるが,その逆は必ずしも成立しない.いや,違うかな?「φ(n) = n − 1 if and only if n is prime」は成立している.Lehmerのトーシェント問題というのは,「合成数nでφ(n)がn-1を割るようなものは存在するか?」という問題だ.⇒φ→ψという方向を考えるしかなくなってきた.

コメントを残す

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

CAPTCHA