今日はどのマシンも検証テストはお休みだ．予備機はテスト完了してレポート送信に失敗した状態になっている．ネットに接続していなかったためだ．予備機はマウスを持っていないので，WiFiに繋がっていないと操作も面倒くさくなる．要修正点はかなりあるが，方針はほぼ確立したので淡々と進めるだけだ．ユーザインタフェースを整備するだけでなく，内部ロジックの整理も進めている．基本的には共通処理の関数化だ．幹線図で一つ大きなバグが出ている．
まずこれを片付けなくてはならない．一般木モードで枝番号リストに以下のような枝番号列を入力して，幹線図を実行すると下図が出力される．150, 150, 149, 150, 149, 150, 150, 149, 150, 150, 150, 149, 149, 149, 150, 150, 150, 150, 150, 149, 150, 150, 149, 149, 150, 150, 150, 149, 150, 150, 149, 150, 1,
まるきり壊れている．基本的に幹線図と系統図はまった同じ論理になっているはずなのだが，一方は正しく動作し，他方は誤動作している．どこが違うのか？比較してみればわかるだろう．仮想木では問題は発生していないように見える．悪いのはもちろん幹線図の方だ．いや，系統図の方も動作しているようには見えるが正しくない．高さは33あるはずなのに主力は２段しかない．いや，コラッツ数列の方もおかしいのではないか？10段しか出力されていない．枝番号リストの要素数は33なので33段分の出力がなければおかしい．
いや，これはおそらく勘違いだ．というか，現行では裾刈りしているのですべてのデータが画面上に残っている訳ではない．やはり，ファイル出力を取っておくことがどうしても不可避だ．まず，それから片付けるのが先決だと思う．ダンプ出力（Output Frame）に出力している内容を逐次ファイルに保存すればよいというだけだから，それほど難しくない．出力先ファイル名は現行を踏襲でよいのではないか？B面の4機能すべてについて対応する必要がある．
GetTheNumberとTruncatedTreeを統合するという一度挫折した試みを再試行してみた．大体動作しているように見えるが，上のサンプルではやはり不具合が発生する．この仕掛けで少し調べてみることにする．Workingが落ちている．なぜだろう？⇒対処した．DumpSuccessorではN=1のときはループから脱出するような作りになっている．理由はよく分からないが，これでは問題は解けない．⇒この一行を止めて動作するようになった．N=1でループから脱出というのは仮想木の論理だ．
しかし，同じ論理で通常は正しく動作しているのはなぜか？いや，やはり誤動作している．たとえば，{3, 4 1, 2}のような枝番号列を与えると同じ不具合が発生する．⇒正しく動作するようになった．これで4つの主要機能のうちの2つが完全統合できた．この論理は十分整理された短いものになっているので，ここに関してはほぼ仕上がったと言ってよさそうだ．GetTheSequenceの動作に関しては「遅い」という以外ではいまのところ不具合は検出されていない．VerificationTestはこれら2つの機能を同時実行しているだけだから，GetTheSequenceが正しく動作している限り問題は発生しないと考えられる．
従って，主要な課題は，①ダンプ出力のCSVファイル保存，②GetTheSequenceの時間効率の改善の2点に絞られたと見てよいが，その前にユーザインタフェースの仕上がり度を見ておこう．以前は検証テストのときは，Verify以外のボタンはすべて隠すようになっていたが，現行では表示したままになっている．ただし，不能状態になっているため，アクセスはできない．処理を止めることができるのはその処理を実行したボタンだけだ．この仕様は統一していた方がよいと思われるので，現行仕様でゆくことにする．つまり，検証テスト時でもボタンは表示されたままとする．
いまのところUI上の問題としては，幹線図でボタンを押しても停止しないということぐらいだろう．これは上記の幹線図と系統図の統合に関わる修正がまだ収束していないことを意味する．それ以外の気になる点としては，幹線図ではダンプのスクロールが止まっているという点くらいだ．これはリッチテキストへの書き込みのタイミングの問題であるか，もしくは巨大数ではイベント取り出しを挿入することで解決できる可能性はある．それ以外に関しては大体整ったのではないだろうか？
なぜだろう？今度はスクロールしている．どこかで詰まっていたような感じの動作だ．Hideしたあと，復帰するとスクロールが止まるようだ．Hideでは一度バッファを空にしているはずだが，何かそれが影響しているのだろうか？処理速度もガタ落ちになる．⇒いや，Hideは無関係だ．おそらく，幹線図ボタンを押して停止しないことに関係があるような気がする．⇒修正箇所の末尾にExit Subが入っていなかった．⇒問題なく動作するようになった．
一度バックアップを取って次に進むことにしよう．GetTheNumberからストリームの生成と削除を外部に出しておこう．巨大数からスタートしたら，検証テストが停止してしまった．画面は完全にフリーズして進捗は0.1%から進まない．時間パラメータなどもまったく更新されていない．検証テストでは分岐枝リストは隠蔽されているので巨大数が変化しなければ画面は更新されないかもしれない．GetTheSequenceの中でループしているが，現在処理している数は以下のような超巨大数だ．
2528058605650309290508888155878365873428777429329610245413531311009122565860838398507676428668641990449924367323415451899873821658847829619188476564609366352702999427697461717245345793567375753419434826837084809819187673744168005156233758197632068953158785059785541461281384157479418664309929750546454137807100651733674745192215247806173061415661839289683203890090799608996185234179653008138574134546686477565876857223738465581402202324837022126911299780190554607097797321091022298422990450981213040487361883130177550274229688099047178007993463543466203946899609777870963425143600687946887565306149102811552895681467300892411042453238919661322541656922453905703571728895506294249735279164519588778426338081418949046404041681479238492604279022081466893412796769929379101948906135366346556249038540581372645520472412289359158618160358472412007263793121017706881937054156793116038312573754653787854831684987083042562324675862091671106947587988672526236381818013363344313272643366547662655499416749339394332340176276845975735034944354345222361668081960134567712321247966403147137800022177709922207678398723630459082515612288167182980860868275309339807915114956553254228004239564965290904251972179527263931857494381014516047575390935825383341046273927855566344464493488087683285937219283412323388880268163013662384395026919914134269357896864175558581186612427162216168365618463641156257182811002745355638232058728168430212999716687243704359848387162463650198548737380336455000358109722081517100982229523851170083754245876978645997331446338585042572500540785537263453251586772867411773336673190389168808627642636740855484632735780130900694184850022908970961446381394196206567809487558672332285449135115500613758090759592501637733418414924494658499763499749856740392865738955937234908453589448627698488692327206913615159097455685630844807972113898597783728932686448197518328126736829742390484357327113612260986903860617280533132678703505809113795840336620912869135871285494809094219271876873193265897002339123448429406329793247623719431024457369184752032579844081845296815886142703127974129227170157151804670910364810214712275525981570448756401609764176601856457372634115371231558719016454868541064094196519074271639976183450304297493329628312917928009732620232965631112624422524888664476298883361486396999151217833342975058899339373560896635625507523367553360174880186864107155082164864619938566418729901717598133498744620859209004876233472945760658609354893169209360729580935766846602167702420539905855305875674621605368095487025419303392943367665067729641716782433336757636642964226393686660548609857855764209129788534360371354102204246160762995746366552409916472833822395730989310836921450340272188606083871652340560597556625997008012136989408662213438565313314843377659202426377961998727361330326547838071166092452532445441603781668225681266965867081944059412887781
確かにこれではとてつもない時間がかかっても仕方ないような気はするが…はて，どう対処したらよいのだろう？処理に要する時間を見積もることができるだろうか？ループ回数が分かればある程度の推定はできる．樹高は現在9287という数字になっている．まず，その前に最大分岐数と最大樹高を格納しているパラメータを計算用と統計用に分離しておくことが必要だ．コラッツ数列処理と分岐枝リスト処理はそれぞれ分岐数，最大樹高を管理しているが，それと検証テストで使っている大域変数を分離する必要がある．この修正も結構広範なものになるので，一度バックアップを取り直すのが賢明だ．
▲コラッツ木生成でダンプのスクロールが始まるまでに時間がかかる．
なぜだろう？検証テストがやけくそ遅くなっている．画面もほとんど更新されない．いまの修正の影響だろうか？2^13で2分39秒もかかっている．また，テスト終了時にスクロールしていない．GetTheSequenceの動作にはまったく問題がないようだ．GetTheNumberではMax Degreeが0のままだ．また，それを与えるノード番号も間違っている．Max Degree 3 @ 77と表示されているが，77[3]=821なので，3 @ 821と表示されなくてはならないところだ．TruncatedTreeでは上の症状がまたぶり返している．しかし，修正は残っているので，今回の修正の影響だろう．反例はOdd number=16385．
共通処理のGetTheNumberでは冒頭で最大分岐数を取得しているが，その計算を仮想木のときしか実施していない．これはかなりおかしい．これでは動作するはずがない．しかし，それにしては分岐枝リスト処理では正しく動作しているように見えるのだが…⇒おそらくこれは，分岐枝リストでは最大分岐数は動作に関わりがないためだろう．幹線木ではその値がないと木を構成できない．⇒対処した．
幹線木ではMax Degree 3 @ 262165はた出しいが，Tree height 15 @ 262165は間違っている．これは15 @ 16385でなくてはならない．Tree heightはあとから見ることにして，分岐枝リストのMax Degreeの誤認を見ておこう．この処理ではMaxDはあらかじめ定まっているので，比較して該当ノードを決めているはずだ．821の分岐枝が1になっている．これは間違っている．⇒幹線図と分岐枝の統合で手抜かりがあった．⇒完全に動作するようになった．上記のTree height 15 @ 262165の誤りも解消した．Tree heightのローカル化もやっておこう．
不測の事態に備えてバックアップを取ってから始めよう．木の高さに関してはTreeHeightとMaxHeightの2つのパラメータが使われている．B面のTreeHeight2に格納されているのはこの値だ．MaxHeightが使われる場合もある．混乱を避けるために，MaxHeightを統計更新用に用いることにする．MaxHeightはすでにそのような使い方に統一されている．TreeHeightは現状でも問題なさそうだが，一旦廃止して個別にローカル変数として再定義することにする．
大体収まったように思われるが，仮想木ではまだかなり悪い．GetTheSequenceでMax degree=0，Tree height 0 @ 85などのおかしな値が出ている．GetTheNumber, TruncatedTreeは正しく動作しているようだ．GetTheSequenceではMaxHeightは最後にならないと確定しない．⇒大体収まったのではないかと思う．⇒検証テストがやけくそ遅くなっているのはなぜだろう？このテストはGetTheSequenceとGetTheNumberを交互に実行しているだけなので，そのどちらかないし両方が遅くなっていると考えるしかない．GetTheSequenceはGetTheNumberよりだいぶ遅い感じがするので，それが原因かもしれない．この速度の差は元々存在していたように思われるのだが…
ともかくMax degreeとTree heightを片付けてしまおう．検証テストではMax degreeがまったく更新されていない．直接値を書き換えている場所があったので，すべて排除した．多分これで問題は解消したのではないかと思う．もう一つ整理しておきたいことがある．汎用の小さな変数がグローバル変数として定義されているという問題だ．この中には，D, H, i, j, Nなどがある．⇒片付いた．
今日の午後5時ころにバックアップした版では，まだここまで遅くなっていない．多分この直後の修正で何か致命的な不良が紛れ込んだものと思われる．この版ではすでにGetTheNumberとTruncatedTreeの統合は実現されている．確定的なことは分からないが，上記の3000桁以上あるような超巨大数に対処するための修正にかかった辺りから異変が生じているもののように見える．このバックアップのあとに2回バックアップを取っているので，修正は相当広い範囲に及ぶものになっている．これをもう一度手戻りするのはかなりきつい．しかし，シューティングもかなり難しそうだ．この版と次の版の差分を調べてみるというのが一番早いのではないだろうか？ともかく，いま現状でバックアップしておこう．
フォルダ名を変更したことが影響している可能性はあるだろうか？これまではCollatzProjectという名称だったものをCollatzMilkywayに変更している．これで影響するのはスタックサイズの変更でそれに失敗していれば速度に影響する可能性は大きい．変更点を列挙してみよう．
- HIDEBRANCHLISTのON/OFFが違う
- sjisEncという変数名をUTF16に変えた
- Nが巨大数のときDoEventsを実行する
- ゼルコバの木CSV出力を前方に移動
- GetTheNumberのオリジナルコードを廃棄
- TruncatedTreeの修正をフィックス
- UpdateTreeHeight関数の修正を確定
いや，どうも少し勘違いしていたような気がする．上記の3つ前のバージョンでも開発環境で走らせるとそれほど速いというほどのものではない2^13で1分58秒かかる．一方最新版もEXEを走らせた場合には同じ設定で3秒で完了する．ということは，まったく遅くなっていないと言える．この版は廃棄して作り直すつもりだったが，そのまま続行で問題ないようだ．いや，しかし，どうにも腑に落ちない点はある．上で実行速度をチェックしたときは，すべて開発環境でリリース版を試している．3つ前のバージョンは少なくともそのときは十分速い実効速度を持っていた．
いや，間違っている．いま試している版はColatzProject 2022-02-08 BADというものだ．最新版は同じBADでも，CollatzMilkyway 2022-02-09 BADだ．それではColatzProject 2022-02-08 BADはどこから出てきたのか？これは今日の午前0時32分なので最新版ではないかと思うのだが，CollatzProjectとついているのだから旧版の系統だろう．しかし，中身は2022/02/08のCollatzMilkyHighway.exeだ．どうも訳がわからなくなってきた．いや，これは少なくとも24時間以上前の版なので，最速版よりも古いことは間違いない．確実なのは，CollatzProjcect 2022-02-008-2というバージョンだ．ともかく，ここから出直そう．