InvertFuncの中で直接循環周期列を生成するという方式変更をインプリメントしているところだが，どうも，かなり問題がありそうだ．既存コードと出力が一致しない．後ろの方が切れてしまっている．従来論理では周期列の２倍の長さのサンプルを用意してそこから切り出すようにしているが，改訂版では周期が判明した時点で処理を打ち切っているというところがまずいのだろうか？もし，そうであるとしたら，どこを修正すればよいのだろう？InvertFuncではQT()という配列に商を格納して返しているのだが，おそらく，冒頭でx≧nになるまで空回ししているところに問題があると思われるのだが，そこの論理は従来と同じなので，まず，従来論理との不一致が発生する理由から突き止める必要がある．
サンプル＝1234で10進数のとき，末尾の5008103727が不足している．10桁だ．従来論理にはzerosupという処理が入っいるが，結果として出力されている数列では冒頭部分はまったく同一だ．改訂版にはこの措置は入っていないのに同一文字列になるというのもよくわからない．⇒従来論理では1/nをbのべき乗倍して整数化しているが，数値をｎで割っても頭の方では商が立たないため，それを補うためのゼロ補正と考えられる．QTの中には冒頭のゼロも入っているため，同一結果になると考えられる．論理的にはこれでよいのではないだろうか？従って，問題は末尾に並ぶゼロの列ということになる．
やはり，問題はfixedではないだろうか？rcount=kであるということは，fixedの分は配列に格納されていないということになる．いや，rcountは上がっている．むしろ空回しのとき，fixedが上がってない方が問題なのではないだろうか？fixedはR=0のとき，x>=nの場合に限りインクリメントされている．いや，ちょっと違うかな？fixedの値は出口で決めているので，インクリメント操作は受けていない．k=i – IT(rindex)という値を返している．keta=fixed+kで，ketaが配列サイズに等しくなることを期待しているのだが…配列サイズはrcountだが，現在はこのテーブルはハッシュテーブルとして使っているので，必ずしも前詰めされていない．
InvertFuncは最近ハッシュ値を使うように仕様変更しているが，この修正に抜けがあるのではないか？rindexから後方しか探していないが，これでは全数検索したことにならないのでは？この修正は2023/04/17に入れているが，4月16日のコードと比較してみよう．いや，その下のループでそれはやっているようだ．同じコードがダブってしまうが，実害はないと思われるので修正を入れた．あとで整理することにする．
出力文字列が正しいことを検算する方法を考えなくてはならない．InvertFuncを用いずに直接検査することは可能だろうか？方法はあるだろう．文字列から整数を生成してしまうのが速いのではないか？いや，そんな簡単な話ではない．循環列は無限に反復する無限級数になっているので，そのΣを取らなくては元の数字にはならない．InvertFuncの動作（の模倣）ならあるいは可能かもしれない．つまり，ｎを頭から割り込んで剰余が一致するところが検出できたときの下図が一致すればよいのではないか？⇒検算は必要だが，ここでは保留しておこう．
テキストの長さと桁数では７の差がある．この７という数字は文字列に詰め込まれた記号で/B:0.&/の７文字だ．従って，桁数と配列長は一致している．問題はn=1234で10進数の場合，末尾の5008103727の10桁が欠損しているというところだ．これは結局，QTに書き漏らしがあることを意味する．MakeRecurringDecimalよりも前の問題だ．１から始めよう．現行論理では１は例外として扱うしかない．
φ，ψなどがすべて１になっている．これで正しいか？ここは後でチェックすることにして，２を見てみよう．従来論理では正しく0.5を表示しているが，改訂版では0.0で5が入ってこない．なぜか？xの初期値は1だが，x=x*bから始めるので，i=1でｘ=10，これを2で割って商が5というのはよいが，fixed=i=1で固定部が立ってしまう．