月: 2022年1月

AYANETにパスワード変更の依頼を出して，メールを往復している．

現在　管理サーバーメンテナンス中にて設定変更にお時間をいただいております。

作業完了後に改めて連絡させていただきます。

ということなので，近日中に片がつくだろう．それはそれでよいのだが，メール送信に関してはやや不審な点がある．念のため，GmailアカウントにCCしたのだが，入ってこない．2通送信して，2通とも入らなかった．別の宛先に送ったものはCCできている．ただし，送信元は同じではなかった可能性はある．AYANETに送ったのは送信元はoutlookアカウトで，別の宛先のときは，Yahooだった．outlookから送り直してみよう．通った．ということは，AYANETへの送信に限ってCCされていないということになる．

もう一つ不審な事象が起きている．「テストメール」という表題のメールが4本着信していた．すべて自己宛メールで，送信元はoutlookアカウト，宛先はGmail, Yahoo, outlook.com, outlook.jpだ．送信日時は2022/01/11の午前3:18～3:32の間の14分間だが，20日も前に送信したメールがいま頃届くということはあり得ないから，日付は改ざんされているものと思っていいだろう．このメールは自己宛メールだが，わたしが発信したものでないことはその本文から明らかだ．

こんにちは。(*^▽^*)

お元気ですか？

わたしは基本的に絵文字を使わないので，こんなメールを書いているはずがない．このメールのメッセージはおそらく，「あなたのメールアカウントのパスワードは盗まれています」ということではないだろうか？つまり，outlook.jpのアカウントがハックされているということになる．多分，送信元まで偽装するということは可能なので，このメールが100%その証拠になるという訳ではないが，その可能性は十分高いと考えなくてはならない．タイミング的に言うとAYANETとの応答と重なってくるところが微妙なところだ．というのは，2011年に当時の担当者のK氏という人物に以下のようなメールを送っているからだ．

> おはようございます。
返信ありがとうございます．
> 下記の件、こちら側の問題ではないと思われます。
そうですか？８月頃督促を受けていた時期に起きていた
事象とかなり似ているところからもしやと思ったのですが．
> 再度、ご点検を
あのときは，入金した時点でぴたりと止まりました．
まったくの偶然だったのかも知れませんが・・・

AYANETはサーバーの運用をどこか外部に丸投げしていると思われるので，その会社の性格は不明だが，信頼度はあまり高くない．上記ではoutlook.jpのアドレスがハックされているという可能性を指摘しているが，実際にはもっと広範である可能性もある．わたしのメールアカウントは必ずしも非公開というものではないので，いろいろな情報を突き合わせれば現在使っているメールアカウントを網羅的に知ることは不可能ではないと思われるが，それも相当な手間の掛かる作業だ．特に，outlook.comというアカウントは基本的にすでに使用停止しているので，それまで知っているというのは尋常なことではない．わたしのパスワードリストが流出しているのだろうか？

パスワードリストはストレージに格納されているが，バックアップとしてあちこちに分散している可能性がある．点検しておく必要がありそうだ．outlook.comを廃止したのは少なくとも2018年以前の相当昔の話だ．Yahooを使い始めたのはoutlook.comからoutlook.jpに切り替えた時期に重なっているのではないかと思うが，いずれ2018年頃と思われる．ネットを再開した時期と言ってよいはずだ．この時期には異常事象が発生しているので，それと同根と考えて間違いないのではないだろうか？というか，昨日のカスペルスキーの警告が本物なら，すでに開発機自体が乗っ取られているということになる…

そこから始めるしかないような気がする．リカバリディスクは作ってあったろうか？作ってないのではないか？lenovoはDドライブにOSイメージを持っていたので，比較的簡単にOSの再インストールができたが，このマシンではまだやったことがないような気がする．⇒リカバリディスクは一応作ってあった．2020/10/14という日付だ．このマシンはネット再開時に購入しているはずなので，2020年まで戻せば回復できる可能性はある．ともかくそれをやるしかないのではないだろうか？ちょっと顔を洗ってから考えることにしよう．

上の「テストメール」で一つ興味深い点がある．Yahooアカウント向けのメールの宛先名が「那須ミチロウ」となっている点だ．わたしもごく稀に下の名前をミチロウと書くことはあるが，よほどのことがないとそのような書き方はしない．わたしのことを知らない人物は通常わたしの名前を「ミチオ」と呼び間違えることが多いので，それをミチロウと表記できるのは距離的にわたしにかなり近い可能性がある．つまり，わたしを直接知っている人物というプロフィールが浮上してくる．

outlook.jpのパスワードは比較的最近変更しているのだが，ともかく変えておこう．⇒パスワードを変更して，マイクロソフトから「Microsoft アカウントのパスワードの変更」というメールが届いた．しかし，これはおかしくないだろうか？メーラはまだパスワード変更を知らない（パスワード変更していない）のに受信できているというのは？⇒送信もできてしまった．腑に落ちない．Thunderbirdで保存しているパスワードは変更前のものだ．Thunderbirdはこのパスワードを使っているはずだから，古いパスワードが通用していることになる．これではパスワードを変更した意味がない．

どうもマイクロソフトはパスワードを廃止してスマホで認証するという方式に誘導しようとしているのではないか？

Microsoft アカウント
パスワードが変更されました
たった今、Microsoft アカウント ba**s@outlook.jp のパスワードが変更されました。
お客様がこれを実行した場合は、このメールを無視しても問題ありません。
お客様がこれを実行していない場合、お使いのアカウントが不正に使われています。以下の手順に従ってください。
パスワードをリセットします。  
アカウントの安全性を高める方法をご確認ください。 
セキュリティ通知を受け取る場所を変更するには、ここをクリックしてください。
サービスのご利用ありがとうございます。

パスワードをリセットして古いパスワードが削除されるのならよいが，スマホ認証を強制されるのはゴメンだ．多分マイクロソフトメールなどでないと受信できないようになると思う．あるいは，マイクロソフトのルールではマイクロソフトアカウントでログインしているデバイスではメールのパスワード検査をパスしているということなのだろうか？ともかくパスワードのリセットというのを試してみる．⇒パスワードのリセットというのは新しいパスワードを入力するというだけなので，前回やったのと手続き的にはまったく同じだ．多分結果は同じことになるだろう．つまり，通用するパスワードがさらに増殖するということになるのではないか？マイクロソフトは72日ごとにパスワードを変更することを推奨しているが，まったく意味がない．

outlookのパスワードはマイクロソフトアカウントと連動していると考えられるので，古いパスワードでログインできるかどうかを試してみよう．他のマシンでログインすればよいのではないか？開発機で再起動してログインしてみた．ログインは通ったが，その後（ネットに接続するまでの時間が経過した後）「お使いのアカウントの一部に注意が必要です」の警告が出た．パスワードの不一致が検出されていることを意味する．ただし，これは警告で無視すれば通常通りの運用が可能だ．パスワードを再設定して正常に戻った．

このマシンからもログアウトしてサインインし直してみよう．⇒問題なくログインできたが，再起動してログインし直すとやはり，「お使いのアカウントの一部に注意が必要です」という赤字のメッセージが出るようになる．新しいパスワードを入力すれば正常に戻ることは確かだが，その前にメールの送受信がどうなっているか見ておこう．⇒Thunderbirdでログインに失敗しました，が出た．この動作はノーマルだが，ということは，マイクロソフトはメールの送受信まで仕切っているということになる．いや，よく分からないが前回はメールサーバーとの間でリンクが確立していたため，パスワードと関わりなく送受信できていたという可能性も考えられる．

いずれにしても，PCへのログインは古いパスワードでOKということだけは言える．これはあまりよい設計とは言えないだろう．開発機にアクセスするためにはログインする必要があるが，そのためにはこの機械の前に座る必要がある．ただし，リモートアクセスという手があるので，もしそれが可能ならパスワードでプロテクトなどザルだということになる．いや，リモートアクセスはWindows 10 PRO以上でなくてはサポートされない．このマシンは幸いWindows 10 HOMEなのでリモートアクセスはできない．

Chrome Remote Accessというのもある．Googleが提供するサービスだ．Chrome Remote Desktopにアクセスすると，履歴として2019/8/5にFireBirdにアクセスしたという記録が残っている．3年前だがもしかしたらそのようなことをやっていた可能性はある．リモートアクセスを許すためには，そのマシンでセットアップを実行する必要がある．また，リモートアクセスコードを相手のマシンに送る必要がある．しかし，最終的には外部からそのマシンを完全に遮断する以外の方法はないと考えた方がよい．整理してみよう．

1. 外部からoutlook.jpのメールサーバを経由したメールが送られてきている．送信者はoutlook.comのメールアカウントを知っている．これはかなり昔マイクロソフトアカウントにサインインするために作ったもので，それ以外の用途ではほとんど使われていない．
2. また，この送信者はミチロウというカタカナ表記を知っている．これはごく親しい友だちへのメールにしか使わない署名だ．
3. 予備機で発生した「zzzz…居眠り事件」は予備機がハッキングされていることの証拠と見るべきだろう
4. 開発機でゼルコバの木のEXEがカスペルスキーによって4件駆除された．これは開発機がハッキングされている可能性が極めて高いことを示す証拠と見られる
5. AYANETへの送信メールでCCが実行されなかった．この事象は複数回発生している．他のアカウントからの送信，他のアカウントへの送信ではこのような事象は発生しない
6. ownCloudのフォルダに格納したファイルが3本削除されて，ゴミ箱に落ちていた．ownCloudのパスワードが盗まれている可能性が高い

対処策として以下を実行した/する．

1. 開発機でEXEを駆除し，完全スキャンを実施⇒除外リストをクリアして完全スキャンを再試行
2. ownCloudのパスワード変更
3. outlook.jpのパスワード変更
4. Windows のリモートデスクトップアクセス，Chromeのリモートデスクトップサービスをチェックした．リモートデスクトップでアクセスされる状態にはなっていないが…
5. 予備機で完全スキャンを実施⇒完了
6. フロントエンド機で完全スキャンを実施⇒完了
7. カスペルスキーの「Microsoft Windows Operating Systemの保護されたトラフィックは監視されていません」という警告⇒以下の方法で対処
   カスペルスキーのルート証明書を Mozilla Firefox 及び Thunderbird に追加する方法（個人向け製品）
   Kaspersky / カスペルスキー 総合176
8. カスペルスキーはownCloudとWordPressのログインIDを区別できない⇒ownCloudに別ユーザを登録してそのIDでログインするようにする

またownCloudを壊された！今度はフォルダごと消えている．ゴミ箱には何も入っていない．これはownCloudのバグである可能性がある．なぜかと言うと，新しいIDを登録したときに，ぐるぐるが回ったままいつまで経っても抜けてこないのでブラウザを落としてログインし直すということになったからだ．かなり始末が悪い．

ローカルフォルダには当然残っている．同期できるだろうか？どうもかなりできが悪い感じだ．ローカルでは「同期成功」と表示されているのに，リモートには入ってこない．どうもこのクラウドは完全に壊れてしまったようだ．ローカルで一旦ファイルを全部削除してもう一度アップロードし直したが，入ってこない．管理者babalaboでログインすると見える．babalabosでは見えない．というか，中身が入っていないので削除している．babalabosは管理者として登録しているのに，すべてのファイルが見えないなどということがあるのだろうか？どうも，訳の分からないシステムだ．

ともかく，公開リンクを作って再公開するしかない．

https://zelkova-tree.net/ownCloud/index.php/s/nxisM8bu2eMAbw5

https://zelkova-tree.net/ownCloud/index.php/s/uH9uUDEQVr1uoCr

昨夜仕掛けておいたつもりの検証テストが見当たらない．画面にはカスペルスキーの通知センターからの警告が表示されている．

削除を選択したら，「特別な削除」というのを始めた．マウスウィズアウトボーダーズがエラーメッセージを表示している．そのあと，もう一つパネルがでて再起動になった．再起動後ログインすると完全スキャンが始まった．残り時間は計算中でまだ出てこない．開発機は滅多にネットに繋がないようにしているが，昨日はしばらく接続していた時間があり，そのあと所内LAN（無線）に繋ぎ変えたつもりだが，どちらも切れていた．画面はスタンバイ状態になっていた（と思うが）が，ログインしているので，もしかしたらリブートしていた可能性もある．

ゼルコバの木の開発用フォルダ内のEXEがカスペルスキーにウィルスと判定されることは稀にある．今回は4つのEXEが駆除の対象になっていて，その中にZEKOVA – コピーというフォルダが含まれている．しかし，再起動後に確認したらそのようなフォルダは存在していない．ZEKOVA – コピーというフォルダが残っているとしたら，始業時のバックアップでフォルダをリネームし忘れたということになるのだが…カスペルスキーは通常フォルダごと削除ということはしないはずなので，どうもその辺りがよく分からない．

テストを仕掛けたつもりでやっていなかったという可能性はゼロではない．昨日は椅子の上で寝落ちしてしまったので，仕掛ける前に寝てしまった可能性は高いような気がする．始業時のバックアップでフォルダをリネームし忘れするということは経験したことがないが，ゼルコバの木とコラッツ関係をそれぞれバックアップしている上，昨日はいろいろとやることが立て込んでいたので忘れてしまった可能性もかなり高い．

マウスウィズアウトボーダーズを使うためには複数のマシンをLANで接続している必要があるが，相手方のフロントエンド機は常時ネットに接続しているので，手間を省くために開発機側でWifi（スマホのテザリング）につなぐことが最近増えている．開発機から直接ネットにアクセスできるといろいろやり易くなるため最近は（開発機のネットからの隔離が）少しルーズになっている傾向がある．

一昨日も寝落ちしているが，予備機で異常が発生していた．スクショは取れなかったが，画面に見たことのない黒い画面が出ていて，意味不明なテキストが広がり，警告メッセージが表示されていた．テキストの頭はZZZZZZZでその後の文字は覚えていないが，同じ文字が連続的に入力されたような状態になっていて，警告の内容もよく覚えていないが，「居眠りのようなキーワードで検索してみたらどうか？」のような感じのメッセージだった（爆）．一昨日（昨日の朝）はデスク上に足を投げ出した格好で寝ていたので，キーボードに触れて文字列を連続入力した状態になっていた可能性は排除できない．目覚めた直後の足の位置は確認しているが，キーボードから離れていたことは確かなのだが…

通常の設定ではスタンバイに入るまでの時間はかなり短く，それより短い時間でモニターの電源を落とすように設定しているが，検証テストが止まってしまうので，現在はどのマシンもスタンバイに入らないという設定になっている．そのスキを狙われた可能性は否定できない．

ようやく残り時間が表示された．あと2時間掛かる．これまでにも開発フォルダのバックアップ中のEXEがウィルスと認定されたことはあるが，「そんなことはないはずだ」と考えて，おそらくカスペルスキーの誤動作というか，過剰反応とみなしていたのだが，そうではなかったと見たほうがよいのではないか？ということは，これまでにも侵入されていた可能性が排除できないということになるのだが…現象的に見ると，やはりネットに繋ぎっぱなし，常時ランニング状態というのはよくないような気がする．少なくとも開発機はネットから完全に切断したクリーンルーム状態を維持しなくてはならないのではないだろうか？元々そういう原則で運用してきたのだが，明らかに最近はタガが緩んできている．

かなりまずい事態になってきた．ownCloudのコラッツ関係フォルダに置いたファイルが2つとも消えている．ごみ箱に入っていた．Collatz Tree Generator.zipは13時間前，CollatzTreeGeneratorManual.PDFも13時間前に削除されている．13時間前に削除されたファイルがもう1本，Collatz Tree Generator V1.1.2.zip．復元という操作があるのでやってみた．戻ってきた．共有中の公開リンクをチェックしてみよう．

https://zelkova-tree.net/ownCloud/index.php/s/mn77KXxhqUh1j0y
https://zelkova-tree.net/ownCloud/index.php/s/V9hlAIxxOR5MKyH

どちらも昨日設定したものだ．これらの原因をすべてわたしの「ボケ」に帰するというのはかなり無理がある．だとしたら，「標的型攻撃」の対象になっていると認識するしかないのではないか？これまでにも何度も「標的」になってきたことは間違いないので，特に不可解な現象というのでもない．問題は，どう対処すべきか？ということに尽きる．ownCloudは自分でサイトを管理するよりはずっと安全なのだろうと思い込んできたが，そういうものでもないらしい．ownCloudのソフトのできはかなり未熟なので，何かセキュリティ上のホールが存在する可能性はかなり高そうだ．ともかくパスワードをチェックしておこう．

開発機で走らせておいたタスクがまた落ちている…いや，あった．アイコンをスパイラルに変えたのはよいが，あまり目立たない（見慣れていない）ので見落としてしまった．1日＋6時間48分走って，69%，残り時間は1日を切って13時間34分になった．予備機の方は8日＋3時間走って，82%だ．時間の経つのは速いような遅いような…

コラッツ木構造図に含まれてた漸化式の間違いに関する手当はまだ収束していない．コラッツ木生成論理はすでに修正を入れてあるが，それ以外の4本の処理は多分独立に計算しているので，以前の論理がそのまま使われているはずだ．これらをすべて新しい式に書き換えなくてはならない．モヒティにはこれら2つの漸化式が等価であることを証明するように頼んであるが，やはりやる気はないようだ…自分の昔の思いつきに固着していて，まったく進歩していない…

実際，ネット上で「コラッツ予想はブラックホール」で検索してみると，山のような記事がヒットする．もちろん，その中にモヒティの名前は出てこない．つまり，モヒティの「インスピレーション」もそれほどユニークなものではなかったというのが現実のようだ…モヒティとのやりとりはすべてバックアップしておきたいので，一段落したら，テント村に置いた記事も更新しておかなくてはならない．

この修正は遅くとも今日中には片付くと思われるので，バージョン番号とリリース日付を更新してから始めることにする．漸化式が2つある．①N(k) = 4N(k-1)+1，②N(k)＝(４M(k-1)-1)/3 : M(k)=4M(k-1)だ．②式で使っているMという変数は奇数と接続する偶数を表している．①式にはMという値は現れない．つまり，この式は奇数演算だけで完結している．我々の（正則）コラッツ木には奇数ノードしか含まれないので，①式を使うのが妥当である．

※2022/01/31 ②式は間違え易いので下記のように修正した
②N(k)＝(M(k)-1)/3 : M(k+1)=4M(k)

どちらを使ってもプログラムは正しい結果を出しているので，基本的に等価（同値）であると考えられるが，そのことを証明しておく必要がある．モヒティにはこの証明を課題として与えているのだが，まぁ，やる気がないのは明らかなので自分で回答することにしよう．数学物理etc（談話室）にコメントを追加して，②式を①式で書き換えたバージョンをASAPリリースすると予告した．

漸化式はコラッツ木上の奇数ノードNの子ノードをN(i)としたとき，N(k)の値をN(k-1)から導くための等式だ．①式の場合も，②式の場合も，N(1)=(N*2^c-1)/3となる．②式ではM=N*2^cとした上で，Mに関する漸化式M(k)=4M(k-1)を使って，間接的にN(k)の値を計算している．まず，①式を展開して，

N(k) = 4N(k-1)+1
4N(k-1) = 4(4N(k-2)+1) = 4^2N(k-2)+4
4^2N(k-2) = 4^2(4N(k-3)+1) = 4^3N(k-3)+4^2
:
4^(k-2)N(2) = 4^(k-2)(4N(1)+1) = 4^(k-1)N(1)+4^(k-2)
————————————————　両辺の和を取って
N(k) = 1 + 4 + 4^2 + …+ 4^(k-2) + 4^(k-1)N(1)
   = ((4^(k-1)) – 1) / (4 – 1) + 4^(k-1)(N*2^c – 1) / 3
  = ((4^(k-1)) – 1) / 3 + 4^(k-1)(N*2^c – 1)  / 3
        = ((4^(k-1)) – 1 + 4^(k-1)(N*2^c) – (4^(k-1))) / 3
        = (4^(k-1)N*2^c – 1) / 3 ーーーーー（Ａ）

ここで，累乗の和を求めるのに，∑r^(i – 1): i = 1 to n = (r^n – 1) / (r – 1)の公式を用いた．次に，②式のM(k)=4M(k-1)，M=N*2^cから

M(1) = N*2^c
M(2) = 4M(1)
:
M(k-1) = 4M(k-2)
M(k) = 4M(k-1)
————————————————　両辺の積を取って
M(1)M(2)…M(k-1)M(k) = 4^(k-1)N*2^c*M(1)M(2)…M(k-1)
M(k) = 4^(k-1)N*2^c

N(k)＝(M(k)-1)/3
       = (4^(k-1)N*2^c – 1) / 3 ーーーーー（B）

以上により，（A）式と（B）式は等しい．よって，①式と②式は等価（同値）である．つまり，偶数ノードを介さなくともコラッツ木を構成可能であることが示された．言い換えれば，コラッツ木では奇数ノードNと最右子ノードの値を決めている2の累乗値がわかれば，枝番号bを与えるだけで任意の子ノードの値を決定することができる．

cの値にはやや非決定的なところがあるが，それ以外のノードはすべて決定性で計算可能であるところが注目すべき点である．最右子ノードの値は親ノードの値よりも小さくなる場合があり得るが，同じ兄弟ノードの値は左に進むに従い単調に増加することも見逃せない．

実装コードとしては，①最初にMを計算してN(k)＝(４M(k-1)-1)/3で求める方式，②最初にN(1)を計算して，N(k) = 4N(k-1)+1で逐次計算する方式，③最初にN(1)を計算して，事後はN(k)=(4^(k-1)*(3N(1) +1)-1)/3で計算する方式など考えられるが，計算効率的には②が最適と考えられるのでこれを用いることにしよう．これはコラッツ木生成論理ですでに実装済みのアルゴリズムである．

▲2^24で検証テストを実行中，STOPを掛けたらVerificationTestのEXITFUNNINGでODD=0で停止した．Odd number には18177が入っている．⇒再現できないが，確かに動作的におかしいところがある．Stopで止まったとき，Odd numberの値が小さくなることがある．5という値が入ることが多い．この値は，GetTheNumberで更新している．VerificationTestでは内部変数のODDで更新している．検証テスト中はGetTheNumberでは更新しないようにしたが，現象は収まらない．UpdateTreeHeightでも更新しているが，RunFlagが立っているときは更新していない．UpdateTreeHeight2でも同じだ．

Tree height=1 @ 5という表示が出ている．確かにUpdateTreeHeightないし，UpdateTreeHeight2の誤動作と思われる．UpdateTreeHeight2はDumpSuccessorsで呼ばれるだけなので無関係だろう．これは結構難しいかもしれない．Verification Test中DoEventsを実行してイベントループを回しているが，Stopボタンが押されたとき，どこにいるかは予測できない．一番おかしいのは，TreeHeight2の値がStopで小さくなるという点だ．⇒何とか収まったようだ．⇒少し走らせてみよう．Verification TestはGet the SequenceとGet the Numberの相互検証になっているので，これが走ればまず間違いない．

マニュアルの内容には変更はないが，参照しているモジュールのバージョンだけ更新しておこう．B面の処理ではCSVファイルを出力しないようになっているが，A面と同じ仕様にしてもよいのではないか？出力をファイルに取ってあれば，動作を比較したりするときにも有利だ．単純に出力フレームに出しているダンプをファイルに落とすだけでよいのではないか？Verificationでは確かに出力フレームには進行状況しか表示されていないのだが…I/Oフレームに出している枝番号リストを保存するという考え方もあるが，むしろ隣接リストを出力する方が応用が効くのではないだろうか？まぁ，これはペンディングということにしておこう．

Verificationに仕掛けたタスクは約1時間で終わる．それが終わったら，少し大きめのサンプルをZTで出力して目視検査することにしよう．

最新版ZIPとPDFをクラウドにアップロードしたが，ダブってしまったので古い方を削除したら元のリンクからアクセスできないようになってしまった．新しい公開リンクを発行した．

https://zelkova-tree.net/ownCloud/index.php/s/mn77KXxhqUh1j0y

https://zelkova-tree.net/ownCloud/index.php/s/V9hlAIxxOR5MKyH

開発機で実行していた検証テストが完了している．

Start From 1275069537 up to 1811940447

丸1日＋18時間42秒でトータルノード数は268435456だ．サイトの表示を更新しておこう．ログを更新しようとしたら，メモリ不足エラーになってしまった．多分再起動が一番早いと思われるのだが…ｃドライブの空き容量はなんと0バイトになっている！初めて見た．削除できる一時ファイルは10.7MBしかない．

開発機のテストは13時間30分経過して，残り時間1日＋14時間，進捗は26%だが定速で走っている．予備機の方は7時間40分走って，74.2%だ．マニュアルにもう少し手を入れる必要がある．Tab Aの”Screen Components on tab A”はヘッダのはずだが，本体テキストになってしまっているとか，細かい直しがまだ少しある．これは改めて告知せずに，黙って修正でよいだろう．マニュアルにもバージョン番号を入れた方がよいのではないだろうか？⇒マニュアルのタイトルにエディション番号を記載するようにした．

結構あちこち直しが入った．当初は画面上の要素名はすべて大文字で始まるようにしていたのだが，やや大げさなので，オブジェクトを指す場合のみ大文字とし，変数名などは本文の中では小文字で始めるように書き換えた．大文字にする利点は冠詞を付けなくても通るという点にあるが，小文字にした場合にどうか？というところでは多少のブレがある．ほとんどの変数名は小文字にした場合も太字でかつイタリックになっているので，冠詞を省いてもよいのではないか？というのが当方のポジションだ．まぁ，文体が多少古臭いのはやむを得ない．これが学校の英語教育で教わった英語なのだから…

さて，またこれをアップロードしなくてはならない．アドレスは変えなくても済むようになっているはずなので，①PDFをアップする，②ZIPにPDFを同梱してアップするの2ステップで片付くはずだ．やってみよう．ownCloudのクライアントをインストールしてあるので，どちらもローカルのファイル操作だけでよいはずだ．⇒問題なさそうだ．

さて，もう一つやらなくてはならないことがある．モヒティのスレッドに投稿したコラッツ木構造図だ．だいぶ奥の方に落ちてしまっているのでアクセスが難しい．というか，テント村のトップ記事にリンクを置いていたはずだ．いや，トップ記事には入っていないが，その前の長文記事の中にあるはずだ．⇒出てきた．

開発機で実行していたテストは昨日のうちに落ちていた．うっかり閉じてしまったのだろう．予備機のテストは続いている．6日＋52分で63.2%．少なくともあと4日は掛かる形勢だ．予備機でもカスペルスキーのパスワードマネージャのアンロック画面が出ていて，そのあとに「個人情報の商用利用」の許諾を求めるメッセージが出た．拒否したのに「おめでとうございます…」のようなことを言っているのが気になる．ボタンを押し間違えてはいないと思うが，この種のボタンは一度許諾すると戻せない（のが普通だ）．

正則コラッツ木生成機の画面要素はすでに確定しているので，あとはマニュアルの図版を差し替えるだけになっている．それほど時間は掛からないので，ほどなく公開の段取りに入ることになるだろう．公開後も差し替えができるようにしておくので，多少のところは後日修正もできるだろう．テント村の訪問者がじわじわと増加傾向にある．昨日の訪問者数は64人で，いまの時刻午前四時ですでに訪問者8人，うち2人がオンライン中になっているので，海外からのアクセスが出てきている可能性はある．現在公開しているCollatz Tree Generator V.1.04は少なくとも数本はダウンロードされている．

仮に今日中に最新版＋マニュアルが公開できたとして，その後に日本語版マニュアルを作るかどうか？が問題だ．グーグル翻訳である程度のことはできると思うのだが，読者の便を考えれば作った方がよいのは当然だろうとは思うのだが…まぁ，これはあとから考えることにしよう．アイコンを作り変えるという話もある．現在は応急的にゼルコバの木ベータ時代の切り株アイコンを使っているのだが…⇒アイコンは作るとしても間に合わない．図版もすべて差し替えになってしまうし…

マニュアルの図版でとんでもない間違いが見つかった．一番肝心なコラッツ木構造図だ．k番目の子ノードの番号を与える漸化式を，

N(k) = 4N(k-1) – 1

としているが，これはN(k) = 4N(k-1) + 1の明らかな誤りだ．誰も指摘してくれていないので，読まれていないことは間違いないが…本体プログラムではこの式を使わず，

N(k)＝(４M(k-1)-1)/3 : M(k)=4M(k-1)

のような式を使っているので，この間違いは発現していない．まず，この図版を修正し，かつ漸化式をN(k) = 4N(k-1) + 1に変えて動作することを確認しておく必要がある．モハティのスレッドの図版も差し替える必要がある．しかし，これは最新版＋マニュアルの公開の手配が整ってからやることにする．

▲Collatz Tree 3-8-766.zelをダブルクリックで起動して，フォントサイズゼロというエラーが出た．

アプリを起動しておいて，ファイル→開くではエラーは起きない．ダブルクリックで起動したときに固有の現象のようだ．

正則コラッツ木生成機のCollatzTreeStructureに上記の修正を入れて動作を確認した．つまり，「漸化式をN(k) = 4N(k-1) + 1に変えて動作することを確認」できた．この方が論理が単純なものになるので，より優れていると言える．プログラムの修正はこれまでなので，図版を作り直すことにする．コラッツ木構造図はゼルコバの木で描画しているので，原図を探してみよう．フォーラムに投稿された画像の日付は2021/12/17だ．⇒どこにも残っていない．簡単な図なので作ってみよう．⇒バックアップに入っていた．見つからなかったのは，このあとフロントエンド機を変えているためだ．

▲コラッツ木構造.zelを保存しようとして，PAGESETUP::GetPageCountのエラーになった．

とりあえず，マニュアルに関しては図版を差し替えるだけになった．アイコンにトライしてみたが，なかなか難しい．ネットでピッタリの絵柄を見つけたので使わせてもらうことにした．ありがたいことに無料だ．

無料なのはいいが，フォトメディアアドオンというアプリのインストールが勝手に始まっている．もしかしたら，どこかのボタンを押しているのかもしれないが…こっちはドライブが逼迫しているので勘弁してほしい…エクスプローラのプレビューに画像が表示されないので，再起動したところだ…（再起動すると多少緩和して表示できるようになる）

一つ問題が出てきた．Export Zelkova Tree CSVがオンになっていると，ゼルコバの木形式CSVファイルが出力されるようになっている．全部で4種類のファイルが出力されていて，CollatzNumber.csvという名前のファイルは，Get the Numberで出力されることになっているが，Verification Testでも同じ名前のファイルが出力されている．本来Verification Testではファイルに保存しないという仕様だったが，内部でGet the Numberが走っているため，副次的に生成されている．

もし，Verification TestでもCSV出力が取れるということになれば，それはそれで面白いのだが，現在の動作では，最後の1点についてのグラフデータしか出力されていない．これはほとんど意味がないので，全面的に出力しないようにするか，ないし，全点（と言ってもゼルコバの木が読み込める限度内ではあるが）取れるようにすべきだろう．Verification Testのテスト結果をゼルコバの木で可視化できるとかなり面白いのだが，可能だろうか？

このためには，隣接リストファイルをゼルコバの木で直接読み込めるようにする必要がある．Verification Testで出力されるグラフというのはすべて「鎖」なので，不可能ではないような気もするが，ゼルコバの木を改変しないでそれができるかどうかはやや疑問だ．というのは，どうしても交叉が発生する可能性があり，特に1はすべての鎖に含まれるので，現行のゼルコバの木の論理では別人物として登録されるのは避けられないような気がする．いずれにしても，いま直ちに実装するというのは困難なので，Verification Testでは何も出力しないようにしておくしかないだろう．⇒対処した．

▲CollatzTree.csvをインポートしようとして，ImportTablefuncのエラーが出た．

あまり見たことのないエラーだ．そのあと，ファイルのオープンに失敗しましたなどのエラーが続く．どうもこのCSVファイルはでき損なっているのではないか？プレーンCSVを取ってみよう．これは問題なさそうだ．⇒ゼルコバ形式ファイルを出力していないように見える．やはりそうだ．どこか壊してしまったのだろうか？mmm…確かにやり過ぎていたかもしれない…

ExportZelkovCsvでWorkingでないときは無動作で抜けるようになっていた．この関数は汎用でゼルコバCSV出力では必ず使われるものだから，ここで抜けるというのは間違っている．ゼルコバの木出力しないときは，プレーンCSVを出力するようになっているので，それをインポートしたゼルコバの木が「ファイルのオープンに失敗」というのは正しい動作だ．いや，まだ少しおかしい．CSVファイルが消えてしまった．⇒拡張ディスプレィの方に出ていた．まったく問題ない．

▲出力枠のテキストを切り詰めるとき，行単位で削るようにしているはずだが，うまく動作していない．最初の一行が半端なところから始まっている．⇒テキストがMAXDUMPTEXTより短いときは切り詰めないようになっているが，等号が成立したため無処理になっていた．等号の場合も処理するようにした．

▲プレーンCSVを取ったあと，ゼルコバの木CSVに切り替えて例外が発生して，異常終了した．⇒これはLcalcを開いてファイルがロックされていたためと思われる．フラグは立っているが，ストリームがNothingであるため，Closeしようとして例外が発生している．⇒対処した．

公開版のバージョンをV1.1.4とし，リリース日付も2022-01-27に改めておこう．まず，これをownCloudにアップロードして場所取りをしておこう．⇒クラウド上にすでにCollatz Tree Generatorというフォルダは存在する．一番最初に作ったものだが，上書きしてしまおう．⇒公開リンクは一つのファイルに対して複数作れる．一応，新しいリンクを作っておくことにする．

https://zelkova-tree.net/ownCloud/index.php/s/hp1QwdFxv3HLez1

今度はLibreWriterから直接印刷してみる．⇒レイアウトで失敗している．18ページのところが，19ページになってしまった．紙とインクがもったない…仕上がりはほぼ同じだ．Libreの方がPDFより気持ちページが縦長になっているが，まぁ，収まっている．完璧とは言えないにしても，ほぼ満足できるものになった．マニュアルも仕上がったのでクラウドにアップすることにしよう．

マニュアルの公開リンク：https://zelkova-tree.net/ownCloud/index.php/s/Tsgt6t10A3NI7Uz

まず，テント村のトップページに告知を入れておこう．⇒片付いた．パッケージにPDFを詰め込んでダウンロードできるようにした．オンラインマニュアルも開くことができる．これで万端整ったと言えるだろう．別バージョンが3つアップされているが，すべて27日以内に期限切れとなるように編集した．

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

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

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

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

「It’s lonely here! Your sensitive PDFs 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の画面はこれで決まりとしたい．

これに合わせてプログラムを書き換える必要がある．⇒終わった．あとは図版を張り替えるだけだ．今後のこともあるので，バージョンに関わりなく同じファイル名でダウンロードできるようにしておきたい．パッケージに入っている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に書き換えて，４のリンクを挿入する

問題は，マニュアル本文の中に４の公開リンクへの参照が含まれていることだ．従って，まず，マニュアルを同梱しないバージョンのパッケージを作成し，それを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%というところだ．１日当たりの進捗率は前者が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が作られていなかったような気がするのだが…⇒問題なく作られている．３年前のわたしはまだ若かった！いまでは小石一つにでもつまずいてしまうほど老いぼれてしまったよ…バージョンの更新はもう少し込み入ったところがあるのだが，外からは見えないところなのでここまででとりあえずパスすることにしよう．さて，何をしようとしていたところだったのか？何かサンプルを作るつもりだったのだろうか？

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

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

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ページ．あとは細かい手直しといろいろな調整を行うだけになった．明日くらいにはリリースできるだろう．

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

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

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

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

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

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

開発機で走らせている検証テストは現在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．書き込みは実行されているのだが，自分自身が自分の親になっているようだ．番号の割り付けが悪いのだろうか？しかし，ここでだけそのようなことが起こるという理由が分からない．