マニュアルの再編成という最適化問題

開発機に仕掛けた検証テストが完了している.1日+6時間58分で2^28をこなした.当初の見積もりは1日+十数時間だったので,それよりはだいぶ早くなっている.残り時間が変動するのは,カウントがまだ上がっていない時期で,ある程度以上進むとほぼ安定してセコンド単位で進むようになる.カウント数が少ない段階で変動するのは当たり前だろう.⇒開発機には続きを仕掛けておいた.残り時間1日+14時間と出ているが,もう少し小さい数字になるだろう.

フィードバック情報にはユーザ情報は何も含まれていないが,せめて使っているプログラムのバージョン番号くらいは取り出しておきたい.⇒アプリのタイトル行を出力枠に直接出力するようにした.バージョンを一つ上げて,V1.1.3としておこう.これがおそらく最終版になるだろう.Rel 2022-01-26だ.

マニュアルは用紙サイズとフォントサイズを変更したので,全面的な模様替えになってしまったが.大体収まった.このドキュメントには画像がふんだんに入っているので,それをページ内に配置するというのはまるきり最適化問題そのものになる.「正則コラッツ木」に関する記述を前方に移したりなど,相当大掛かりな修正になったが,何とか見られる状態にはなったのではないかと思う.逆にここまでやると,どこかに一行追加するのも難しくなる.つまり,それが,ほぼ完成ということになるのではないか?ともかく,PDFを印刷してみよう.

カスペルスキーのパスワードマネジャーが突然立ち上がって,パスワードの入力を求められた.通常起動時に一度パスワードを入力すればその後は何も操作しなくてもよいはずなのだが…それはそれとして,このとき同時におかしなポップアップが表示された.

image

「It’s lonely here! Your sensitive PDSs are waiting to get into the vault.」というもので,ネットで調べると同じような事例がある.

Nothing stops annoying Kaspersky messages/advertisements, Kaspersky Secure Connection [Solved][Closed]

パスワードを入力し終わるとほぼ同時にカスペルスキーからの通知が入ってきて,「個人情報の商用利用に関して」許諾を求められた.拒否してもサービスは継続されるので,拒否しておいたが,それとこれは関係あるのだろうか?ないのだろうか?カスペルスキーの言っているvaultというものがどういうものなのかよくわからないが…⇒パスワードマネージャが使っている暗号化されたストレージだ.しかし,そこにPDFを移すというのがよく分からない.カスペルスキーは最近わたしがPDFを編集したりしていることを知っている様子だが…「読んでるよ」って挨拶かな?

Branch order sequence周りの用語を統一するためにかなりの書き換えを行った.刈り込み木などもう少し精確に記述したいところだが,行数が変化するとレイアウトがまた壊れてしまうので,ここまでということにしたい.ただし,用語を変えたので画像の差し替えが必要になっている.これはやっておくしかないだろう.かなりの枚数があるが,片付けることにする.サブノートのCドライブも逼迫している.元々28GBしかないのですぐに使い切ってしまうのだが…

図版もすべて差し替えて一旦編集完了と言いたいところだが,もう少し書き直しておきたいところがある.Up to the power of 2 と test countの関係が分かりづらい.むしろストレートにTest countと表現しておいた方がよいような気がする.そうなるとまた図版の張替えになるが仕方ない.Branch number sequenceはすべてBranch order sequenceに書き換えたのだが,Copy branch order from the sequence というのもイマイチ意味不明だ.Auto-copy branch ordinal numbers in I/O frameとしてみたが,I/O frameという用語は画面上では明示されていない…

テキストの修正は容易だが,図版がからむと手が掛かる.ともかく,まず,画面要素を完全に確定しなくてはならない.test count k=2^pとすると,計算式も書き換えなくてはならない.LNK1342というエラーが出ている.

1>C:\Users\babalabo\Desktop\CollatzProject2\bin\Release\net5.0-windows\CollatzTreeGenerator.exe : fatal error LNK1342: 編集するバイナリ ファイルのバックアップ コピーの保存に失敗しました

この原因はポストビルドイベントでCollatzProject2にアクセスしているためだ.

“C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\Hostx64\x64\editbin.exe” /STACK:1073741824 “C:\Users\babalabo\Desktop\CollatzProject2\bin\Release\net5.0-windows\CollatzTreeGenerator.exe”

CollatzProject2というフォルダはすでに廃止してCollatzProjectを使っているので,書き直しておかなくてはならない.⇒対処した.タブBの画面はこれで決まりとしたい.

image

これに合わせてプログラムを書き換える必要がある.⇒終わった.あとは図版を張り替えるだけだ.今後のこともあるので,バージョンに関わりなく同じファイル名でダウンロードできるようにしておきたい.パッケージに入っているEXEは現在も共通の名前を使っているが,パッケージ名もバージョン番号を外してCollatz Tree Generator.zipとしておくのがよいと思う.アナウンスの手間も省けるし,差し替えも容易だ.マニュアルはCollatzTreeGeneratorManual.PDFでよいと思う.

マニュアルはほとんど仕上がった

開発環境で走らせている検証テストは最新版なので残り時間が出ている.それによるとあと7時間掛かる見込みだ.経過時間は23時間40分なので所要時間は1日+7時間くらいということになる.予備機の方は4日+3時間50分で進捗は42%だ.あと5日は掛かる.マニュアルはほとんど仕上がったのではないかと思う.あとは,リンク関係を整備するだけだ.しかし,リンクを入れるためにはまず,対象ファイルがアップロードされていなくてはならない.少し整理してみよう.

  1. マニュアルをPDF化する
  2. Collatz Tree GeneratorのZIPパッケージを作る:この中にはマニュアル.PDFを同梱
  3. Collatz Tree Generator.ZIPをownCloudにアップロードする
  4. Collatz Tree Generator.ZIPの公開リンクを生成する
  5. ゼルコバの木テント村の先頭ページThe Collatz Conjecture was solved の画像→Collatz formulas are like a black Hole of natural numbersの英文記事へジャンプ
  6. Now Collatz Tree Generator V1.04 is available here for free をV1.1.2に書き換えて,4のリンクを挿入する

問題は,マニュアル本文の中に4の公開リンクへの参照が含まれていることだ.従って,まず,マニュアルを同梱しないバージョンのパッケージを作成し,それをownCloudにアップロードして,公開リンクを取得する必要がある.その後,マニュアルにそのリンクを記載して,最終版としてPDF化し,それを同梱したパッケージを作り直して,アップロードし直さなくてはならない.ownCloudは多分,ファイルの差し替えができるようになっていると思うが,それも試してみなくてはならない.

PDFのアップロードはownCloudが一番安全だとは思うが,ここに置くと,ブラウザで開くという使い方が(多分)できない.PDFをHTML化してテント村におくか,ないし直接ブログの記事として公開するということも考えられる.これは後から考えるとして,ともかくまず最新版のCollatzTreeGeneratorをアップロードしておこう.これもできれば同じアドレスで異なるバージョン(最新版)をダウンロードできるようにできるとよいのだが…ownCloudはかなり限定的なことしかできないようだ.できることといったら,ファイル名の変更くらいしかない.

ownCloudのクライアントアプリというのがあるのでインストールしてみよう.インストールはできたが,どうもイマイチだ.確かにリモートフォルダとローカルフォルダを仮想化してローカルでもファイル操作できるようにはなっているのだが,連携があまりよくない.リモートでアップロードしたファイルを共有設定しても,ローカルではそれが反映しない.同期というのが,上り方向で同期を取るのか,下り方向で同期するのかもよく分からない.少なくともローカルフォルダに新しいファイルを追加すると,クラウドにアップロードされることは確かだが…共有設定などはローカルでは操作できない.

これでともかく,同梱したPDFファイルの差し替えができるものかどうか?試してみることにしよう.⇒どうもやはり,差し替えはできないようだ.つまり,もう一度公開リンクを作り直さなくてはならない.これでは堂々巡りになってしまう!しかし,共有リンクは切れていないので,ダウンロードはできる.現物は差し替わっているので実質的には問題なさそうだ.つまり,ローカルフォルダのアイコンの表示の問題だけと言ってよさそうだ.これで段取りはすべて整ったのではないだろうか?あと,付け加えるとしたらPDFをブラウザで開けるようにするというのがあるが…⇒いや,案ずるまでもない.

PDFファイルをownCloudにアップロードするとブラウザで開くようになっている.多分写真などもそういう扱いになっているのではないだろうか?あとは,CollatzTreeGeneratorの動作チェックと,マニュアルの校正だけだ.マニュアルは一度紙にプリントして裸眼でチェックした方がよい.いや,画面上でチェックするのと実質は同じなのだが,印刷したものの仕上がりを見ておきたい.このためには,まずダイソーに出かけて用紙を買って来なくてはならない.手元にはもう裏紙もなくなって,B4の用紙を半裁したものを使っているくらいだから…

英文社名をBaba Laboratory Inc. Ltd. からBaba Laboratory Inc. に変えることにしたので,ゼルコバの木の画面も変える必要がある.ゼルコバの木はいまのところまだ公開の準備は整っていないが…開発機のHDドライブがだいぶ逼迫してきている.開発用のD:ドライブから2021年度のフォルダをすべてバックアップドライブE:に移動したが,今度はE:ドライブが赤くなってしまった.外付けHD,SDXCも赤になっている.そろそろ何か大容量の外部ドライブが必要になってきている.

印刷してみた.Acrobat Readerではなぜか印刷できなかったので,LibreOfficeでODTファイルを印刷した.文字がやけに大きい!画面上では適切なサイズに思えたのだが,幼児向けの絵本になってしまった.しかし,この文字サイズを変えるのはかなり難しい.ページの割り付けがほぼ完璧に決まってしまっているからだ.このマニュアルの読者には高齢者と非英語圏からの参加が含まれると推定されるので,むしろこのままの方がいいような気もするのだが…

Acrobat Readerで印刷できない理由はわかった.セキュリティ上の理由で「起動時に保護モードを有効にする」がデフォルトでオンになっていたためだ.メニューバー→編集→環境設定→セキュリティ(拡張)→起動時に保護モードを有効にするのチェックを外して再起動してプリントできるようになった.

このプリントにはもう一つ難点がある.ページ全体が上に上がり過ぎている.上辺のマージンは2センチにも足りないのに,下は5センチも空いている.用紙がB5になっていた.これでは下が空くのは当然だ.一度バックアップを取ってから直すことにしよう.⇒Acrobat Readerのプリント出力は妥当なものだ.上下のバランスが整っているので,文字が大きくてもそれほど気にならない.もしかすると,これで出荷できるかもしれない.英語の苦手な人にはこれくらい文字が大きい方が読み易いのではないかと思う.1ポイント落として,11ptにしてみた.まぁ,これくらいなのではないかと思う.

マニュアルの執筆・編集はかなり進んだ

開発機に仕掛けた検証テストの進捗は4日+17時間48分で33.6%,予備機の方は2日+22時間で28%というところだ.1日当たりの進捗率は前者が8.8%,後者が12%というところで,予備機の方が2日分遅れているが,そのうち追いつくだろう.マニュアルの方はかなり進んだと言ってよいのではないかと思う.Verification Testがまるごと残っているが,それほど込み入った説明は要らないので片付くと思う.コラッツ木構造について,どこで言及するか?というのがポイントだ.枝番号リスト(数列)に関しては刈り込み木のところで図示するのが一番わかり易いような気がするが,コラッツ木構造に関しては言及しないということは可能だろうか?このマニュアルは論文執筆の下書きというつもりで書いているので,どこかで触れる必要があるような気もするのだが…

公式版をリリースしようとして,バージョンに関係するパラメータをあちこちいじっているうち,ビルドできなくなってしまった.管理者権限でVSを立ち上げる必要があるが,VSが立ち上がってこない.予備機では同じ操作でVS2017を開くことができる.再起動したいのだが,それをやると実行中の検証テストが吹っ飛んでしまう.どうしたものか…検証テスト完了まであと一週間以上掛かる…ここで止めたらすべてが水の泡だ…いや,そんなことも無いのでは?検証テストは開始奇数番号を指定して始めるようになっている.現在の最終番号はわかるのだから,そこから再開すればよい.今度は範囲をもう少し狭くしてせめて1,2日のうちに終わるようにしておこう.

いま,59.9%なので…いや,おかしい.進捗が0.59%まで落ちている.経過時間も1時間31分でまだ始まったばかりだ.いま,走っているのはV1.1.0 Rel 2022/01/19で仕掛けたときの版だと思うが…停止して,レポートを送っておこう.

Verification Test for the Collatz Tree Structure ( 22/01/23 16:22 UTC )
Start From 38651 up to 4295005945
Total odd number count: 2147483648
Big number : 102098975067917
Max degree: 12 @ 215307605
Tree height: 263 @ 15733191
Progress rate: .61%
Time spent: 01:33:18
Verification Test Stoped at 26046439

開始時刻は22/01/23 16:22 UTCだ.つまり,昨日の午後4時ということになるが,UTCの現在時刻は18:00なので,2時間前ということだろう.テストを実行しているパネルを操作したつもりはないのだが,誤操作で無関係なキーストロークが入ってしまったのだろう.と言っても,この状態になるためには,①画面が初期状態で開いている,②フォーカスがVerifyボタンの上にあるという2つの条件が必要だ.②というのはあり得るとしても,①が起きているというのはかなり考え辛い.一度閉じなければ初期状態にはならないはずだが,そのためには,一度閉じてそれをもう一度起動する操作が必要になるが,そんなことをやった記憶はない.これで情報はすべて失われてしまったが,ともかく再起動してみる.今度はVS2017が管理者権限で立ち上がってきた.

ビルドで失敗する理由はVBからOCXが参照できていないためと思われるが,このパスを通すのがなかなか難しい.一度切れるとそれを復活させるのにかなり厄介な手順が必要になる.もう一度作り直してみよう.⇒一応できたので,これを開発機にインストールしておこう.どこを変えるとビルドがうまくゆかなくなるのかを調べてみる.

いまのところ,①Licensecode.hでLICENSENOとVERSIONSTRを変更する,②SetupBeta3でVersionを変更し,UpgradeCodeないしProductCodeを更新,SubjectとTitle, ProductNameを変更,③version.vbの表示文字列を更新,④SplashWindow.vbのパラメータを更新,⑤SetupBeta3のプロパティでOutput file nameを変更するところまでは問題ないことが確認できた.

ZelkovaVB3のアセンブリ名をZelkovaTree2021からZelkovTree2022に変更してみよう.確かに,ここを変更すると,

「COM 参照 ‘ZelkovaZ3Lib’ は ActiveX コントロール ‘AxZelkovaZ3Lib’ の相互運用アセンブリですが、コンパイラによって /link フラグでリンクされるように設定されています。この COM 参照は参照として処理され、リンクされません。」

のようなエラーが出るようになる.このアセンブリ名は生成されるEXEの名前にも使われているようだ.まずいことには,この文字列を元に戻してもエラーが解消しない.ZelkovTree2022ないしZelkovTree2021で検索しても何も見つからない.ハッシングされているのだろうか?

どうも訳が分からない.アセンブリ名というのはEXEの名前を決めているだけのようだが…上記のエラーメッセージでググったら,上から4番目に2019/01/08に書いたテント村の記事が出てきた.この頃は「VS2017への移行」というのをやっている真っ最中で,山のような障害に包囲されて四苦八苦していたところだ.タイトルは

「VS 2017でインストーラをビルドするところまで進んだ」

この記事が自分の書いたものだということはタイトルを読んだだけでピンと来た.これは「わたしの文章」だってね.こういう感覚/センスはわたしに固有のものだったというのはかなり驚きだ.普通に書けば誰が書いてもこうなるような気がしてたからね.これがわたしのフレーバつまり〇〇味だってことがわかる.この記事には,こう書かれていた.

VBのプロパティ→署名で「ClickOnce マニフェストに署名する」をオフにしてこのエラーは回避できたが、まだもう一つ警告が残っている。
1>  COM 参照 ‘ZelkovaZ3Lib’ は ActiveX コントロール ‘AxZelkovaZ3Lib’ の相互運用アセンブリですが、コンパイラによって /link フラグでリンクされるように設定されています。この COM 参照は参照として処理され、リンクされません。
この警告は無視してもよいだろう。

確かにそれでもよいのかもしれない.しかし,さっきの結果ではEXEが作られていなかったような気がするのだが…⇒問題なく作られている.3年前のわたしはまだ若かった!いまでは小石一つにでもつまずいてしまうほど老いぼれてしまったよ…バージョンの更新はもう少し込み入ったところがあるのだが,外からは見えないところなのでここまででとりあえずパスすることにしよう.さて,何をしようとしていたところだったのか?何かサンプルを作るつもりだったのだろうか?

まず,ともかく開発機の検証テストを再開しておこう.もう一度1006634083から始めるしかない.2^32というのはやはり大き過ぎるので,中を取って2^30でやってみよう.予備機はこの設定で走っている.やはり,残り時間の計算は欲しいところだ.Verificationテストはあらかじめテスト総数がわかっているので,それを出すのは難しくない.ことのついでにやっておくことにしよう.

いや,どうも様子がおかしい.一旦テスト完了しているのに,またその続きをやっている.これはまずいだろう.どうも上で起きた不具合はこれが原因と思われる.つまり,テスト完了した時点でさらに延長が掛かっているように思われる.いや,ちょっと違うかもしれない.一度完了したと持ったのは,0.99%が1.00%に変わったのを誤認したのではないか?小数点の前に0を出しておいた方が安全だ.⇒大体動くようになったが,時間区間が広い場合にはなぜかかなり激しく変動する.相当長い期間増加が続いたりすることもある.計算式では局所的な値ではなく,全体の所要時間で見ているのでそれほど変動しないような気もするのだが…特に区間が1日を超えるようになるとかなり変則的な動作になる.なぜだろう?ともかく,少し長い時間を設定して様子を見てみよう.

1006634083から+2^28までという設定で開始してみた.丸一日+十数時間という見積もりだ.中間では上り下りがあるようだが,時間経過とともに少しづつ減少しているようなので推移を見ることにする.今現在午前7時くらいだから,明日の午後8時頃まで掛かるという予想だ.⇒走り始めは,1日+13時間くらいだったのが,1時間半経過して1日+8時間くらいに変わった.まぁ,順調と言ってよいだろう.

▲Collatz 3-5-94.zelを開き,画面に合わせてズームしようとして,PAGESETUP::GetPageCountのエラーが出た.また,親子連結垂線が途切れている.人名枠幅を小さくしても変化しない.氏名だけが右にずれてゆく.人名枠ギャップは調整可能だが,結婚枠ギャップは変更できない.⇒独立に変更できないとしても,人名枠ギャップに連動して小さくできるようにすべきだ.⇒写真枠幅をゼロにしたら,人名枠幅が狭まった.⇒CubePDFに出力しようとしたら,ハングしてしまった.⇒VS2017を2つ立ち上げていたのが影響していたかもしれない.一つ落として出力できた.

D=3,H=5というコラッツ木を掲載しようと思ったのだが,さすがに大き過ぎて収まらない.D=3,H=4くらいが限度だろう.⇒マニュアルはほぼ書き上げた.全24ページ.あとは細かい手直しといろいろな調整を行うだけになった.明日くらいにはリリースできるだろう.

Truncated treeが軸線図にならないバグ

開発機に仕掛けた検証テストの進捗は3日+17時間で24.8%,予備機の方は1日+21時間で16%というところだ.どちらもまだまだ掛かりそうだが,順調に走っていると言えるのでこのまま推移を見ることにする.

Truncated tree(刈り込み木)が軸線図にならないバグを片付けなくてはならない.この軸線図と枝番号リストは1対1に対応するものなのでこれを表示できるようにすることはとても重要だ.Odd number=32769のとき,最大枝数3,樹高32になるが,このサンプルの刈り込み木を取ると,3つの部分木に分離してしまう.参照番号が1ずれていることが原因なので,どこかに論理ミスがあるものと思われる.

imageコラッツ木生成ツールの画面に表示されている隣接リストは正しいが,オプションのゼルコバの木CSV出力に誤りがある.⇒親番号に1つ大きい数が割り当てられていた.ほぼ繋がったが,先頭の1で失敗している.1は#1として登録されているが,5も同じ#1で上書き登録されている.⇒対処した.あとは,これを軸線図として出すだけだ.

残念ながらエラーになってしまう.前に一度刈り込み木を軸線図として表示できたことはあったような気はするのだが…⇒SIMPLEGRAPH::MakeAntiChainListで最長鎖の長さゼロでゼロ復帰している.SIMPLEGRAPH::GetHasseDiagramで長さゼロを返している.⇒この関数は冒頭でゼロ復帰している.なぜだろう?ともかく,これを外してみる.

image途中エラーは出ているが,描画できた.これが刈り込み木と呼んでいるものだ.きちんとしたデバッグは後日ということにして,この図をマニュアルに取り込む段取りを進めよう.枝番号数列はこの図から簡単に導くことができる.上から,軸線ノードが右から何番目の子であるかを数えるだけだ.マニュアルには,15から生成される高さ5の刈り込み木を挿入した.

image

これで大体道具立てはそろったのではないだろうか?あとは,淡々と記述するだけではないかと思う.タブAの部分はすでに書き上がっているが,タブBに関してはまだ,画面構成にも残っている部分がある.これらは,タブBの4機能を書き上げた上で,その要約として書き込めばよい.従って,4機能をまとめるのが先決ということになる.


LibreOffice→PDFに変換はほぼ満点だ

開発機で走らせている検証テストは現在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の検査は,①カード合併,②インポート,③完全木テストの3箇所で,おそらく過去にメモリ不足状態で悩まされたことが理由ではないかと思う.現在のメモリ管理はその頃とはかなり変わっているはずなので,無視しても多分問題ないのではないかと思う.スタックで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つのグループに分かれてしまっている.

image

隣接リストの2行分の情報が欠落している.画面上には表示されている,ゼルコバの木で脱落したものと思われる.理由は分からない.何かその項にだけ特別な理由があるようには思われないのだが…CSVファイルで欠落が生じている.本人は存在しているが,親が不在だ.親不在ノードは2つ,2339と6563だ.2339の親は3509,6563の親は9845.書き込みは実行されているのだが,自分自身が自分の親になっているようだ.番号の割り付けが悪いのだろうか?しかし,ここでだけそのようなことが起こるという理由が分からない.

マニュアル編集はそれなりに捗ってはいる…

予備機の検証テストは2^28で現在91.4%まで進んでいる.2^32を仕掛けている開発機の進捗は10.6%だ.現在,1日+15時間なのでこの10倍ということは10日+150時間となるので,2週間,つまり半月掛かる見込みだ.どちらも堅調に走っているので,まぁ,これでいいのではないかと思う.⇒予備機で走っていた検証テストが完了している.1日+19時間27分だから,2^28で43時間半掛かっている.検証済み最大奇数は1006634081になった.サイトを更新しておこう.遊ばせておくのもなんだから,開発機の続きを仕掛けておこう.開発機はまだ10日以上掛かるので,予備機も2^30まで増量してみる.これでもまだ,予備機の方が先に上がってしまうかもしれない.⇒いや,とんでもない.2時間掛かってまだ1%も終わっていない…

マニュアルの執筆/編集に掛かっているところだが,書いた分だけ書くことが増えてしまうので完成までにはまだかなり掛かりそうだ.大体パターンも出揃ってきたので,あとは淡々と進めるだけというところには来ているが…⇒まだ仕上がっていないが,PDFに出力してみた.Good!これなら問題ない.LibreWriterの編集画面と寸分変わらないものが表示されている.これでなくてはならない.

HTMLでは表示にいろいろと難点があり,悩んでいたのがきれいに吹っ飛んだ.数式もきちんと表示されている.PDFならダウンロードしてオフラインで読むこともできる.一石二鳥だ.配布パッケージに組み込むこともできる.LibreOfficeはどうもHTMLが苦手なようだ.HTMLはルールもやかましく,ブラウザごとに動作が異なることもあるので,対応しきれていないのだろう.おそらく,LibreOfficeのファイル形式とPDF形式は相性がいいのではないかと思う.

あとはともかく書き上げるだけだ.⇒ゼルコバの木のリリース版を予備機にインストールしているが,ここではCSVのインポートでおびただしい数の障害ファイルが生成されている.同じ版のはずなのだが,開発環境ではそれが起こらない.なぜだろう?いや,何か勘違いしていた.インポートでは障害は発生していない.画面設定を操作したときに起きていたのだろうか?幹だけのコラッツ木の画像を取ろうとしているのだが…いや,それどころではない.Truncated treeの出力がおかしい.

#15を対象にTruncated treeをCSV出力して,ゼルコバの木で読み込んだところ高さ3の木が出力された.本来なら,(15, 23, 35, 53, 5, 1)なのだから,高さ5の木にならなくてはならないところだ.⇒画面出力は間違ってはいない.CSVファイルが悪いのだろうか?CSVファイルをダブルクリックしたらExcelが立ち上がってきた.このマシン(VAIO2)にはOfficeがプレインストールされているのだろうか?Microsoft Officeが使えて悪いということもないのだが…確かにMicrosoft Office 2013がインストールされているようだ.このマシンにはまだLibreOfficeをインストールしていないので,ともかく使うしかないだろう.

1→5→53→まではよいが,53の子どもの{35, 141, 565}が3の子どもになってしまっている.また,35の子どもの{23, 93, 373}が13の子どもになっている.53の下には{15, 61, 245}が配置されているが,これは23の子どもだ.CSVを見てみよう.確かに,CSVが間違っているようだ.#35の親が#3になっている.おそらくこれは,隣接リストの出力順が変化しているためだろう.以前の論理ではルートから一段目を水平に処理してから,次段に移るようなフローになっていたはずだが,現行は一番右端の下降パスを行きがかり順に垂直下降しながら出力するようになっているが,カード参照番号の振り方が従来通りになっているため,合わなくなっているのだろう.

Collatz Tree GeneratorのCSV出力は問題ないように見えるが,なぜだろう?正則コラッツ木の出力も再帰関数を使う形に変更されているはずなのだが…他の処理の出力を見てみよう.Get the sequenceとGet the numberはファイル名は違うが,どちらも1をルートとしているため内容はまったく同じものになっている.Get the sequenceは画面上では最後に1が出力されるようになっているが,あえてそれを逆転させて出力している.むしろ,素直に転倒木として出力してもよかったのではないか?

いずれにせよ,刈り込み木出力が間違っていることは間違いない.正則コラッツ木が正しく出力できるのなら,できてもよさそうな気はするが…確かに,正則コラッツ木と刈り込み木ないしナンバー木では上下関係が逆転している.これは後で見ることにして,先に刈り込み木をゼルコバの木上で編集して画像だけ取ってしまおう.刈り込み木というのは幹だけの直線図式に直結する葉を付け加えたものなので,ストレートに表示するためには,血統軸線図を使う必要があるが,動作しない.エラーになってしまう.この図はどうしても必要なので,ゼルコバの木をデバッグするしかない.どうもいろいろと厄介なことになってきた.ともかく,この機会にできる限り並行してデバッグするという方針なので,行きがかり上途中下車になってしまうのはやむを得ない.まぁ,この辺りの図面がなくてもまだ書ける部分はあるので,そちらを急ぐことにしよう.⇒仮の画像を作って貼り込んでおいた.

Collatz Tree Generatorの最新版では,所要時間に日数を表示

Collatz Tree Generatorの最新版では,所要時間が24時間を超えた場合には日数を表示するようにした.これで原理的にはいくらでも長時間のテストができることになったので,予備機と開発機にそれぞれかなり規模の大きなテストを仕掛けてみた.予備機は15時間経過して32%,開発機の方は同じく15時間経過で4.2%だ.予備機のテストはあと2日くらいで終わるだろう.開発機には2^32という検証テストを仕掛けている.これが完了するのにはあと2週間くらい掛かるという見通しだ.それでも,2^32までのテストを通すというのは,「当面の目標」だったので,それが単独で可能ということになる.

いや,テスト開始時の奇数番号は1よりもかなり大きいものになっているから,実際には2^32をかなり超えたものになるはずだ.いまの目標値は5301601377だが,電卓で調べれば2^cの値を取れるだろう.mmm…32.4という数字が出た.大雑把には2^32のオーダーということになる.ちなみに,2^32=4,294,967,296だ.テスト範囲(検査回数)を2^cで設定するようにしたのは,大きな数字を打ち込むのが面倒と思ったからだが,値を設定するようにした方がよかったのかも…

ボケを2つも連発してしまった

2つもボケを連発してしまった.一つは,「Verification Testで検証に失敗」の件で,これは明らかに,うっかりどこかのボタンを押してテストが停止していたのを「検定に失敗」と誤認したものだ.画面に「Verification Failed」と出ていたので錯覚するのも無理はないとも言えるが,その場合にはメッセージパネルが出るはずであり,単純な停止とは区別できたはずなのだが…B面ではVerifyボタンはStopに変化するが,それ以外のボタンではラベルを書き換えていない.しかし,他のボタンを押しているのならその検定を実行しているはずだから,当然RTFテキストボックスの内容も書き換えられていなくてはならない.

V1.05, V1.06, V1.07のすべてで問題の区間でエラーが発生していないことを確認しているので,原因がうっかりテストを止めたことにあることは間違いないが,他の検定を実行しないでそれが可能なのか確認しておく必要がある.⇒いや,B面でVerificationを実行しているときには,他のボタンはすべて隠蔽されていて,アクティブなボタンはVerifyから変化したStopボタンしかない.実際,これを押して止めたことは明らかだ.障害が起きたバージョンで現物テストしているのだから間違いない.このときの状態は確かに騒動が起きたときの状態と同じになっている.StopボタンはVerifyに戻り,RTFボックスにはVerification Test Failed!が出ている.メール送信ボタンはアクティブになっていて,表示されたテキストのボトムはThanks in advanceだ.

最新版ではこのような場合には,Verification Test Stopped at xxxx のよな表示が出るようになっている.進捗率と所要時間も表示される.停止した場合にも,その結果を送信することは意味があるから,Click…Thanks in advance となっているのは問題ない.メール送信ボタンも送信可能になっている.まず,これでよいのではないか?

もう一つのボケは,「Facebookに2000人分の友だちを抹消されてしまった」という騒動だ.これは明らかに勘違いで,数学基礎etcにコメントを付けようとしてログインしたとき,常用のアカウント以外の別のアカウントでログインしていたためだ.ただし,このアカウントは長期間放置されていたもので,パスワードも忘れ,変更手続き中だったのだが,マイクロソフトからは認証を拒否された状態になっていた.

アカウントに登録された情報との一致が認められる有効な身分証明書をお送りいただけるまで、このアカウントへのアクセスは認められず、お客様のリクエストにはお応えいたしかねます。

これは,ウェブカメラで撮った顔を左右に振る動画とパスポートの顔写真が一致しないと判定されたためだが,パスポートを更新するお金もヒマもないので(その必要もなくなった)放置していたので,本来ならログインできないはずなのだが…上記の拒絶通知の日付は2021/12/28で,その後,2022/01/04に「アカウントのロックが解除されました」というメールが入っていた.これは,頻繁に入ってくる「いつもと違う場所からFacebookにログインしましたか?」という通知に似ていたので,多分同種のものと思って見過ごしていた.このメールがoutlook.jpアカウント向けのものであることに注意すれば分かったはずなのだが…ともかく,古いFBアカウントが復活したことは喜ばしい.

確かにこのアカウントは使っていた痕跡はあるが,復活させようとしていたアカウントとはまた,別のものだ.わたしが復活させたいと思っているアカウントはプロフィール画像に百舌鳥の写真を使っているもので,アカウントは本名で登録されている.theory-edgeなど,過去の数学領域での活動はすべてM.N.で行っていたので,これを使いたいと思っているのだが…このアカウントではそもそも,メールアカウントとして何を使っていたのかも分かっていない状態だ.(時期的に見て)AYANETのアカウントである可能性はほぼないとは思うのだが…AYANETのアカウントはとっくの昔に死んでいる.

AYANETに連絡を取って,このアカウントを復活させるということも考えられなくはないが…それができれば古い友人たちとのコンタクトを復活させるのにも一番早いのだが…AYANETとはもう10年以上前から解約交渉を進めていて,ずるずるとここまで来ているのだが…まぁ,もちろんコラッツ問題の賞金が入ってくれば,恒久的にこのサイト(冷たい森)を維持することも難しい話ではなくなる,とは言えるのだが…

Facebookから電話番号変更の通知が届いた.OutlookのアカウントとGmailのアカウトで同じ番号を登録しているためだが,古い電話番号を「他の人が登録しています」という状態になっている.Outlookではすでに電話番号を変更しているので,上記のモズアカウントだろうか?Facebookは本来実名登録が原則だ(だった)が,実際には複数アカウトの使い回しを認めているようなので,多分同じ番号でも通るだろう.(アカウント分だけのスマホを持つなんて不可能だし…)

最新版の動作に一つ問題がある.Verifyを実行して,ボタンが「Stop」になっているとき,これを押すと停止してStopped at xxxx が表示されるが,その直前に何かのダンプが瞬間的にスクロールしている.おそらく,Stopを押したタイミングではまだ検証論理が別スレッドで走っているから,このタイミングでフラグが落とされたためにダンプが可視化されているのではないか?これは画面が停止したときには上書きされているので,実害はないと言えばないのだが,あまり芳しくない.

アノーマルな停止の仕方ないし出力画面の更新には複数の場合がある.①Stopボタンが押されて停止,②検証テストが失敗したために停止,③実行時なんらかのシステム障害が発生して停止,④メール送信エラーが発生してエラー情報をダンプ.⇒始業時バックアップと仕掛り版で異なる動作になっている.どこかいじってしまったのだろうか?⇒確かに一箇所修正が入っていた.Running_Click_1の冒頭で

If Working and Not Runflag Then

となっているところで and Not Runflag を削っている.このように修正すると,Stopボタンを押したタイミングで例外が発生するようになる.オリジナルではStopボタンではこの論理を通らない.Working というのは,検証テスト中でかつ,検査ルーチンのGetTheSequenceとGetTheNumberのペアを実行中という意味だ.Runflag というのは,検証テスト中という意味だから,どこかでRunflag が落とされた場合には無視するという意味になる.しかし,もう少し進んだところで出口に向かうようになっている.しかし,この論理もややおかしい.出口に分岐する前に実行しているのは各種パラメータの初期化だが,ここで開始時刻なども設定されている.

しかし,それにしては正しい値が表示されているようにも見えるのだが…おそらくこれは,上書きされているため正しい表示になっているのだろう.本来はこの処理はフラグだけ変更して抜けるべきものだと思う.この意味で上記のNot Runflag を外した修正というのは正しい.⇒Not Runflag を外すことで余分な処理を実行することはなくなったが,逆につねに Test Completeになってしまう.RunFlagを落としてやればよいのだろうか?⇒そのようだ.気持ちよく止まるようになった.

これ以外のアノーマルケースの動作も確認しておこう.②は問題なく動作する.②の検証テスト失敗と,③の実行時システム障害は本質的に同じだ.③ではたとえば,整数演算でエラーが発生するなどのことが考えられるが,メモリ不足を除けば,これらすべては論理ミスということになると考えられる.メモリ不足は避けられないが,これもある意味では「検証テスト失敗」と呼べなくもないので,同じ扱いでよい.メール送信エラー時にはすでに検定は完了しているのだが,その後に発生したエラーをログとして記録するという趣旨なので,現状でよいと思われる.

メール送信結果はメッセージパネルで通知されるが,ユーザとの応答をテキストボックス上でやっているのだから,ここにも何か残した方がよい.⇒対処した.これで完成だ!リリース版を起こしてみよう.⇒所要時間は24時間制になっているが,24時間を超える場合もあり得る.dayまで表示するようにしておいた方が安全なのではないか?⇒対処した.一日を超える場合にだけ日数をdays.hh:mm:ssの形式で表示するようにした.これで完成というところかな?

このパッケージには,高さ8の3-正則コラッツ木のサンプルをPDFファイル形式で添付する予定だ.Collatz Tree Generator のCSV出力をゼルコバの木にインポートして,CubePDFに出力し,LibreOfficeで調整したものだ.全766点というゼルコバの木としては大型のサンプルになったが,「正則コラッツ木」というものがどういうものか,直感的に理解してもらうにはちょうど手頃のサンプルではないかと思う.V1.1.0とした.今度は24時間を超えても対応できるので,予備機では少し欲張って2^28という設定で仕掛けた.24時間くらいあれば完了できるのではないかと思うのだが…

開発機にも仕掛けておくことにしよう.予備機の受け持ち区間の続きをやらせることにする.こちらは,ちょっと無茶だが,2^32まで仕掛けてみる.スタート時点ですでにかなり大きい数になっているので,どういうことになるのか…まぁ,一種の限界テストないし耐久テストということでやってみる.⇒さすがにこれは少々無理っぽいという感じもする.いつまで経っても0.01%まで上がってこない.⇒予備機の方は,30分で1%くらいなので,1時間で2%として,50時間,ということは丸2日は掛かりそうだ.開発機の方はもっと遅く,30分でわずか0.15%だ.うまく行っても,3時間で1%くらいだろうか?何日掛かるのか見当もつかない…1ヶ月は掛からないとは思うが,1週間では終わらないだろう.

Verification Testで検証に失敗

予備機に仕掛けておいたVerification Testで検証に失敗している.

Verification Test for the Collatz Tree Structure ( 22/01/16 18:00 UTC )
Start From 402654307 upto 469763169
Total odd number count: 33554432
Big number : 2194137831130865
Max degree: 14 @ 2102744405
Tree height: 361 @ 423186581
Time spent: 03:36:36
Verification Test Failed!
Click the mail button above and send the result to us (babalabos@outlook.jp) !!
If you have any additional infomation, use the colored textbox as a sticky ote.
Thanks in advance...


Enter any additional information here.

サイトの掲示では,すでに469763169までは検証完了となっていたので,402654305まで巻き戻した.このエラーが発生していることは昨晩中に確認されているが,すでに少しアルコールが入っていたため,そのときどう対応したのかよく覚えていない.レポートは送信されているので,「メール送信」ボタンはクリックしているようだが,パネルに表示されているテキストには少し不審な点がある.上掲のメール本文には

Start From 402654307 upto 469763169

とあるが,画面ではこの行の後ろの部分「upto 469763169」が欠けている.

image

このテキストが表示されているRTFテキストボックスは読み取り専用で,間違っても上書きしたり,修正したりすることはできないはずであり,うっかり消してしまうようなことは起こり得ないはずなのだが…念のため,スクロールして下の部分もスクショを取っておいた.

image

ピンクのテキストボックスは書き込み可能で,「VAIO2 FAILED」の文字列はわたしが後から書き入れたものだ.ただし,「メール送信」ボタンは一度しか使えないため,この画面内容は送信されていない.ともかく,障害が再現可能かどうかを見るために,開発機で同一設定のテストを開始したところだ.ただし,走っているのは最新版のV1.07でエラーが起きているのはV1.06だから,必ずしも再現できるとは限らない.エラーが発生した実機でV1.06を走らせて再現性を見ることにする.

RTFテキストボックスはRead Onlyのはずだったが,書き込みできてしまう.これはかなりまずいと思う.また,エラーが発生したときの進捗率が表示されていないのも問題だ.Odd numberに表示されている423186581という数字はエラーが発生したときの対象となる奇数番号とみられるから,この数字から開始してエラーが発生するかどうか確認できるはずだ.ともかく,このエラーは最重要なのでじっくり取り組むことにしよう.コラッツ木構造に何らかの欠陥があるとすれば致命的だが,修正ミス,その他の理由も考えられる.

現行版で423186581からテストを開始してみたが,再現しない.もう少し若い番号から初めてみよう.1000番ないし10000番前から開始してみたが再現しない.V1.06に戻って確認してみよう.どうも,この版はバックアップされていなかったようだ.あるいは削除されてしまったのだろう.EXEは残っているが,パッケージが見当たらない.⇒EXEを走らせて再現を試みたが,再現できない.⇒この一つ前のV1.05で試してみよう.今回は実機と完全に同じ条件で走らせてみる.予備機では障害発生までに3時間36分掛かっているのだが,開発機ならもう少し速いだろう.この版ではすでに「Test Failed」を表示するようになっているので,条件はほぼ等しいと見てよいはずだ.

V1.05とV1.07を開発機に仕掛け,V1.06を予備機で走らせている.予備機では設定を間違えていたためやり直しになっているが,開発機のV1.07はすでにエラーが発生したポイントを通過している.⇒当初は検証テストが失敗して奇数Nとそれから計算したコラッツ木枝番号数列から得られる奇数N’で不一致が生じた場合,当初はStop文で停止するだけになっていたところ,V1.06辺りからエラーメッセージを表示するように変更している.このとき,エラー処理の動作を確認するために,ある条件が成立したときにはこのエラーを発生させるような論理を暫定的に組み込んでいるが,もしかしたら,この仮修正を残したままリリース版を起こしてしまったという可能性もある.

ただし,もしそうであるとすれば,その条件はたとえば,対象の奇数があるきりのよい数より大きくなったときとか,カウンタがあるきりのよい値を超えたときにエラーとなるように作っているはずだが,エラーの発生状況から見るとそのいずれにも該当していない.本命の予備機で走らせているV1.06はまだ6%を超えたばかりで,障害地点に達するまであと3時間は掛かる模様だ.最新版のV1.07はすでにこの地点をパスしているので,「コラッツ木構造に何らかの欠陥がある」可能性は少ないと見ているのだが…

Facebookで2000人近くいた友だちをすべて抹消されてしまった.グループ登録も消え,メッセンジャーにも何も残っていない(発信できなかった下書きが1本だけ残っている).数学物理etcに山本氏が投稿した「あのシュレーディンガーが、実は小児性愛者だった、という話。」に付けたコメントが虎の尾を踏んだのだろう.わたしはネット上の住人なら誰でも知っているような「公知の事実」しか書いていないのだが…https://www.facebook.com/groups/2354748741306929/posts/4738902149558231/ 辛うじてアカウントだけは残っているがFBからすればいますぐにでもパージしたいところなのだろう.まぁ,わたしはFBと刺し違えるつもりはないからね.

ごみ箱からRel 2022-01-17というフォルダを2つ見つけた.もしかしたら,この中にV1.06のソースコードが入っている可能性はある.しかし,開発環境では最新版を実行中なので,それが終わるまでは開くことができない.いま,96%というところをやっているので,ほどなく終わるだろう.⇒終わった.これはV1.06でエラーが出た領域の再試験に当たる.いや,おかしい.アプリは閉じたのにまだ走っている.V1.07と思ったが,走っているのはV1.05の方だ.こちらは,まだ15%しか進んでいない.

VSのインスタンスをもう一つ開いてみよう.[ごみ箱に残っていたフォルダは]2つともV1.06だが,一つはStopで止まるだけのものだ.もう一つはエラーパネルを出すようになっているが,動作確認用の仮修正は残っていない.予備機にはV1.06のEXEが2つ残っている.いまテストしているのがそのうちのどちらなのかは分からない.もし,新しい方なら多分停止しないで最後まで走ることになるだろう.古い方であれば,同じ障害が再現されなくてはならないはずだ.しかし,仮に障害を再現できたとしても原因を突き止めるのはかなり難しい.

すでに予備機で走っているテストは障害ポイントをパスしてしまっているので,おそらく新しいバージョンの方なのだろう.古い方を立ち上げて試してみよう.いや,見ている場所が違う.古い方というのは,BlackHawkのフォルダだった.⇒もう一つのケースとしては,単純にボタンを2度押しして停止しただけという可能性がある.ノーマルに終了したとき以外はすべてVerification Test failedを表示するようになっているので,何かの理由で停止したのを忘れていたのかも知れない.⇒いずれにせよ,単に打ち切った場合とエラーが発生した場合を切り分けるようにしなくてはならない.

メールを送信しようとして,エラーになったような場合,エラーメッセージの内容がメール本文に書き込まれるようになっている.検証テストでエラーが発生した場合も,例外を発行してエラーハンドラで処理するようにした方が安全なのではないか?こうしてあれば,メール本文を参照することで本物のエラーか,単に停止しただけなのかを読み分けることができる.どうも,いまのところ,状況判断した限りではテストを打ち切っていたのを忘れて,ないし,うっかり止めてしまったのを,画面上の「Failed」というテキストだけを見て勘違いしてしまった可能性が一番高いような気がする.

▲Odd numberが空の状態でVerifyボタンを押すとハンドルされていない例外が発生する.⇒関数の冒頭でOn Error GoTo を実行すると,エラーが反復発生するようになる.⇒ボックスが空でないことをチェックして警告を出すようにした.

B面のDegreeとTree heightはInt32の範囲に限定するという仕様になっているが,内部計算でそれを超える場合が考えられる.従って,内部では従来通りBigIntegerを用いるようにした方がよいのではないか?⇒一度バックアップを取ってから修正に入ることにしよう.⇒いや,とりあえず,そこまではよいのではないだろうか?確かに,32767×32767の木をくまなく調べればIntegerで間に合わない場合が出てくる可能性はあるが,Integerの範囲は2147483647なのでまず,大概のところはカバーできるのではないか?⇒当面は現状のままとする.

▲Collatz Tree 3-8-766.zelを人名枠幅を調整してから印刷しようとして,GetPageCountのエラーになる.

Get the Numberの出力に修正ミス

Collatz Tree Generatorはほぼ完成に近いと見られるが,まだ多少未整備のところが残っている.というか,Get the Numberの出力に修正ミスがあったので対処した.未整備な点としては,①Get the SequenceでランタイムにTree heightとそれに対応する最大ノード番号が更新されない,②Truncated treeも同様という点だ.①は終端ノードから1に下降する手順になっているため,原理的には計算が完了しないと高さは決まらないということになるのだが,途中経過として表示しても問題ないのではないか?②に関しては,Get the numberと論理を共通化すれば解決するはずだ.⇒いや,同じ論理を使うという訳にはゆかないのではないか?Get the numberとGet the sequenceではチェーン上のノードだけを見ればよいが,Truncated treeの場合,周辺ノードが最大ノードになる可能性はある.

大体収まったのではないかと思う.冗長な論理が入り込んでいないかチェックしておこう.⇒リリース版を起こした V1.06 Rel 2022-01-17.これは基本的に最終リリースに近いのではないかと思う.⇒リリース版を走らせて,32767×32767のコラッツ木生成をやらせてみた.Hideをチェックして,ダンプ出力を抑制すると,かなり速くなる.以前は1点処理するのに小一時間掛かっていたが,わずか16分で150点以上を処理している.Max tree heightは135なので底に達するまでにはまだまだ掛かりそうだが…B面のVerificationもなんだか速くなっているような気がする.Upto 2^16がx分x秒で終わった.これなら2^32を一息で片付けることもできそうだ.⇒いや,それはあまりにも甘そうだ.実際,1分走らせても進捗は0.01%に満たない.2^28くらいならある程度目に見える進捗がある.

▲A面を上限の限界で走らせて,停止したところ,応答なしになってしまった.⇒しばらく放置して復帰した.問題なさそうだ.再帰から戻るまでに時間が掛かっていたのだろう.

さて,またマニュアルに戻ることにしよう.⇒B面の画面レイアウトをもう少しだけ変えることにした.B面には機能が4つあるが,それぞれの機能の相互関係を飲み込まないとこのツールは使いこなせない.一番分かりづらいのがVerificationなので,それを他の機能から区別するために,できるだけ離すようにしてみた.現行はこんな感じになっているのだが…Get the sequenceとVerifyの垂直位置関係を逆転させて,Get the sequenceと他の処理の一体性を強調するようにしてみた.

image

上の図ではGet the sequenceボタンとメールボタンがくっついてしまっているが,デザイン画面でははっきり離れている.このマシンはどうも画素のアスペクト比の関係なのか何か分からないが,デザイン画面通りの表示にならないところがある.⇒Verification testではOdd numberを2づつインクリメントするような動作になっているが,テスト終了時には,最後にテストした番号が表示されている.むしろ,その次の番号を表示した方が分かりやすいのではないか?⇒対処した.その他,A面のBuild Collatz TreeとB面のVerification Testを主機能として,ボタンサイズを大きくし,青色(Turquoise)で着色した.⇒これでほぼ完成したのではないかと思う.

B面2

A面はこんな感じになった.

A面2

このトルコ石カラーのボタン2つが出てくると,「クイックスタート」というシナリオが浮上する.つまり,まず,「黙ってこのボタンを押してみてください」ということが言えるようになる.ともかく,始めることにしよう.もう一度画像の差し替えをやらなくてはならない.これが結構手間の掛かるところだ…

予備機で走らせていたVerification Testで,Verification Failedが出ている.何が起こったのだろう…今日はもう飲んでしまったので無理だ.明日,見ることにしよう.