開発機で走らせている検証テストは現在17%で2日＋16時間，予備機は4.7%で20時間半経過している．まぁ，やらせておくしかない．ヤシの木型の直系図を出力するTruncated tree用の図版を作りたいのだが，問題が発生している．①Truncated treeでエクスポートしているゼルコバの木形式CSVの出力が間違っている，②ゼルコバの木の血統軸線図が動作していない．とりあえず，場所決めのための仮の画像を貼り込んであるので，プログラムの修正は後回しにして，先に進むことにしよう．
▲残り時間を表示できるようにしたい．このためには，コラッツ正則木の正味ノード数を事前に計算する必要がある．この計算式はモヒティに頼んであるものだが，当てにならないので，自分でやるしかない．残り時間が表示できると任意サイズの正則木を指定してそれがどのくらい巨大なものになるかを事前に推定することができるようになる．これは結構おもしろいのではないかと思う．現行では枝数と樹高にはInt16の制限があるが，その範囲でも相当大きな数字になるはずだ．しかし，問題は画面がすでにかなり混み合っていて新たな要素を追加する余地がないという点だ．この修正が入るとマニュアルも更新しなくてはならない．
LibreOfficeからPDFにエクスポートした出力のできが思ったよりずっとよいので，作業が楽しいものになってきた．最終的な論文はPDF形式になるので，これができるというのはとても頼もしい．これなら，いくらでも書けるという感じになってきた．HTML出力を調整するために，いろいろな小細工をしなくて済むというのが一番うれしい．
おかしい．開いているマニュアルのODTファイルが古くなっている．この画面上で修正して閉じていないはずなのだが…⇒ブラウザで開いているPDFファイルは修正後のものだ．LibreOffice上でPDFファイルを直接編集していたのだろうか？確かにそういうことのようだ．これは同期を取っておかないとかなりまずいことになる．考えられるのは，LibreWriterの編集対象ファイルがPDFをエクスポートした時点でPDFに変わってしまっているという可能性だ．これはエクスポートの趣旨からしてかなりおかしな動作だが…
Truncated treeに貼り込んだ画像もPDFにしか入っていない．つまり，ODTファイルのつもりが，PDFファイルを編集していたということのようだ．ODTの更新日時は2022/01/20 22:33でPDFの方は2022/01/21 10:08だ．PDFファイルとODTファイルで画面出力に異同がないのなら，PDFを直接編集するというのでも特に問題はないように思われる．それができるのなら，それでよいのではないか？PDFをダブルクリックするとエッジが立ち上がってくるというのもあまり，うれしくない．エッジではボックスの中の番号で検索ができない．それができるのはAcrobat Readerだけだ．
フロントエンド機にはAcrobat Readerがまだインストールされていない．ダウンロードを始めたが，povo1.0の20GBをすでに使い切っているのでかなり遅い．220円を投下すれば，丸一日快速で使えるのだが，ついこの間それもやってしまった．ちょこちょこ使っているとチリも積もれば山となってしまうが，10万円のコロナ支援金を当てにして，投下することにしよう．300MBくらいなので，通常の速度が出ればあっという間に終わる．それにしても，相当冷え込んできている．-5℃まで下がる予定だという．灯油もあと一缶しかない．3缶で一冬過ごすつもりだったが，到底間に合わない…
インストールは完了したが，Cドライブの容量が逼迫している．⇒いや，完了していない．「失敗しました」と表示されている．一時ファイルを削除して1.18GBの空き領域を確保した．もう一度やってみよう．⇒また失敗だ．今度はクロームでやってみよう．⇒同じだ．デスクトップ上のファイルをすべてSDに移動したが，ほとんど変わらない．ほとんどこれ以上どうしようもないという状況だ．Libreの作業は開発機に移してもよいのではないか？開発機上でブラウザを開いてチェックでもよいような気はする．サブノートはメールの受信とネットアクセスに限定した方がよい．Libreは開発機にもインストールしてある．⇒ノートを再起動してインストールに成功した．
Acrobat Readerのインストールには2GBのメモリが必要とあるが，搭載RAM 4GBのうち，3.9GBくらいまで使用状態になっていた．再起動して，これが約2.0GBまで減少した．2GBには少し不足していたはずだが，何とかインストールできた．まぁ，これでしばらく使ってみることにしよう．Acrobat ReaderをPDFのデフォルトアプリに設定した．Cドライブの現在の空き容量は1.26GB．メモリは1.8GB使用可能となっている．ゼルコバの木で出力したPDFファイルを開いて，ボックス内の番号を選択し，コピー・ペーストできるが，不完全な動作だ．365589という数をコピーしても，トレーには6558しか入っていない．つまり，先頭と末尾の数字が消えてしまう．残念だ．それでも，番号で検索できるのはいまのところAcrobat Readerしかない．それ以外のソフトは数字1文字の検索しかできないという貧弱な仕上がりになっている．
最新のマニュアル原稿はPDFになってしまっているが，これをODTファイルに戻すことができない．ODGファイルに変換することはできる．ODGというのはLibreDrawのファイルで，画像ファイルだ．これも少し具合が悪いような気がする．LibreWriterにもページという概念はあるが，テキスト全体は1個の流動体として扱われている．PDFやODGでは1行分の画像オブジェクトとしてしか扱われていない．これではどうにもならない．ということはODTとして編集した最終ファイルからもう一度やり直すしかないということになる．それしかないのだから，やるしかないだろう．修正の入っている箇所を総点検しながら，復元しなくてはならない．修正箇所は相当あるのではないかと思う．⇒終わった．
「枝番号数列」というのはこの検定では特に重要な概念だが，Truncated treeの出力を見ると，この概念を把握し易いのではないかと思う．その意味では，刈り込み木（血統軸線図）を描画できるようにしておきたい．ちょっと横道に逸れるが片付けておくことにする．まず，最初にCollatz Tree Generatorの方を修正しなくてはならない．この際なので，頻発するエラーだけでも止めておくことにしよう．
▲コラッツ正則木で出力したCollatzTree.csvをインポートしようとして，TREEVIEW:sendUpdateDataエラーが出る．送付されたテキストの中身が空というか，タブ文字が並んでいるだけだ．いや，そもそもCollatzTree.csvの中身が悪い．以下のような行が並んでいるだけだ．
System.Windows.Forms.TextBox, Text:
どうしたのだろう？これ以外の3機能ではCSVファイフは出力もされない．かなりおかしなことになっている…コラッツ正則木では書き込みは実行されているが，Branchlistは空だ．どうも訳が分からない．D=3, H=2でテストすると有効ノードは10個で，書き出された行も10だが，バッファは空なのに余分な行が書き込まれている．そもそもBranchListというのはタブBにあるテキストボックスだ．それをタブAで使っているということ自体誤りではないか？確か前にBranchListを廃止するという修正をやった記憶がある…原因はわかった．元々はBranchListという名前のStringが存在しているのだが，それを捨ててしまったため，直接タブBのBranchListを参照しているのだ．⇒対処した．危ないところだった…
Verifyでも系図データを出力できるようにすると，かなりおもしろいのだが…ちょっと厄介なところもあるので，ここではパスしておこう．将来プレーンな隣接リストから直接系図が出せるようになれば，対応できる可能性はある．GetTheSequenceではフラグ操作を誤っている．つまり，Export plain CSV fileが完全に無視されている．⇒いや，これが仕様なのではないか？Export Zelkova Tree CSVはB面でも有効だが，B面ではプレーンなCSV出力は想定されていないのではないか？いや，コード的には処理は入っている．考えていないとすれば，Verifyで動作することは想定されていないように思われる．
Verify中は無動作になるように修正したが，まだおかしい．CollatzChain.csvにゼルコバフォーマットで出力されている．いや，この関数ExportCsvRecordはゼルコバの木専用だ．ExportZelkovaCsvにリネームしておいた．B面の出力がファイルに保存されないのは，B面では出力を切り詰めるということをしていないためだろう．つまり，画面からコポー・ペーストができるという考え方だ．それでよいのではないかと思う．⇒ゼルコバ形式CSVを調べることにしよう．
CollatzChain.csvを読み込んで，上記TREEVIEW:sendUpdateDataエラーが発生する．CollatzChain.csvの内容は一見したところ正しいように見える．いや，少なくともヘッダ行が欠けているようだ．⇒やり直ししたところ，ヘッダ部も入るようになったが，エラーが発生する．CheckCommitChargeでエラーが起きている．メモリの残量率が0.0640047938で，0.1を切った場合にこのエラーが発生する．メモリは16GBで有効メモリ15.7GBのうち，12.0GBが使用中だ…
コミットチャージ制限値： 11104653
コミットチャージ合計値： 10393902
コミットチャージ残量： 710751
コミットチャージ残量/制限値：60281294899240142671331170620038688586028416878923926284474911346922653283646557054320683106761178397802496.000000
最後の値はかなりおかしな数字になっている．⇒UlongをIntに変換みたいなおかしなことをやっている．PERFORMANCE_INFORMATIONという構造体でシステムから値を取り出している．この情報はWin32時代のものであるような気もするので，無視してみよう．⇒問題なく描画できた．安全のためにこのようなことをやっているのだろうが，ぎりぎりまで使い込んでもよいのではないかと思う．メモリ不足が発生すればいずれシステムエラーがスローされるはずだ．
CheckCommitChargeの検査は，①カード合併，②インポート，③完全木テストの３箇所で，おそらく過去にメモリ不足状態で悩まされたことが理由ではないかと思う．現在のメモリ管理はその頃とはかなり変わっているはずなので，無視しても多分問題ないのではないかと思う．スタックで1GB使っているのが影響している可能性はあるが…
▲画面設定でチャンネル数をゼロに設定して例外が発生した．⇒一般のサンプルではエラーになっていないが，33点のチェーンではGENEBOX：findSameGeneで例外が起きる．GENELIST：AddSameChainで世代枠が空になっている．このサンプルをCollatzChain 32769-32.zelで保存して後日デバッグすることにする．
GetTheNumberで生成したCSVもインポート時にエラーになる．CSVファイル自体は問題なさそうに見える．エラーが起きたのはリリース版で，開発環境では問題なく読めている．Truncated treeのCSVも問題なく読み込めたが，サンプルには問題がある．Truncated treeになっていない．枝数は3だが，高さが32あるはずなのに，5しかない．しかも軸線図になっていない．これはおそらく，論理変更して再帰呼び出しを使うようにしたことに伴う不具合と思われる．これはCollatz Tree Generator側で調べるしかない．⇒できた！⇒いや，できていない．3つのグループに分かれてしまっている．
隣接リストの2行分の情報が欠落している．画面上には表示されている，ゼルコバの木で脱落したものと思われる．理由は分からない．何かその項にだけ特別な理由があるようには思われないのだが…CSVファイルで欠落が生じている．本人は存在しているが，親が不在だ．親不在ノードは2つ，2339と6563だ．2339の親は3509，6563の親は9845．書き込みは実行されているのだが，自分自身が自分の親になっているようだ．番号の割り付けが悪いのだろうか？しかし，ここでだけそのようなことが起こるという理由が分からない．