かなり完成度が高くなってきた

かなりできてきた.タブは機能別に2つある.①コラッツ木の生成では,部分木の根と,ノードの枝数,木の高さを指定してコラッツ部分木を生成し,接続リストを画面にダンプする.

image

②ノードの枝ポジションの取得には3つの機能がある.(1)コラッツ数列の取得,(2)ノード番号の取得,(3)簡略部分木の生成の3つだ.(1)コラッツ数列の取得では指定した奇数のコラッツ数列を生成する.各ノードには数列の軌道を示す枝番号が付されている.(2)ノード番号の取得では,部分木の根のノード番号とそこからの経路を示す枝番号のリストを入力して,その位置にあるノードの番号を取得する.(2)は(1)の逆演算になっている.(3)簡略部分木の生成では.(2)で入力された情報を使って幹と葉だけのスギナのような部分木を生成する.この部分木のノードは最大枝数で指定した数の枝を持っている.

image

「ノード数列から枝番号のコピーを指定」チェックボックスをオンにしておくと,(1)コラッツ数列の取得で表示された枝番号のリストが自動的に枝番号リスト入力ボックスにコピーされるので,(2)ノード番号の取得で枝番号リストを手入力する手間を省くことができる.「最大枝数」は変更可能で,(3)簡略部分木の生成で生成される部分木のノード枝数にはここで設定された値が使われるが,(1)と(2)の操作では処理された部分木上の実際の枝数によって自動的に上書きされる.

出力はすべて画面上に表示されるだけで,ファイルには保存されないが,「コラッツ木の生成」タブにある「ゼルコバの木ファイルフォーマットでエクスポート」チェックボックスをオンにしておくと,それぞれの操作で生成されたコラッツ木をゼルコバの木形式のCSVファイルに保存する.保存されるコラッツ木の形状はそれぞれの処理によって異なる.CSVファイルには4種があり,それぞれ固定のファイル名でデスクトップ上に生成される.

  1. コラッツ木の生成(CollatzTree.csv):指定されたノードを根とする指定された枝数と高さを持つコラッツ木
  2. コラッツ数列の取得(CollatzChain.csv):1を先頭ノードとし,指定されたノードを終端とする線形のコラッツ木(枝数1の鎖)
  3. ノード番号の取得(CollatzNumber.csv):指定されたノードを先頭ノードとし,枝番号リストで指定された経路の終端ノードを終端とする線形のコラッツ木(枝数1の鎖)
  4. 簡略部分木の生成(TrancatedTree.csv):3の線形コラッツ木の各ノードに指定された枝数の枝と葉を付け加えた木

まだ,バグは残っているかもしれないが,そろそろリリースしてもよいかもしれない.FBがEXEのアップロードを認めているかどうかが問題だ.当初はソースコードごと公開することを考えていたが,最高機密に相当するので今回は見送るつもりだ.(モヒティからも欲しいという要望は出ていないし…)

▲CollatzChain.csvをインポートしてエラーが発生する.内容はCollatzNumber.csvとまったく同じ.ただし,カード並びが一方が昇順,他方が降順という違いがある.読み込み後は正常に描画できる.エラーはTRIBEBOX::CheckAbsoluteGenerationで起きている.理由は系列優先ノードのbreakupがオフという理由にある.breakupという変数は「重婚クラスタ検定で除去された結婚枝の当事者ノード」というものだが,それと「系列優先ノードの絶対世代番号不一致」がどう関係するのか飲み込めない.この関数は「系列優先ノードの物理世代番号を基準に絶対世代番号を振り直す.系列優先借りノードがbreakupノード(重婚クラスタ検定でパージされた結婚当事者)の場合,そのノードが本人ノードであっても,絶対世代番号と異なる位置に配置される場合がある得る このような場合,「系列優先ノードの物理世代番号を基準にその系列に属するすべてのノードの絶対世代番号を振り直す.」のように説明されているが,このサンプルでそのようなことが起きるとは考えづらい.⇒「コラッツ対応版応急措置@20211223」で止めておくことにする.

▲リリース版を使って,コラッツ木生成で枝数3,樹高40を実行したところ,どこかでハングしてしまった.STOPボタンも効かない.⇒Gobutton_Clickでオーバーフローが発生してSTOP文が実行された後,制御を失っている.⇒例外をスローしてハンドラーで処理するようにした.

コラッツ木生成で枝数3では樹高17以上は処理できない.枝数2では26くらいまでだ.

▲EXEを走らせておいたところ,カウント4985でハングしている.1分30秒しか走っていない.枝数は2,樹高は26.画面の移動もできない.エクスポートはオンになっている.MAX樹高は27になっているので,割当分は完了しているようにも見える.オーバーフロー件数は0だ.開発環境では再現しない.リリース版を作り直して再試行してみたが,再現しない.

▲ごく一部しか処理されていないのに,樹高がどんどん上がってしまう.これはかなりおかしい.現行論理は積み上がったものを端から処理してゆくだけの単純なものだが,これだと偏った木になってしまうのだろうか?だとしたら,高さで打ち切るようにしなくてはならない.⇒樹高を求める計算が間違っているのではないだろうか?⇒樹高を求める計算は間違っていないし,ノードの総数を求める計算もあっている.変異が起きるのは,3の倍数が子孫を持たないためだ.3の倍数は表示されているノードの1/3に当たるが,その下流がすべてカットされるため,膨大な数のノードが余剰となり,それが溢れて木の高さを大きくしている.やはり,設定値で切断するようにした方がよい.これ↓が樹高5の正しいコラッツ正則木だ.

image

これを見ると,設定では三元木のところ,実際には二元木になっていることがわかる.また,3の倍数ノードをピンク(女子色)にしているので,3の倍数ノードが正確に全体の1/3であることも分かる.これが一番わかり易いのではないか?ただし,三元木がが完全に正則であると仮定したときのノード数364を大幅に下回る94ノードしか表示されていない.樹高5の二元木のノード数63に3の倍数ノードの個数31を加えると正確に実数の94という数字になる.まだレンジオーバーフローは発生していないが,レンジオーバーフローが発生するようになれば,設定値よりさらに少なくなることだろう.

レンジオーバーフローのカウントはレンジオーバーフローとなるノードの個数ではなく,レンジオーバーフローの発生回数であるので,この数を参照しても必ずしも総和と一致しない場合があるだろう.これは,一度レンジオーバーが発生すると,その後に続くノードも必ずレンジローバーになるので,そこで処理を打ち切っているためだ.枝数4,樹高4のサンプルを取ってみた.

image

4は3で割り切れないので,枝数3のノードと2のノードが入り混じった状態になっているが,女子ノードが全体の1/3になるという点に関しては間違いがない.これで大体まとまったのではないだろうか?あと残ったのは,この手続きが代数的に正しいことの証明だけだ.

コメントを残す

メールアドレスが公開されることはありません。

CAPTCHA