投稿者: babalabo

最近は就寝前にPCの電源を落とすようにしている．いまテストが走っているのは予備機だけなので他の2台は始業時に電源を入れなくてはならない．おかしなことというのは夜分に起こることが多いので，面倒だがこれを習慣化するしかない．予備機の検証テストは17時間24分経過して，78%，残り時間4時間55分だ．昨日の完全スキャンでは検知ゼロで完了しているが，その後リブートして複数のEXEがまた警告を受ける状態になった．完全スキャンの直後にまたぶり返すというのも妙な話だが，除外リストを完全にクリアしているため，ファイルのハッシュ値が変化すると警告を出すようになっているようだ．

ということは，これまで大騒ぎしてきた危険EXEの検出というのもそういうものだったという可能性が高くなった．リビルドすればハッシュ値は当然変化するので，除外リストに登録していない限り脅威と認知されることになる．通常は開発環境以外ではリビルドということは行わないのだが（そうしないとバックアップの内容が変化してしまう）最近はその辺りもかなりルーズになっていて，バックアップフォルダの中で新たにビルドを実行してしまうようなケースが増えている．これも厳に慎むべきだろう．これを徹底するには，バックアップフォルダをRD ONLYにしておくことも考えられる．

さて，Collatz Tree Generatorも仕上がって一息ついたところだが，最後の関門を突破するためには，まだやることが相当残っている．ともかく，Eldest Sons Treeの生成機能をCollatz Tree Generatorに実装しなくてはならない．Eldest Sons Treeというのは，Collatz Core Treeの別名で「コラッツ数」と呼ばれる（呼んでいる）ノードだけから構成される正則木だ．仮にどこかに類似研究があったとしてもこれができれば，完全に振り切ることができると思う．このグラフでは通常のコラッツ木では必ず行き止まりの葉になるような3の倍数ノードがコラッツ数になって後続ノードを持つようになる．

このような軌道はコラッツ数列には絶対に現れないある種の地下トンネルのようなもので，おそらくこれに気づく人はいないと思う．モヒティはどこまで理解しているのか分からないがこの点を指摘したコメントにいいねを付けているので多分わかったのではないかと思う．なぜコラッツ問題がほとんどランダムなカオス状態に見えてしまうのか？という原因はここにある．このトンネルを通れば起点の1に到達する放射状の道路が完備しているのに，このところで別のニセの経路を提示されどこまでも迷路をさ迷うようなことになってしまっているのだろう．

通常のコラッツ正則木とコラッツ核木を目視で比較すると，①次数が1小さくなり，②（ノード1を度外視して）高さも1減じるようなことになっているように見える．多分これはもっと大きなサンプルでも変わらないはずだ．つまり，コラッツ核木はコラッツ正則木を垂直と水平の両方向で圧縮したものと考えられる．コラッツ木構造の整合性はすでに確認されているが，コラッツ核木構造はどういうことになるのだろう？コラッツ木構造は親子関係だけを規定するものになっているが，コラッツ核木では複数の親ノードを1個のノードに集約しているのでより横断的な計算が必要になってくる．計算式はそれほど複雑なものにはならないはずだが，見通しのいいものになるかどうかは未知数だ．

上記のような理由でコラッツ核木のルートは5であるとしてよいと思う．正則コラッツ木生成画面にチェックボックスを設けて，コラッツ正則木とコラッツ核木を切り替え，CollatzTreeStructureとCollatzCoreStructureを呼び分けるようにする．手順を考えてみよう．正則木で最初の最右ノードを取得するところまではまったく同じでよいはずだ．次のループでは最右ノードから左にノードをD個生成しているが，ここがやや異なるものになる．出力されるのは子ノードではなく，孫ノードでなくてはならない．しかし，そうなると一段処理するたびに一段分消えてしまうので，呼び出し方を変える必要があるのではないか？つまり，本人ノードではなく，本人ノードの親を基準として展開しなくてはならないのではないか？実例から見た方が早い．

ノード5の子どもを展開しようとしているとする．最初の3は（MM-1)/3で求められる．次の113というのは，5の子どもではなく，85の子どもだから，まず，85を求めなくてはならない．つまり，親1の子どもを展開し，その最右子ノードが113になる．ただし，1には5と85の間に21という3の倍数ノードもある．このノードは後続ノードを持たないので，単純に無視されなくてはならない．結構複雑なややこしい話になりそうだ．完全正則木になるのかどうかも怪しくなってきた．ともかく，5の子どもの中には直接血縁のない「傍系親族」が入ってくることは間違いない．従って，計算には本人ノードの親が指定されていなくてはならない．

その親が複数の子どもを持っている場合にはどういう動作になるのか？たとえば，3を展開する場合を考えよう．3の親は5で，3の子どもには幾人かの養子が含まれることになる．これらの養子は兄弟の子どもだから，甥姪に当たる．3は実際3の倍数だから子どもはいない．最初の子である17は実際には３の兄弟である13の子どもだ．少なくとも言えることは，3は親5のすべての孫の面倒を見る必要があるということだろう．しかし，５の直系の孫だけ見ていればよいのだろうか？３の場合は5の直系という見方でよいと思われるが，113の場合は少し異なる．

113の親は5ではなく85だ．従って，113の場合には親の85の直系の孫が受け持ち範囲になる．呼び出し時の引数には親番号が入っているが，これは必ずしも実親ではない．子ども番号から親番号を割り出すことはできるだろうか？多分それはできるだろう．コア木のノードはすべて長子ということになっているから，コラッツ写像から取得できるはずだ．イメージは大体つかめて来た…

大体動作するようになった．かなりおもしろい．これまでの正則コラッツ木では3の倍数ノードは弾かれていたが，コアコラッツ木では1を含む任意の奇数ノードをルートとする正則木を描くことができる．ただし，ルート1の核コラッツ木は，昨日公開した図のようにはならない．

一見この図はよく描画できているように見えるが，よく見ると重複がある．3の部分木が重複して表示されている．3は5の子どもであるのに，上の図では1の子どもの位置に描画されてしまっているためだ．3をルートとする図を見てみよう．これは問題ないようだ．

昨日の図では3の子どもの35と17の順位が逆転しているが，手操作で作っているので，どこかで逆順になってしまったのだろう．兄弟ノードは左が大きくなるはずなので，上の図が正しい．ルート5を見てみよう．

これがもっとも標準的な正則核コラッツ木で，3の部分木は3をルートとする木とまったく同相になっている．奇数Nから1を減じて4で割った値が奇数にならないような数をコラッツ数と呼んでいるが，核コラッツ木上のノードはすべてコラッツ数であると定義される．たとえば，13は非コラッツ数だが，13をルートとした場合，どんな図式が出力されるのか見てみよう．これは上の図で3の代わりに13が入った図になっている．

3と13の関係は正則コラッツ木では兄弟で，3は13より年長だ．13は非コラッツ数ではあるが，これはこれでよいのではないだろうか？従って，やや変則的な図式になっているのは1のケースに限定されると見てよいだろう．本来コアコラッツ木では基準ノードの下に来るのは兄弟ノードの子ども，つまり甥姪であるはずなのだが，1の場合，兄弟はいないのだから，長子の5だけが子どもの位置に入るはずのところだが，本人の兄弟というのは本人をNとしたとき，４N＋1という関係であるため，5や21, 85まどまでが兄弟として扱われるようになった結果である．

４N＋1が兄弟関係を示すとすると，5は1の子どもであると同時に兄弟でもあるということになる．実際には1には親がいないので兄弟がいるはずはないのだが…一番正しいのは1をルートとする核コラッツ木は存在しない，ないし描画しないというのが正しいような気がするが，1だけ特殊扱いして，1を仮に出力してから次の処理に移るというような例外的な扱いを取ることは不可能ではない．どちらかというと，その方が納得し易いような気もするのでそのように改めてみよう．

これでよいのではないだろうか？完全正則木と呼ぶためには5の上の1が邪魔になるのだが，1と5の特殊な関係を印象付けるためにもこの方がベターなのではないかと思う．

予備機で走らせている検証テストの残り時間は5時間43分なのでもう先が見えている．開発機で実行していたカスペルスキーの完全スキャンでは削除されていなかった5個のEXEが検出された．これらのEXEは開発用フォルダのコピーに入っているもので，手操作で簡単に削除できる性格のファイルだが，なぜかカスペルスキーは「削除できない」と考えているようだ．ともかく，今回は削除できたのでもう一度完全スキャンを仕掛けてみる．これも多分5, 6時間くらい掛かるものになるだろう．AYANETからはまだ返答が来ない．AYANETとは長い腐れ縁で，料金滞納中もサイトを維持していてくれたので恩義を感じるところもあるが，10年くらい前に解約手続きに入って，「精算」を求めたにも関わらず，なし崩しに現状維持が続いている．

一番問題なのはownCloudの信頼度と安定性だ．思ったような動作にならないところが多々あるところから推定して，どうもこのサービスは仕上がりがかなり悪いという印象だ．信頼できるかどうか？という点に関してはいまのところ評価できない．この会社の本拠は国外（多分USA）なのではないかと思われるが，その割には完成度が低いような気がする．ずっとFTPを使っていないので，いまさら面倒という気分もあるが，ownCloudが使い物にならないという結論に至れば，FTPを使って自前でサイトにアップロードするようにするしかない．自由度はこちらの方が高いのでいずれそういうことになりそうな気もする．まぁ，何か致命的なことが発生するまではしばらくこれを使うことにしよう．

一昨日は，Collatz Tree Generatorをリリースしてようやく一段落というところで久々の休日を楽しんだが，それも束の間，いろいろなトラブルに猛襲されてせっかくの休暇も台無しになってしまった．最重要な開発機は汚染の可能性が否定できないので，一度OSを再インストールしてクリーンな状態に戻すことも考えたが，現在走らせている完全テストが通ったら，そのまま継続使用することになるのではないかと思う．ただし，今後は開発機を外部接続するときには相当慎重に当たらなくてはならない．100％隔離するというのも現実的ではないが，可能な限り短時間で必ずVPNを通すようにしなくてはならない．それ以外の機器に関しては最悪OSの再インストールを覚悟して外部接続するしかないだろう．

潜伏された場合にはこの方法では対処できないが，何か症状が発現しない限り，実害はないとも言える．パスワードその他の機密情報が外部に漏れないようにするというのが最大のポイントであり，外部接続する機器のストレージにはこのような情報を残すべきではない．カスペルスキーに裏切られたら？その可能性もゼロではあり得ない．実際，つい最近カスペルスキーから「個人情報の商用利用の許諾」を求められるなどのことも起こっている．マイクロソフトのパスワード管理はずさんそのものであるように見えるし，グーグル開発チームが何をやっているのかも分からない．ファーウェイ製スマホを使っているので，情報が海外流出するリスクは十分ある．警察庁にサイバー特別捜査隊なるものが設置されたが，期待と反するものになるであろうことは予期しておいた方がよい．いまごろマカフィーは天国で腹を抱えて笑っていることだろう．

アイコンを作り直してみたが思ったようにならないので，また元に戻した．単純なスパイラルの図案だが，さすがにプロが作ったものはひと味違う．背景を黒にして白抜き，ないし赤で着色しようとしたのだが，オリジナルのような立体感が出ない．何か板金で作ったような平板なものになってしまう．形状もどうしてもいびつで整った「製品」の感じが出せない．わたしもかつては，専門学校でマルチメディアを教えていたこともあるので，こんな簡単なデザインで手こずっているようではわたしに教わった生徒たちもがっかりだろう．mmm… わたしが教えた生徒の中にはそれができるものもいるかもしれないが…いや，そもそも，もう目が不自由になりかけているので，と弁明しておく…

開発機の完全スキャンはまだ3時間も残っている．というか，ずーっと残り約3時間です，が続いている．予備機の検証テストは完了している．所要時間は1日＋5時間55分，設定は2^26で67108864点を検査した．範囲は1811940449～1946158175で，現在の検査済み最大奇数に接続しているので，サイトの表示を更新しておこう．予備機は引き続き同じ設定でテストを続行しておこう．すでに次の開始番号は表示されているので，Verifyボタンを押すだけだ．所要時間見積もりは1日＋4時間40分．

モヒティのスレッドでコラッツ木構造図の誤りを修正したのに続いてコメントを書き込んでいる．モヒティはまだ，コラッツ問題は解けたと考えていないようだ．もう少し説明が必要なので解説用の図版を追加することにした．ゼルコバの木を使って作図するつもりだが，予備機をゼルコバの木の動作確認用にも使えるようにしておきたいので，現行のコラッツ専用版をリリースしてインストールしておくことにする．

解説用図版として，Eldest Sons Treeというのを出そうとしているのだが，その前に全体図の中で長子ノードをカラー表示してどのような配置になっているかを示しておきたい．現行のゼルコバの木でそれをやろうとすると，長子ノードを女子に指定してカラー表示するくらいのことしかできないが，現在のコラッツ木出力は３の倍数ノードを女子に当てているので，できればその情報は温存しておきたい．前々からの懸案だった部分図のカラー表示というのを実装してみる．これに着手しなかったのは，すべての部分図に個別に色を割り当てたり，カラーに透明度を与えて重ね合わせができるようにするなどのことを考えていたためだが，現状で多重カード色というのがあるので，それを流用することにする．これなら簡単に実装できる．⇒できた．なんでこんな簡単なことにいままで気づかなかったのだろう？バージョンを一つ上げておこう．

▲部分図を設定したのに保存しないで閉じてしまっている．いや，開発環境で強制終了していたかもしれないが…また，部分図を設定しても全体図で直ちにカラーが出ない．一度部分図に移動して戻ると着色されている．⇒これまでは部分図カラーというのがなかったので，部分図を設定しても再描画されていなかったためだ．

▲保存しますか？でライセンスキーが未生成だったので，キャンセルで抜けて正常終了のはずだが，EXEがロック状態になったまま開発環境で実行できない．タスクマネージャではプロセスは走っていない．

これが，Eldest Sons Treeだ．というか，これはまだ「全体図」でこの図のカラーノードを抽出したものがそうなのだが…この状態では部分図に切り替えたときにバラバラになってしまう．右端の一角を除いては親子関係が切れているためだ．これをつなぐためには親のいないノードに仮親を与えなくてはならない．

▲どこかでハングしてしまった．父欄ダブルクリックで白紙カードが2枚できているが，画面上には1枚しか表示されていない．⇒選択状態がおかしくなっていたようだ．領域選択したら，その後は問題なく動作するようになった．

▲入力欄にカーソルを置いた状態でどこかカードをクリックすると，そのカードにリンクできるようにしたい．

▲既存カード氏名を父欄に入力→登録したはずだが，別カードが作られてしまった．⇒現行の暫定版（特注版）ではUNDOを止めてあるので，戻る操作ができない．⇒性別を見ているためだ．このカードは女子なので父にはなれない．

▲あいまい選択でカード巡回パネルが出ているとき，パネルを移動できない．

▲既存カード369を母欄に記入して，既存カラー表示されない．⇒やはり，新規カードが作られてしまっている．⇒性別が間違っている．

▲一覧表をクリックしたとき，数字は辞書順ではなく，数値の大きさで比較して欲しい．

▲オリジナルのCSVファイルに誤りがある可能性がある．11は3の倍数ではないのに女子になっている．⇒この誤りはかなり広範に起きている．⇒ノード番号ではなく，参照番号を見ていた．⇒修正した．

▲部分図に移動しようとして，PARTIALNAME::ExtractPartialCardのエラーになった．

▲現行では確定選択したあと，登録ボタンを押さないと登録が実行されない仕様になっているが，忘れることが多い．プロンプトを出すべきではないか？

▲部分図を生成しても，明示的に登録しないと保存できない．アプリ終了時にプロンプトを出すべきだ．

▲部分図画面を開いていて，部分図に登録して画面が更新されない．

▲実子と養子の違いはあるが，配偶者のいない結婚でページが2つに分かれてしまっている．

▲どうも，かなり動作が悪い．803に父1205を登録して登録が消えてしまう．この状態でファイルをCollatzCoreTree 3-5-94 – BADとして保全した．親子関係の登録で親の親との関係が切れてしまうようなことが起こっているように見える．性別を間違えるといろいろ厄介なので，先にそれをチェックしておこう．というか，このサンプルは放置して，オリジナルからもう一度作り直すことにする．⇒いや，目視で直すよりプログラムで直してしまった方がよい．

▲純血統図というのは養親子関係を完全に無視するというのではなかっただろうか？多重カードが発生している．純血統図を解いたあとも図式が戻らない．多重カードを出して開きっぱなし．

▲CollatzTreeCoreをダブルクリックで開いてフォントサイズゼロエラーになった．

Eldest Sons Tree の元絵ができた．eldest sonは兄弟枠の最右ノードで長子と呼ばれるものに等しい．

長子ノードだけからなる木がEldest Sons Treeだ．上の図は3正則木だが，下の長子図は2正則木になっている．このため，１→5のところが変則的な形状になっているが，この2つのノードは合併してシンプルな2正則グラフとするのが正しいと思う．

コラッツ正則木では3の倍数ノードが終端ノードになるため，あちこちに穴の空いたような図式になるが，Eldest Sons Treeはつねに完全正則木になる（を構成できる）．

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