ゼルコバの木コラッツ特注版をASAP公開

ゼルコバの木コラッツ特注版をリリースするという方針を決定した.これは系図作成の原点に立ち還るということであり,知らず識らずのうちに大きく道を逸れていたことに気付くのがあまりに遅かったとは言え,まだ快復のすべは残っている.隣接リストとして与えられたコラッツ木データを例外処理としてではなく,基本処理として安定かつ高速に処理できるよう仕立て直さなくてはならない.その上でもう一度既存論理を見直して,どこでどう曲がってきたのかを洗い出す必要がある.

まずは,ともかくコラッツ中核木生成ツールとゼルコバの木が完全一体とは言わないまでも十分スムーズに連携できるようにするところから始めよう.すでにゼルコバの木では隣接リストをインポートして描画できるようになっている.これができるとコラッツ木生成ではあえてゼルコバの木一覧表形式でファイル出力する必要がなくなるので,仕様の簡素化という意味からも,ゼルコバの木CSV形式で出力というオプションは廃止すべきだろう.この修正が入れば,画面レイアウトは完全に固まったことになるので,いよいよ内部ロジックの修正に移ることができる.

▲コラッツ中核木のCSVをインポートしてCheckDispSizeで停止した.⇒これは「この図面はxx%以上には拡大できません」という警告を表示するためのものなので無視してよい.というか,それ以上に拡大した場合には生描画という方法があるはずなので,この警告自体表示しなくてもよいのではないか?また,描画用ビットマップサイズの制限がメモリ容量に関係するものであるとすれば,もう少し大きなビットマップを予約することも可能なのではないか?最終的にエラーが出た場合には,その旨表示して処理を中断すればよいのでは?

確かに生描画で描画は可能だが,画面の更新にかなりの時間を要するようになる.やはり,ビットマップの拡大を考えた方がよい.

▲インポート処理中はカーソルを砂時計表示する

▲64点のCollatzNumber.csvをインポートして,終端の65539でソートしようとして,GetGenerationエラーになる.

2^13の検証テスト結果をインポートして,最大カード数をオーバーする.⇒そのあと,ImportTabelFuncでインデックスが配列の境界外エラーが起きる.VerifyTest.csvのレコード数が15841になっている.レコード数をカウントして打ち切っているはずなのだが…それを変換したVerifyTest.ZEL.CSVでは17145点で却って増えている…ループが二重になっているため,脱出できていない.⇒対処した.

MDIParent.vbが読み取り専用で開かれている.なぜだろう?⇒エクスプローラ→フォルダのプロパティで読み取り専用を解除して使えるようになった…⇒デバッグ中は修正できないという意味では?

VeriflyTest.csvをインポートしてフェーズの遷移エラーが発生した.PHASEは9:DECOMPOSITIONで,modeは3:INITIALIZED.例外が発生している.-10001:メモリ不足だ.ヒープサイズはすでに1GB=1073741824バイトを予約してある.おかしい.ERR_NOMEMORYをスローしているすべての箇所にブレークを設定しているのに止まらない.fatalerrorにエラーコードを格納してからスローしているので見つからなかった.

TRIBEBOXオブジェクトを生成する段でメモリ不足が起きている.1064580バイトを請求しているが多過ぎるのではないか?TRIBELISTにリストノードとして追加しようとしているところだ.無数のTRIBEBOXを生成しようとしている.おそらくこれはカード数オーバーで処理を打ち切っているためだろう.このため親を失って孤児となったノードが無数に発生しているものと推定される.

それにしても,TRIBEBOX1個で1MBというのは大き過ぎる.⇒MAXIMALGRAPHを抱えているためだ.このオブジェクトはそれだけで1064120バイトある.これを系列枠ごとに持つ必要はあるのだろうか?MAXIMALGRAPHは大きい配列を2つ持っている.一つはSEGMENT配列,もう一つはMARGBOX配列だ.どちらもMAXPDB+MAXMDB+1のサイズを持っている.

対策を考える前に,エラーが発生したときの後処理を見ておこう.⇒「検定に失敗しました」のパネルが出るのはよいが,そのあと制御が戻ってこない.VBのInitializeDisplayではエラーを見ていない.いや,もちろん見ているが,そのあとOpenFileProcでCloseDataBaseを実行しようとして沼に嵌まり込んでいる.VBは致命的エラーのときは,FatalErrorを実行してアボートするようになっている.Z.mSendCardではメモリ不足時はそれを実行している.InitializeDisplayで「検定に失敗」したときには,FatalErrorでアボートするようにした.

▲Ancestry.zelでgetnodeegneのエラーが発生するので,SUPPORTSIMPLEGRAPHを完全に止めた.この結果(であるかどうかは確定できないが)topologicalSortの出口検査でInvestigateHSplitsのエラーが発生するので,これも一時停止した.

MAXIMALGRAPHをシステムに1個で動作可能かどうかを調べてみよう.⇒MAXIMALGRAPHは温存し,その中のSEGMENT[]とMARGBOX[]を外に出してみよう.⇒問題なく動作しているように思われる.⇒いや,結構問題がある.SEGMENT[]とMARGBOX[]はMAXIMALGRAPHのprivateメンバーとし,系列枠から直接アクセスできないようにした.

特に問題なのは,MAXIMALGRAPHで「近傍系列検定」というのをやっているという点だ.暫定的にこの処理は停止することにする.近傍系列検定というのは系列が他系列と接触しているか否かを問題にしているので,基本的にはスプリット検定などでカバーできるはずと思われるのだが…もし,それができないとしたら,なにかもう少しましな「広域検定」を編み出すしかないかもしれない.とりあえずのところは「大体動いている」というところだ.

GetAncestorsListで時間をバカ食いしている.先祖ノードが3480個もある.おそらくその大半は孤立ノードだろう.この敗因はおそらく,先祖テーブルに人名リンクではなく,参照番号を格納しているためだろう.このため,参照番号からカードを取り出すという余分なコストが掛かっているものと推定される.このテーブルに番号を格納しているのは,先祖並び替えのとき,アプリに引き渡す必要があるためと推定される.⇒いずれにせよ,これでは日が暮れてしまう.一旦打ち切ることにしよう.2^12に落としてみよう.⇒出た!

image

形状は前回表示した2^11と酷似している.前回はD=8, H=96,3236点だが,今回もD=8,H=96は変わらない.ノード数は3236から6510に増加している.点数が倍増しているのに形状がほとんど変化しないというのはフシギな感じがする.範囲を拡げたらどうなるのか,ぜひ見たいところだが,いまのところここまでが限界だ.表示までに191秒,約3分掛かっている.これににはCSVをインポートするまでの時間は含まれていないので,全体では5分近く掛かっているのではないだろうか?サンプルは確かにゼルコバの木的には巨大サンプルだが,ビッグデータと呼ぶほどのものではない.もう少し高速化の余地はあると思われるが,先にUI的な部分を手当しておくことにしよう.

主要機能5種に対し,CSVファイルは6本出力されている.これはコラッツ木生成では一般木と仮想木で異なるファイル名を使っているためだが,どちらかに統一した方がよい.とすれば,一般木と仮想木で同じファイル名を使うというのが妥当だろう.CSVファイルを出力したときには,メッセージパネルを表示するようにした.

コメントを残す

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

CAPTCHA