月: 2021年12月

ThunderBirdに追加した2つのメールアカウント，admin@zelkova-tree.netとzelkova@zelkova-tree.netの設定が消えてしまったので，再登録したところまではよいのだが，3日前の2021/12/27に受信したはずのメールが消えてしまっている．昨日はCドライブを空けるために，ファイルを移動したり，削除したりしているので，その手順をどこかで誤っている可能性はある．消えたファイルのほとんどはゴミと言ってもよいものなので，あきらめるとして，バックアップをさっぱり取っていないことに気付いて，現時点におけるバックアップを取ろうとしたのだが，外付けHDをこのノートにつないで開こうとしたとたん，HDでパチっのような音がして死んでしまった．

一度ノートを落として再起動してみたが，ほぼ瀕死の状態だ．HDを外して起動することはできたが，今度はDドライブにアクセスできないという警告が出た．Dドライブには256GBのSDカードが装着してあるはずだが，なぜかEドライブに変わっている．いつもはタスクバーに表示されているはずの常用プログラムのアイコンも消えてしまっている．プログラムはインストールされた状態になっているようなので，再インストールしなくても使える模様だが，DドライブにアクセスしているThunderBirdやOpen Live Writerは再設定しなくてはならない．ドライブ名の指定をどこかで切り替えることはできなかったのだろうか？

できた！スタート→Windows 管理ツール→コンピュータの管理→ディスクの管理で簡単に変更できた．再起動すると，タスクバーやデスクトップの状態も完全に復旧している．書きかけのログも復元できたので，内容は上記とほぼ同じだが，コピーしておこう．

フロントエンドで使っているサブノートのCドライブを空けるために不要ファイルを削除したときの操作で，ThunderBirdの設定ファイルが古くなってしまったようだ．新たに追加した2つのアカウト，admin@zekova-tree.netとzelkova@zelkova-tree.net の設定が消えてしまった．データフォルダは残っているので多分アカウントを追加すれば復活するはずだが…⇒アカウントの追加は問題なくできたが，メールが消えてしまった．3日前の2021-12-27には，adminに228通，zelkovaに30通メールが入っていたはずなのだが，どこにも見当たらない．

2021-12-27には，メールを受信した後振り分けてフォルダに移しているはずだが，検索を掛けても出てこない．2018年以前のものは残っているが，2018年の年末～2021年までの分がない．どうもどこかでフォルダまで古くなってしまったようだ．そもそも，それらの操作を行ったのは，このノートに移行してからのことだし，メールデータを置いているSDカード(256GB)はまったくいじっていないつもりなのだが…逆にこの間バックアップをまったく取っていなかったので，以前の状態に戻すこともできない…

ちょっと遅きに失するが，現時点のバックアップを取っておこう．

外付けHDはメインマシンに戻してあるが，読み書きできるかどうかチェックしておこう．⇒まったく，問題なく開けた．HD自体には特に問題ないとすれば，このサブノート自体の不良ということになる．外付けHDはUSBで接続しているが，USB回路に問題があるのだろうか？症状からは明らかにハード的な要因であるように思われるが，この先このマシンを（少なくとも当面の間）使い続けることができるのだろうか？どうもこの，外部接続用のフロントエンドと呼んでいるポジションに置かれたマシンは戦場の最前線の兵士たちのように犠牲続出という感じだ．いまのところ，USBには無線マウス用の小さなアダプタが繋がれているだけだが，それだけではかなり不自由だ．

ともかく，何らかの方法で現時点でのバックアップを取ることを考えよう．マイクロSDは取り外しが厄介なので，USBメモリかWIFIで所内LANにつなぐしかない．LANを使うことにしたが，残り時間2日以上と出ている．転送量も127GBもある．外付けHDの空き容量は133GBあるのでぎりぎり間に合わない数字ではないが…転送速度は1MB/sをちょっと切ったくらいなので，それほど遅いというほどではない．ともかくこのまま続行することにする．外付けHDはほぼ満杯になるので，これで凍結ということにして，今後のバックアップには何か別の手立てを用意するしかないだろう．DVDに吐き出してしまうという手もあるような気はするが…いや，それはいいが，所内LANを使っている間はネットに出ることができない…それもかなり不都合かもしれない．ログを更新することもできないが，ちょっとした情報特に英単語などをGoogle翻訳するなどのこともできない…2日以上ということは年が明けるまでに終わらないということになるが…まぁ，たまにはそういうことがあってもよいのではないだろうか？投稿する代わりにローカルで保存しておけばよい．

今日の主な仕事は，モヒティのスレッドで続いたディスカッションをまとめて一本の記事にまとめることだ．ボリューム的にはすでに投稿してあるのがすべてだが，スペルミスを修正したり，多少の配置換えなども必要になる．できれば，画像もすべて貼り直しておきたいのだが…というのは，現在貼り込まれている画像はすべてFBのページにリンクしているので，それを外しておきたい．しかし，ネット接続なしでスペルチェックできるだろうか？⇒いや，ローカルでも動作している．スペルチェッカーはOpen Live Writerに埋め込まれているものだが，すべての単語の辞書を持っているのだろうか？

すでに少なくとも1時間は経過していると思われるが，転送はまだ3%しか進んでいない．残り時間は依然として2日以上だ．ミススペルは相当ある．bascketはbasketだし，senceはsenseの間違いだ．過去形やingで語尾のtなどの子音がダブるというのも身に付いていない．時計の針はすでに0時を回って31日に入っている．元旦二日は仕事しないというのが決まりだが，今年は3日に集まることになっているので，三ヶ日はお休みということになりそうだ．スマホがあるので，外界とまったく途絶するという訳でもない．まぁ，年を越すのにはうってつけのシチュエーションなのではないだろうか？

何時間くらい寝たのかよくわからないが，午後三時頃姉が年越し蕎麦とお節を届けてくれたのを受け取ってまた，寝てしまった．転送の残り時間は3時間45分になっている．いま，午後7時15分だから，11時には完了する計算だ．つまり，年が明ける前に終わりそうだ．テント村にアップする予定の記事はほとんどまとまって，一部ネットにアクセスしないと調整できない部分が残っているくらいなので，年内ないし年明け早々にはアップできるだろう．

記事の校正もほぼ完了した．ファイル転送は後2時間残っている．いま，午後9時35分なので除夜の鐘を聴く前に終わるだろう．あと，残っている仕事として，記事中の画像をローカルの画像で差し替えておきたい．まず，それらのファイルを揃えなくてはならない．投稿はVAIOを使っている時期にやっているので，多分VAIOのデスクトップに置いてあるはずだが，バックアップを取ってあるだろうか？

バックアップは取ってあるはずだが，マイクロSDには移していない．メイン機に接続した外付けHDからマイクロSDにVAIOのデスクトップを丸ごとコピーすることにしたが，こちらも2時間45分掛かると出ている．これが終わるまでは何もできないということになった．まぁ，年越し蕎麦でも食べて待つことにしよう．⇒食事している間にサブノート側が落ちてしまった．メイン機側は接続が切れて待ちの状態になっている．再起動でメイン機側の作業は続行できたが，サブ側の作業は中断点がわからないので一旦打ち切るしかない．転送されたのは791MBだが，全体では4GB以上あるので，1/5も終わっていない．同時に双方向で転送するのは無理っぽいので，メイン側が終わるのを待つことにする．92%まで終わっているが，まだ2時間5分も掛かる．

若水を汲んで鬼柚子を入れた初風呂に入ってきた．腰の調子がかなり楽だ．こんな感じで一年持ってくれればいいのだが…転送は完了している．フロ→洗濯というルーチンになっているのだが，元旦早々，それも未明に洗濯機を回すのも何なので遅延処理ということにしておく．姉からもらったお茶を入れて福茶を頂くという段取りだが，今年は梅干しの支給がなかった．干し柿も入っていない．amory氏から送られた干し柿はとっくに食べてしまっているし…それでも，かすかに正月のフレーバーは感じられる…ほとんど無臭に近いものだが…そもそも，除夜の鐘がどこからも聴こえてこない．どこかでにぎやかに年越ししているグループもあるのだろうが…ほとんどサイレントナイトだ．

またWordPressで不調が始まった．投稿しようとすると，xmlrpc.php403 Forbidden エラーが起こる．WAFはすでに止めてあるので対処する方法がない．

なんとなく通った．ロリポのユーザ専用ページで一度WAFを有効化し，しばらく経ってから無効化するという操作をやってみたのだが，それで解決したのだろうか？

ようやく使えるようになったと思ったのも束の間，また障害が発生し始めた．接続を一旦解除してしばらく放置した後，再度接続することで復活した．どうも安定が悪い．VPNは使っていないのだが…アクセスポイントが動的に移動しているような気がする．むしろVPNを使った方が安定するということも考えられるので試してみよう．VPNを使うこと自体には問題はないようだ．⇒またぶり返してしまった．

どうも英文の記事を送るとブロックされているような気がするのだが…今度は通った．

外部アクセス用に使っていたノートがいよいよ潰れてしまったので，一度は退役していた2 in 1 サブノートを復活させて使うことになった．このノートは3回も基盤交換している曰く付きマシーンなのであまり使いたくはなかったのだが，背に腹は変えられない．悪いことには，いつこうなったのかまったく記憶にないのだが，液晶ガラス面の左下隅にひび割れがあり，そこをさすったりするとバチンと音がしてシステムが落ちてしまったりする．さらに悪いことには，どうもこの古傷（というより，わたしが知らない間に付いたので比較的最近の新しい傷のようにも思われるが）の影響か？電源コードを抜くとシステムが落ちて再起動できないのでタブレットとして持ち運ぶこともできない．

満身創痍という感じだが，ネットの接続がしばしば途切れるという障害がなくなっただけでもよしとするしかない．外部アクセス用ノートの用途は主に2つで，一つはメールの送受信，もう一つは作業ログのアップロードだ．どちらも動作するようになっているが，Open Live Writerの画面が少しおかしいところが気になっている．下図はその編集画面だが，タイトル入力欄とツールバーの間に余分な空白が入ってしまっている．あまりうれしくない．

Open Live Writer の前身はマイクロソフトのWindows Live Writerでこのツールがサポート中止になったあと，有志がそれを引き継いで保全しているものだ．Open Live Writer は有志グループの本家サイトとマイクロソフトのどちらからもダウンロードできる．両者のコードには多少の差異はあるようだが，どちらを使っても同じ表示になった．まぁ，実害はないのでこのまま使うしかない…メーラーはThunderBirdを使っているが，現時点ではベストチョイスではないかと考えている．メールの全文検索が可能でかつ，カスタマイズ可能なフィルターも十分実用的なのでわたし的には十分満足だ．

2018年の末にネットに復帰したとき，ユーザ会のパワーユーザに案内メールをCCで送信したことがトリガーとなって大規模なスパムメールが発生して以来，zelkova-tree.netのメールサーバーは使わないようにしていたのだが，このサーバーに登録していたメールアカウントのうち，削除できないため温存していた2つのアドレスを使う必要がでてきたので，アカウントを復活させて受信できるようにしてみた．一つはadmin@zelkova-tree.net，もう一つはzelkova@zelkova-tree.net でどちらもなんらかの契約関係で使っているためすぐには抹消できない．

どちらのアカウントにも2018年から2021年にかけて受信したメールが残っていて，adminには228通，zelkovaには30通のメールが入っていた．カスペルスキーはこのうちの12通を悪質な危険メールとして削除した．（時刻欄で*が付いているのは，送信時刻とカスペルスキーのレポートに記載された（受信時刻と推定される）時間が逆転しているもの）

日付	送信元	宛先	件名
2019/10/21 05:30 2019/10/21 03:27:25*	admin@ zelkova-tree.net	admin@ zelkova-tree.net	Your accounts was hacked by criminal group.
2019/11/21 17:03 2019/11/21 10:41:17*	gelidahv@ fcmail.com	admin@ zelkova-tree.net	I really recommend u to read that letter, just to make sure absolutely nothing could occur
2019/11/21 23:18 2019/11/22 05:18:32	saumata@ easy.com	admin@ zelkova-tree.net	I extremely recommend u to study this letter, simply to ensure not a thing could occur
2019/11/21 23:15 2019/11/22 05:23:08	meliaha@ mail2freedom.com	zelkova@ zelkova-tree.net	I extremely suggest u to read that letter, simply to make sure absolutely nothing could occur
2019/11/12 02:58 2019/11/12 02:13:24*	wypiupohaq8446 @cgocable.net	zelkova@ zelkova-tree.net	Your account is being used by another person!
2019/10/08 18:36 2019/10/09 00:02:25	zelkova@ zelkova-tree.net	zelkova@ zelkova-tree.net	Security Notice. Someone have access to your system.
2019/10/21 5:30 2019/10/21 03:27:25*	admin@ zelkova-tree.net	admin@ zelkova-tree.net	Security Alert. Your accounts was hacked by criminal group.
2019/11/21 17:03 2019/11/21 10:41:17*	gelidahv@ fcmail.com	admin@ zelkova-tree.net	I really recommend u to read that letter, just to make sure absolutely nothing could occur
2019/11/21 23:18 2019/11/22 05:18:32	saumata@ easy.com	admin@ zelkova-tree.net	I extremely recommend u to study this letter, simply to ensure not a thing could occur
2019/11/21 23:15 2019/11/22 05:23:08	meliaha@ mail2freedom.com	zelkova@ zelkova-tree.net	I extremely suggest u to read that letter, simply to make sure absolutely nothing could occur
2019/11/12 02:58 2019/11/12 02:13:24*	wypiupohaq8446 @cgocable.net	zelkova@ zelkova-tree.net	Your account is being used by another person!
2019/10/08 18:36 2019/10/09 00:02:25	zelkova@ zelkova-tree.net		Security Notice. Someone have access to your system.

PCの移行に取り掛かる前に，廃棄対象となるノードでこれらのメールを受信して，その一部を開いているが，そこには「君のアカウトはハックされている．その証拠はこのメールが君自身のアカウトから発信されていることを見れば明らかだろう．」のようなことが書いてあった．確かに，それは疑いようのない事実であるように思われる．パスワードは変更しているので，現時点ではリスクは解消しているものと思われる．

上記の大量同報送信事案が発生したのは，2018/11/20のことで，その時点で一旦Zelkova-tree.netのすべてのアカウトを停止し，後に復活させた2つのアカウントのパスワードはその時点で変更している．いや，adminのパスワードは以前のままだ…

比較的最近カスペルスキーから，nasu@zelkova-tree.netアカウントが流出アカウントデータベースに入っているというレポートをもらった．カスペルスキーがなぜそのことに気付いたのかよくわからないが，現在パスワード管理はすべてカスペルスキーに任せているので，移行手続きを実行しているタイミングでどこかにあったこのアカウントに気付いたのだろう．nasu@zelkova-tree.netはわたしの記憶では「事故」以来使っていないので，多分問題ないと思う．ともかく，adminのパスワードを変更しておこう．⇒いや，すでに変更は入っている．語幹は同じだが文字列を追加して少し長くしている．⇒カスペルスキーが生成するパスワードは各種の記号が入っているため（逆にロリポップ！で必須の記号が入ってこない），弾かれてしまう．⇒更新した．

もう一つ片付けておかなくてはならないことがある．フェイスブックの別アカウントの復活だ．2014年頃に作ったものだが，ほとんど使わずに放置していたものだ．そろそろ本名アカウントが必要になってきたので復活させたいのだが，パスワードどころか，登録に使ったメールアドレスさえ忘れてしまっている．メールアドレスは何とか見つけ出したが，パスワードの更新で躓いてしまった．FBでは休止アカウントの復活には本人確認手続きが必要とされるようになっている．手順は2段階で，まずセルフィーの短い動画を作成し，それから本人確認書類を撮影してアップロードすることになっている．

馬場英治のアカウントはAge Babaで本名アカウントはM.N.で登録しているはずなのに，本人確認の段ではAge Babaであることを証明するよう求められている．これははなはだ不都合だ．フェイスブックは実名登録が原則だが，通称やニックネームの使用は暗黙に認められている．もちろんフェイスブックを始めたころには，本人確認などのことはまったくやっていなかった．昨日一度リジェクトされて，今日は二度目の挑戦だが，まだ審査結果は届いていない．昨日はほとんど折返しでノーが返ってきているので，多少期待できる可能性はあるのではないかと思う．もし，これが通らないとしたら新しい同名のアカウントを作るしかないが，その際問題になりそうな事項としては，一つのスマホ番号で複数のアカウトを登録できないという制限があるという可能性だ．

BlackHawkからWordPressにテスト投稿

▲下のような設定で，垂直親子連結線が兄弟連結水平線を突き出ている．

サンプルはCollatz Tree 3-10-990.zel．

▲Zelkova Treeのリリース版ではCT 3-12-990.CSVを読み込んでエラーパネルが出る．デバッグ版では出ない．また，このサンプルでは「42725406261」というノードが孤立カードになっている．コラッツ木では基準番号と氏名は同じ数字になっているが，このノードに限って214783647という異なる番号が振られている．このカードは3の倍数だ．コラッツ木生成ツールで調べると，このノードは4005506837に繋がっていなくてはならないのだが…42725406261は1から8世代目で左端の枝番号3の枝を辿ると行き着けるはずなのだが，そもそもその親の4005506837がこのグラフに載っていない．この番号はCSVにも記載されていない．いや，記載されている．4005506837に接続する子ノードは3つある．

原因は分かった．この木の左橋辺で187758133の子どもが2人しかいない．カード数が1000点を超えるときにはカットされることはあり得るとしても，上位階のノードが先にカットされることはあり得ない．カード数が990になっていることに関係しているのかもしれない．

あるカードがレンジオーバーしていれば，その場で落とされるということもあり得るが…いまのケースはそれには該当しない．⇒CSVには1000点入っている．ゼルコバの木で失敗しているようだ．⇒どうもこれは，与えられた数が大き過ぎるためではないかと思われる．番号は本来「氏名」でしかないのだが，実際には基準番号として使われている．基準番号はおそらくLONGとして扱われているはずだが，32ビットしかないのではないだろうか？基準番号がレンジオーバーを起こしているときどのように処理されているのかを見る必要がある．リリース版で起きているエラーはおそらくこれだろう．

エラーの原因はatoiにあるようだ．この関数で”4005506837″という文字列が2147483647という数字に化けてしまう．atoiをatolに変えてみたが，結果は同じだ．longは64ビットで9,223,372,036,854,775,807まで扱えるので十分なはずなのだが…受ける側でlong longで受け取って正しい値が取り出せた．C言語の仕様では，longは64ビットとなっているが，マイクロソフトのlongは32ビットのようだ．つまり，intと同じだ．対策としては，

1. 現状のまま，32ビットを超えるデータは扱わない
2. データの仕様を変更して64ビットを扱えるようにする
3. 基準番号を振り替えて1～1000の範囲に収まるように振り替える

現時点では2の選択肢はないように思われる．3の修正にどの程度のコストが掛かるか？が問題だ．手が掛かるとすれば，現状であきらめるしかない．⇒やってできないほどのことではないと思われるので3の修正を試みることにしよう．⇒意外と簡単に実装できた．CT 3-12-1000.CSVを取りこぼしなく読み出せるようになった．CSVファイルは4種あるが，これはメインのCSVで，残り3つはまだ読み出せるようになっていない．まず，CollatzChain.CSVから見てゆくことにしよう．このコラッツ木は倒立しているので，逆順に直さなくてはならない．⇒できたようだ．いや，まだできていない．ノードが一つ足りない．⇒終わった．

▲コラッツ木生成の動作がおかしい．Rootに17602325と入れて，GOで

17602325
11734883

という出力になった．これはかなりおかしい．この表示は孤立ノードが2つあるということになるが，17602325と11734883のどちらも3の倍数ではない．また，エラーになったあとの動作もおかしい．CSVは開いていないのに，別アプリが使っているという警告が出る．⇒これは，自分で使ったままにしている可能性がある．⇒論理ミスがある．設定樹高を超えた場合には打ち切るようになっているが，途中から開始した場合には差分を引かなくてはならない．⇒対処した．

▲CollatzStreamingが立ったままになっている．オーバーフローの始末が付いていないようだ．CARDTABLE::makelinkでは，(nod->getpnum() != nod->cardbase.carddata.refnum && nod->cardbase.carddata.refnum <= tablesize)　のようなエラーが起きているのだが，理由が分からない．nodというのはカードリンクであり，この親はテーブルのはずだから，一致しているはずがない．また，参照番号がテーブルサイズより小さいというのは標準的なサンプルなら普通のことで，エラーとするのはおかしいように思われる．これとは別に両親不在の子どもというのが1件起きている．⇒解消したものと思われる．

▲白紙で起動して最初にインポートしたとき，イレギュラーなフェーズ遷移エラーが起きる．いや，起動直後ではなく，すでにインポートを実施したあとだろう．

▲CSVでは1000点までのファイルを生成しているはずなのに，ノード数が990しかないのはなぜか？⇒カードの基準番号をノード番号と共通にしていたため，基準番号は16ビット整数であるため，atoiでオーバーフローしてしまう．⇒基準番号が1～1000の範囲に収まるようCVS出力関数で調整した．CSV4種のうち，CollatzTree.csv, CollatzChain.csv, CollatzNumber.csvまでは対処し，残りはCollatzTrancate.csvだけになった．⇒できた！

いよいよ，このノートも年貢の収め時が来たようだ．いろいろと不具合が出ていたが，とうとうネットにアクセスできないようになってしまった．最近は頻繁に切れるようになっていたのを何とかだましだまし使ってきたが，アクセスポイントリストでは接続状態になっているのに，ブラウザでは「インターネットに接続されていません」となってしまう．予備機は一応仕立ててあるので，移行するだけだ．

▲CN 335627293189680917.zelを開いて，「画面に合わせてズーム」，「縦幅に合わせてズーム」すると画面が白紙になってしまう．「横幅に合わせてズーム」では以下のパネルを出して，100％で表示する．

このサンプルは154世代あり，1%でも画面内に収まらない．⇒動作していた．木が細過ぎて見えなかっただけだ．

▲コラッツ木生成で．Root=1, Degree=1, Height=1で何も表示されない．このループはWX<MAXの間だけ実行するようになっているが，WX=MAX=1となっているため，無動作で抜けている．これはMAXの計算が間違っているのではないか？R=1, D=1, H=1なら，MAXは1+Dでなくてはならない．⇒修正した．

大体片付いたのではないかと思う．いや，まだある．

▲A面を走らせているとき，B面で例外が発生すると，A面も止まってしまう．いや，エラーが発生しなくても止まっているようだ．Get the Sequenceで停止している．TextBox1_TextChangedで複数のイベントを一括処理している．これは，入力パラメータ値が変更されたときに，MaxNumberを更新するための処理だから，A面にだけ関わるものだ．B面のTree Heightは計算完了して始めて更新されるものだから，イベントを取る必要はない．

A面では枝数3で樹高17くらいまでが限界だが，B面なら樹高120くらいまでは計算できる．そのような大きな（深いところにある）奇数を取り出すには，A面で得られた最大奇数を木の根に設定して再計算というのを複数回反復することで得られる．1111…. 1 という巨大奇数では227桁という長い鎖を得られた．A面では枝数2でも樹高26が限界だ．

大体収まったと思われるので，リリースの準備に入ることにしよう．まず，外部接続用に使っているVAIOから2 in 1 ノートのBlackHawkに移行する必要がある．VAIOではまだ所内LANに繋げることはできるので，ログを付けるのに用いることもできないことはないが，サイトに投稿できないのではどうしようもない．LANに切り替えて受け渡しすることも考えられなくはないが，いずれにしても完全移行を実現してからだ．

かなりできてきた．タブは機能別に2つある．①コラッツ木の生成では，部分木の根と，ノードの枝数，木の高さを指定してコラッツ部分木を生成し，接続リストを画面にダンプする．

②ノードの枝ポジションの取得には3つの機能がある．（1）コラッツ数列の取得，（2）ノード番号の取得，（3）簡略部分木の生成の3つだ．（1）コラッツ数列の取得では指定した奇数のコラッツ数列を生成する．各ノードには数列の軌道を示す枝番号が付されている．（2）ノード番号の取得では，部分木の根のノード番号とそこからの経路を示す枝番号のリストを入力して，その位置にあるノードの番号を取得する．（2）は（1）の逆演算になっている．（3）簡略部分木の生成では．（2）で入力された情報を使って幹と葉だけのスギナのような部分木を生成する．この部分木のノードは最大枝数で指定した数の枝を持っている．

「ノード数列から枝番号のコピーを指定」チェックボックスをオンにしておくと，（1）コラッツ数列の取得で表示された枝番号のリストが自動的に枝番号リスト入力ボックスにコピーされるので，（2）ノード番号の取得で枝番号リストを手入力する手間を省くことができる．「最大枝数」は変更可能で，（3）簡略部分木の生成で生成される部分木のノード枝数にはここで設定された値が使われるが，（1）と（2）の操作では処理された部分木上の実際の枝数によって自動的に上書きされる．

出力はすべて画面上に表示されるだけで，ファイルには保存されないが，「コラッツ木の生成」タブにある「ゼルコバの木ファイルフォーマットでエクスポート」チェックボックスをオンにしておくと，それぞれの操作で生成されたコラッツ木をゼルコバの木形式のCSVファイルに保存する．保存されるコラッツ木の形状はそれぞれの処理によって異なる．CSVファイルには４種があり，それぞれ固定のファイル名でデスクトップ上に生成される．

1. コラッツ木の生成（CollatzTree.csv）：指定されたノードを根とする指定された枝数と高さを持つコラッツ木
2. コラッツ数列の取得（CollatzChain.csv）：1を先頭ノードとし，指定されたノードを終端とする線形のコラッツ木（枝数1の鎖）
3. ノード番号の取得（CollatzNumber.csv）：指定されたノードを先頭ノードとし，枝番号リストで指定された経路の終端ノードを終端とする線形のコラッツ木（枝数1の鎖）
4. 簡略部分木の生成（TrancatedTree.csv）：３の線形コラッツ木の各ノードに指定された枝数の枝と葉を付け加えた木

まだ，バグは残っているかもしれないが，そろそろリリースしてもよいかもしれない．FBがEXEのアップロードを認めているかどうかが問題だ．当初はソースコードごと公開することを考えていたが，最高機密に相当するので今回は見送るつもりだ．（モヒティからも欲しいという要望は出ていないし…）

▲CollatzChain.csvをインポートしてエラーが発生する．内容はCollatzNumber.csvとまったく同じ．ただし，カード並びが一方が昇順，他方が降順という違いがある．読み込み後は正常に描画できる．エラーはTRIBEBOX::CheckAbsoluteGenerationで起きている．理由は系列優先ノードのbreakupがオフという理由にある．breakupという変数は「重婚クラスタ検定で除去された結婚枝の当事者ノード」というものだが，それと「系列優先ノードの絶対世代番号不一致」がどう関係するのか飲み込めない．この関数は「系列優先ノードの物理世代番号を基準に絶対世代番号を振り直す．系列優先借りノードがbreakupノード（重婚クラスタ検定でパージされた結婚当事者）の場合，そのノードが本人ノードであっても，絶対世代番号と異なる位置に配置される場合がある得る　このような場合，「系列優先ノードの物理世代番号を基準にその系列に属するすべてのノードの絶対世代番号を振り直す．」のように説明されているが，このサンプルでそのようなことが起きるとは考えづらい．⇒「コラッツ対応版応急措置＠20211223」で止めておくことにする．

▲リリース版を使って，コラッツ木生成で枝数3，樹高40を実行したところ，どこかでハングしてしまった．STOPボタンも効かない．⇒Gobutton_Clickでオーバーフローが発生してSTOP文が実行された後，制御を失っている．⇒例外をスローしてハンドラーで処理するようにした．

コラッツ木生成で枝数3では樹高17以上は処理できない．枝数2では26くらいまでだ．

▲EXEを走らせておいたところ，カウント4985でハングしている．1分30秒しか走っていない．枝数は2，樹高は26．画面の移動もできない．エクスポートはオンになっている．MAX樹高は27になっているので，割当分は完了しているようにも見える．オーバーフロー件数は0だ．開発環境では再現しない．リリース版を作り直して再試行してみたが，再現しない．

▲ごく一部しか処理されていないのに，樹高がどんどん上がってしまう．これはかなりおかしい．現行論理は積み上がったものを端から処理してゆくだけの単純なものだが，これだと偏った木になってしまうのだろうか？だとしたら，高さで打ち切るようにしなくてはならない．⇒樹高を求める計算が間違っているのではないだろうか？⇒樹高を求める計算は間違っていないし，ノードの総数を求める計算もあっている．変異が起きるのは，3の倍数が子孫を持たないためだ．3の倍数は表示されているノードの1/3に当たるが，その下流がすべてカットされるため，膨大な数のノードが余剰となり，それが溢れて木の高さを大きくしている．やはり，設定値で切断するようにした方がよい．これ↓が樹高5の正しいコラッツ正則木だ．

これを見ると，設定では三元木のところ，実際には二元木になっていることがわかる．また，3の倍数ノードをピンク（女子色）にしているので，3の倍数ノードが正確に全体の1/3であることも分かる．これが一番わかり易いのではないか？ただし，三元木がが完全に正則であると仮定したときのノード数364を大幅に下回る94ノードしか表示されていない．樹高5の二元木のノード数63に3の倍数ノードの個数31を加えると正確に実数の94という数字になる．まだレンジオーバーフローは発生していないが，レンジオーバーフローが発生するようになれば，設定値よりさらに少なくなることだろう．

レンジオーバーフローのカウントはレンジオーバーフローとなるノードの個数ではなく，レンジオーバーフローの発生回数であるので，この数を参照しても必ずしも総和と一致しない場合があるだろう．これは，一度レンジオーバーが発生すると，その後に続くノードも必ずレンジローバーになるので，そこで処理を打ち切っているためだ．枝数4，樹高4のサンプルを取ってみた．

4は3で割り切れないので，枝数3のノードと2のノードが入り混じった状態になっているが，女子ノードが全体の1/3になるという点に関しては間違いがない．これで大体まとまったのではないだろうか？あと残ったのは，この手続きが代数的に正しいことの証明だけだ．

コラッツ木生成ツールはほとんど完成しているが，もう一つだけ機能追加することにした．ノードのアドレス（枝番号リスト）を渡してそのノードを特定するという処理だ．これができると，仮想的にはコラッツ木上の任意の位置にある奇数を特定できることになり，コラッツ木を完全管理（アンダーコントロール）できていることを示すことになる．⇒ほぼ実装完了した．画面構成も変更し，タブで画面全体を覆うようにした．2つのタブはそれぞれ出力用ペーンを持ち，干渉することなく独立した2つのアプリとして操作できる．つまり，Build Collatz Treeで大きな木をダンプしているのと並行して，GetBranchPositionで遊ぶことができる．GetBranchPositionには2つ機能が入っている，①Get the Sequence と②Get the Numberだ．

①は奇数を指定して，その奇数のコラッツ数列を出力し，②はコラッツ数列の枝番号リストを入力してその経路の末尾ノードを出力するというものだ．②は①の逆演算で実際，出力画面では天地が完全に入れ替わっている．このプログラムがつねに正しい値を出力することが保証されれば，このアプリ自体，コラッツグラフ問題に対する解答になっている．①の論理も②の論理も間違いようがない程度にシンプルなものなので，すでにこの問題は解かれていると考えてよいと思う．

ことのついでにもう一つ機能拡張しておきたい．Trunlcated treeというオプションだ．これを使うとコラッツ木を1本の幹と葉だけからなる単純な木に縮約して出力することができる．本体のBuild Collatz Treeの出力はしばしば大きなものとなり，終了までに数時間以上掛かることもあるので，興味のある部分だけを抽出出力できればかなり応用範囲が広がる．それほど難しいものではないので，実装に進むことにしよう．

書きかけでPCを再起動することになったので，下書きに保存してOpen Live Writerを閉じたつもりなのに，残っていない．パラグラフ3つ分くらいなのだが… 最初の辺りはもう忘れてしまったので，最後のVBのバグについてだけ書いておこう．

DIm N as Ulong = Val(str) で文字列を数値に変換するとき，Integerの上限よりも大きいがUlongの上限よりは小さいような奇数文字列を変換しようとすると，偶数に化けてしまう．境界がどの辺りかは確定できなかったが，10進数で15桁以上の数で起きているように思われる．Valを使うのを止めて，Ulong.parse()を使うように変更して解決した．

▲9007199254740991という奇数のコラッツ木上のアドレスを計算して，下のような結果が出ている．

3 [1]  5 [1]　1 [1]

これはかなりおかしい．3は3の倍数であり，3の倍数は部分木を持っていないことになっているからだ．しかも，3 [1]というのは3というノードの枝1に接続していることを意味するのだから，なおさらだ.

9007199254740991 – 1)  = 9007199254740990 を4で割ると，2,251,799,813,685,247.5 余り 1 になる．従って，このノードは最右ノードであると思われる．この数に 3N+ 1 を施すと，27021597764222974を2で割り込んでゆくと，3になる．この計算はおかしい．27021597764222974は3の倍数ではない．どうもN/2の計算が間違っているようだ．実数になってしまっている．⇒2で除算する代わりにビット演算で右シフトするようにしたら正しく動作した．ただし，どこかでオーバーフローが発生してしまう．3N+1でオーバーフローが起きている．ノードの枝ポジションの計算は単発なので，ここで打ち切るしかないだろう．

上記の修正をプログラム全体に適用しなくてはならない．①ValをParseに代える，②N/2を右シフトに代えるの2点だ．⇒この修正後，起動時に例外が発生するようになってしまった．どうも，Parseという関数はテキストが空文字列の場合には例外を発生するという作りになっているようだ．しかし，デザイン画面では13という値が入っているのだが… この例外はDesigner.vbでオブジェクトの初期化を実施しているところで起きている．TextBox1_TextChangedで文字列が空の場合は無動作で復帰するようにした．

2で除算で動作不良が起きるのなら，他の数での除算でも同様のことが起きる可能性がある．このプログラムでは除算は①2で除算，②3で除算，③4で除算，④d-1 で除算の4通りある．③の4で除算は右シフト2回，③で除算は右シフト＋加算でも対処できるが，④が問題だ．しかし，④は問題にならない可能性もある．2で除算でエラーが出るのはおそらく，システムが型の異なる2つの値の除算と判断して，倍精度実数演算に切り替えているためではないかと推定される．これはおそらく定数2をIntegerと推定しているためと思われる．d-1の場合はdがULongなので，多分d-1もULongと認めてくれるのではないか？

③で除算は右シフト＋加算でも対処できるというのは，×3と÷3を取り違えている．3で除算をビット演算で代用することはできない．⇒安全のため，定数3をULongとして定義して使うようにした．

大体できたので，動画を取ってFBに投稿した．

https://www.facebook.com/groups/2354748741306929/posts/4541797995935315/?comment_id=4644516072330173&reply_comment_id=4644558065659307&notif_id=1640091947682768&notif_t=group_comment&ref=notif

コラッツ木生成プログラムに奇数Nのアドレスを取得する拡張を行ったが，さほど大きくない設定でも整数レンジオーバーが発生してしまうので，このプログラムの中で使っているすべての整数をIntegerからUlongに切り替えてみた．Integerは最大2,147,483,647だが，Ulongは18,446,744,073,709,551,615まで表現できる．ここまで出せればとりあえず，当面の目的には十分だ．trillionの上はquadrillionと呼ぶそうだが，quadrillionは千兆に相当するので，1京8千兆という巨大数字だ．

①コラッツ木生成と②アドレス計算を連携して表題のような操作ができるようにしてみたい．②の画面に最大次数と木の高さを表示し，これらの値を①の画面に転記して連続的に操作できるようにすればよいだろう．①コラッツ木生成では，Cancelボタンで打ち切れるようにしたい．どうすればよいか？Cancelイベントでなにかフラグを立ててやればよいのではないか？

アドレス計算で表示された最大次数と木の高さを①の画面に転記するというのは，少しやり過ぎではないか？この値は1をルートとする木の次数と高さであり，Nの部分木のそれではない．この意味では②の画面の入力奇数番号を①の開始番号に転記するというのもやり過ぎだろう．つまり，この2つの機能はあくまで独立に操作するものとしておいた方がよい．⇒道具立てはそろったので，テストしてみよう．

その前に，途中でキャンセルできるようになったので，中断したところまでに出力したノード数をカウントして表示できるようにしておこう．いや，すでにTotal Valid Numberという値が表示されている．これがその数に該当するのではないか？いや，おかしい．デザイン画面では表示されているのに，実行時には表示されない．なぜだろう？visibleが偽になっていた．⇒つねに最後まで実行するようになっていたので，設定値とつねに一致するため表示を省いていたのだろう．

まず，27までの経路が正しいことを確認してみよう．50までの奇数をすべて含むコラッツ木の葉になっているノードをすべて検査して，いずれも正しく動作していることを確認した．このために61，91などをルートとする部分木を出力して参照した．このプログラムはすでにほぼ完成していると言ってよいと思われるが，外部に持ち出して運用するためには，ゼルコバの木ファイル形式ではない，もっと一般的なファイルフォーマットで出力する必要がある．グラフファイルフォーマットにはいくつかの世界標準があるが，CSVファイルに落とすのが一番簡単でかつ扱い易いように思われるので，この仕様で実装することにする．この場合，今度は逆にCSVからZELに変換というのが必要になる．

▲以下の式である程度以上大きい数を文字列から数値に変化しようとすると，1多い数が返される．つまり，奇数が偶数に化けてしまう．

dim N as Ulong = Val(OddNumber.text)

Ulong.parse(OddNumber.text)で正しい値が取り出せるようになった．ただし，その後の計算がまだおかしい．

グラフ理論ではグラフGを頂点集合Vと辺集合Eの対 (V, E) であると定義している．頂点は英語ではvertexと呼ばれ，辺はedgeと呼ばれる．わたしはグラフ理論をかなり古い本で学んでいるので，頂点の代わりに点（point）と呼んだり，辺を枝（branch）と呼んだりすることもあるが，現在ではほとんど通用しない用語かもしれない．頂点(vertex)はときに節点（node）と呼ばれることもある．ノード（node）はどちらかというとグラフ理論の応用であるネットワーク理論などで使われているが，最近はグラフ理論の論文中などにも見かけるようになってきた．

わたしはこの2つ（vertexとnode）を次のように使い分けている．つまり，純グラフ理論的に頂点を扱うときには主にvertexを使い，応用的な使い方をするときにはnodeと呼んだりする．たとえば，自然数の集合｛1, 3, 5, 7,…, n｝を頂点集合とするグラフであれば，V(1)=1, V(2)=3 などのようになる．一方ノードとして見るときには，N(1) =1, N(3)=3のようにその「値」を直接使って表記する．この方が説明し易いことが多い．

NODULE はC++のクラスであり，我々のシステム上のすべてのオブジェクトを生成する基底クラスである．NODULEは親ノードへのリンクと子ノードへのリンク配列を構成要素として持っているが，この構成はFB上で展開した議論でコラッツ木構造として示したものにとてもよく似ている．

FB上のディスカッションではこのようなブロックを「セル」と呼んでいたが，今後はノジュール（nodule）と呼ぶことにしたい．このような構造体を導入すると，親リンクをNとして，スロット内の子リンクはN(1), N(2)のように表記できることになり，かなり都合がよい．たとえば，前述の「奇数ノードのアドレス」も，

67.address = 1((1) – 5(2) – 13(1) – 17(1) – 11(2) – 29(1) – 19(2) – 101(1)

のように記述することでその奇数のコラッツ木上の位置を一意に決定できる．67から生成されるコラッツ数列は

67→ 101 → 19 → 29 → 11 → 17 → 13 → 5 → 1

のようになるが，コラッツ構造体から生成される数列もそれとまったく一致する．異なるところはスロット（配列）上の位置が特定できるようになっているという点だけだ．これは従来の方式では絶対に求めることのできなかった情報であり，この解法の優位性を示すものと言える．NODULEクラスは，馬場研究所の出発点であり，（明示されてはいないが）25年も昔1996年に取得した米国特許(No. 5572642)技術の根底にある概念である．さて，構想も大体固まったので，実装に移ることにしよう．

「USBが認識されません」という症状が開発機にまで感染って来ている．マウスを交換したら動作するようになったので，このマウスが物理的に不良になっているのだろうか？Open Live Writer から投稿したときの画面の更新が依然として悪い．何らかの事情で反映するのに時間差が出るというのは受け入れられるが，複数の古いバージョンが交互に出てくるという現象は納得がいかない．ネット上のどこかでインターセプトされているのだろうか？もし，そうであるとすればパスワードを変えてもあまり効果はないかも知れない…新しいパスワードがハックされているとしたら意味がないからだ…まぁ，ともかくそれだけでもやっておくことにしよう．

Open Live Writerではプロフィールを更新すると，サイトのテーマをダウンロードするオプションがあるが，いつまで経っても完了しないので，更新しないことにした．テーマには変更はないので特に実害はない．気持ち応答がスムーズになった気がする… 時間遅れはあるが，誤動作は解消しているような気がするが，まだ分からない．さて，先に進む前にゼルコバの木の最新版とR20210317版で実施した修正の同期を取っておこう．多分まだ差分が少し残っているはずだ．

1. TOPOLOGY::ClearTableで参照番号不整合が発生したとき ⇒ すでに止めてあるが，「コラッツ対応版応急措置＠20211219」というリテラルで明示する
2. SearchCard.vbのSearchCommand_ClickでMakeSearchSelection  ⇒ すでに止めてある，この修正は恒常的なものであるように思われるので，現状のままとする
3. SelectCard.vbのSelectCard_KeyDownをまるごと止める ⇒ すでに止めてある　現状のまま
4. SelectCard.vbのSelectCard_Moveをまるごと止める ⇒ 現状のまま
5. SelectCard.vbのProcessDialogKeyは活きている ⇒ 現状のまま
6. NAMEBOX::Drawで人名枠高が世代高を超えた ⇒ コラッツ対応版応急措置＠20211219」で止める
7. MARGBOX::makeGoodSonの冒頭で「つねに中吊りする＠20211216」でゼロ復帰 ⇒ コラッツ対応版応急措置＠20211219」で対処
8. class COUPLINGの定義でclass PAGESETUP *pagesetupをprotectedからpublicに暫定修正 ⇒ 「仮修正@20211216」で対処
9. class PAGESETUPでdoCleanを新設 ⇒ 対処済

一応これで全部ではないかと思う．これでコラッツ木アドレス計算に戻れる．プログラムは小さいものだし，あまり分散させたくないので，これまで作ったコラッツ木生成プログラムの機能を拡張することで対処することにしよう．現行では，木の高さと次数を設定してGOボタンで計算するようになっているが，ボタンと入力ボックスを追加して，「ノードアドレス計算」でアドレス文字列を出力するようにしてみよう．「ノードアドレス計算」ではコラッツ木の全体を構成しなくても計算できるので，コラッツ木は生成しないことにする．ただし，できるだけ大きな数まで処理したいので整数範囲を拡大して，せめて倍長整数までは計算できるようにしてみたい．この部分はこれまで書いた論理とは別ものなので対処できるのではないだろうか？まず，画面を作ってみよう．

現行では設定パラメータにより，整数範囲オーバーが発生するとアプリ終了するようになっている．3-正則木のときは木の高さが6を超えるとオーバーフローする．これでは少しお粗末過ぎるが，これに関してはあとで対策するとして… 既存処理と新規追加処理はまったく独立なので，タブを導入して切り替えることにする．計算が完了するまでは，木の高さも次数も不明なのだから，奇数を入力された時点では表示できる情報は何もない．

後は，「Get node address」ボタンを押されたときの処理を書くだけだ．⇒一通り動作するようになったが，一筋縄ではゆかないところもある．出力データが正確であることを確認するためには，参照可能なコラッツ木の図面ないし，グラフデータのようなものが必要だが，現状では上記の通り，ごく小さい木しか出力できていない．ノードを指定して部分木を出力できるようにすればこの欠陥もかなり緩和されるので，まずその部分を実装しておくことにしよう．

おかしい．またあのxmlrpcエラーが出始めた．

なぜだろう？昨日，この機能を無効化しているのだが… ログインしようとしたら，403エラーになった．

WAF設定は昨日設定した通り，無効になっている…ロリポップのサポートに下記のようなメールを入れた．

「Open Live WriterからWordPressに投稿しようとして，下記のエラーが発生します．

The server repored an error with the following web address:https://zelkova-tree.net/WordPress/xmlrpc.php405  Not Allowed

また，WordPressにログインしようとすると，今度は「403 Error」が発生し，「現在，このページへのアクセスは禁止されています．サイト管理者の方はページの権限設定等が適切化ご確認ください」のメッセージが表示されます．

前日も同様の障害が発生したので，ロリポップ！ユーザ専用ページにアクセスし，WAF設定を無効とするように設定してその後は動作していました．現在確認したところでは，WAF設定は現在でも無効になっています．どのように対処したらよいのでしょうか？」

48時間以内に回答するということになっているが，前回問い合わせのときも2, 3日は掛かっていたような気がする．パスワードは今朝切り替えたばかりだが，効果なかったようだ．WordPressにログインできれば，Open Live Writerが使えなくても何とかなるのだが…手の打ちようがない．ともかく，一度リブートしてみよう．⇒WordPressにログインできた．Open Live Writerからの投稿もできた．どうもネットワーク上の経路のどこかでインターセプトされているような気がする…

コラッツ木の部分木を出力できるようになった．これはかなり便利だ．大き過ぎて一度には出力できない場合でもそのノードの周辺だけを出力できるので，原理的にはいくらでも（オーバーフローが発生しない範囲で）出力できるということになる．特にゼルコバの木は上限が1000なので，細かく分割できるとチェックするのも楽になる．61から下を調べてみよう．コラッツ1000.zelを開くのに1分以上掛かるため，マネージド・デバッグ・アシスタントのお出ましになってしまう．

#61の部分木を取ってZEL化した．このサンプルは364点しかない．高さを5に設定していたためだ．#911で高さ6に設定しようとして，オーバーフローが発生した．⇒このプログラムで扱う数は関数の戻り値以外はすべてUlongを使うようにしたら，オーバーフローがまったく発生しなくなった．いや，発生する．{61, 3, 13}という条件で以下のエラーが出た．

GetEvenでレンジオーバーの値を生成している．GetEvenはセルの最右偶数のM=N*2^cを計算しているところだ．レンジオーバーが発生していることは検知されているので，この部分の処理はまるごとスルーするしかないのではないか？左へ行くほど数は大きくなるので，回復する可能性はないと考えられる．これはMM OVER FLOWと言っているのと同じ性質のエラーなので，同じ扱いでよいのではないだろうか？⇒MM OVER FLOWを表示して処理を続行するようにしたが，まだ同じエラーが出る場所がある．M=M*2を実行する前に事前にチェックする必要がある．⇒これで停止しなくなったようだ．しかし，ダンプ出力しているのでムチャ時間が掛かりそうだ．あ，それでも予想外に早く完了した．ノード数239万点で2分12秒だ．オーバーフローは5000箇所くらいで発生している．かなりいい感じになってきた．

表題のプログラムを示せば，我々の解法が正しいことは誰にでも容易に理解できる（必ずしも証明に代わるものではないが）．類似のプログラムはネット上にあるが，それらは任意の奇数（ないし自然数）を指定して，その数から1に至るコラッツ数列を表示するというものに過ぎない．これらは個別の数について，コラッツ予測が成立していることを示すものではあるが，コラッツ木を一般的に生成するものではない（コラッツ正則木上の位置は決定できない）．表題プログラムはこれらとは一線を画すものであり，コラッツ木を葉から根へと探索するのではなく，その数のコラッツ木上の位置を直接決定しようとするものである．

どうも，外部接続用のVAIOの状態がおもわしくないので，万一に備えて予備を整備しておくことにする．画面というより，一部画像が真っ赤になってしまうという現象はしばらく現れていないが，USBが不安定ですぐに切れてしまう．無線マウスはまったく使えない．WiFiの接続も途切れることが多い．このノートはtamo2氏から贈呈されたものだが，そろそろ寿命なのではないかと思う．控えのマシンはしばらく使っていなかった 2 in 1 のサブノートだ．これまでに少なくとも3回基盤交換していることもあり，しばらく任務を解かれていたのだが，復帰してもらうしかない．OSをクリーンインストールした状態になっているので，環境整備を一からやらなくてはならない．

手順は例によって以下の通りだ．①デバイス名を変更する，②Chromeをインストールし，Googleにログインする，③カスペルスキーをインストールして，完全スキャンを実行する，④ThunderBirdを導入する，⑤Open Live Writerを導入する, ⓺MouseWithoutBordersを導入する．これだけ済めば後は，必要に応じてということでよいだろう．というか，このノートは実装RAM 4GB，HD 278GB しかないので，できるだけ余分なものは搭載しないようにしないと走らない．③の時点でディスクの空き容量はすでに12GBしかない．

ThunderBirdのデータ移行はまだやっていないが、一応使える状態にはなった。あ、もう一つある。Google日本語入力だ。これで一通り平常作業ができるようになったのではないだろうか？VAIOはまだ生きているが，マウスを使わずにタッチパッドで操作可能かどうか？見ておこう．タッチパッドが作動していると誤動作が発生することが多いので，現在はテープを貼って隠してある．⇒やはり，すべてをタッチパッドでやるというのはかなり難しい．特にThunderBirdなどでドラッグ＆ドロップなどをやるととんでもない失敗を冒す可能性がある．使うならマウス使用，使わないのなら廃棄と決め付けた方がよい．

新しい環境にも一つ難点がある．Open Live Writerの編集画面のレイアウトがおかしい．タイトルの上に不用な空白があり，その上，編集画面を一定の幅以上に広げることができない．それ以上に拡げると逆にその半幅に縮まってしまう．Open Live Writerは本家サイトからダウンロードしたものだ．USBが認識されずにカーソルが固まってしまうのよりはマシかも知れないが…

どうも，控えの方も怪しくなってきた．液晶のガラス面左下隅に割れ目があり，そこをさすっていたら突然落ちてしまった．その後，再起動しても立ち上がらない．外付けHDを外したら起動できた．HDがダメージを受けているとすれば痛手だ．繋ぎ直してみたが，特に問題はなさそうだ．ガラス面の傷は多分触りさえしなければ，なんとかなるとは思うが…気になるので，ついつい触ってしまいそうだ…VAIOのバックアップを取ってみたが，46GBもある．Cドライブには12GBしか空き容量はないので，当然間に合わない．VAIOには256GBのSDカードを装着しているので，それを持ってくるしかないのだが…今日のところはここまでということにして，もう少し（潰れるまで）VAIOを使ってみることにする．

無線マウスも使える状態になっている．タッチパッドは感度を下げてもご動作する．本来デバイス設定でオン・オフできるはずなのだが，ボタンが表示されていないし，アンインストールしても再起動すると戻ってしまう．やはり，上にテープを貼っておくしかないようだ．表題のプログラムに戻ることにしよう．奇数Nが与えられたとき，系図木上の位置を決定するためには，この数字を解析しなくてはならない．通常のコラッツ数列を生成するやり方を使えば，少なくとも木の高さを求めることはできる．しかし，これではカンニングしたみたいでおもしろくない．やはり，正則系図木を生成する手続きの逆手順として実施されなくてはならないと思う．どういう手順になるか？

1. 任意の奇数をNとする
2. (N – 1) / 4 の操作を右端のノードに出るまで反復する　この回数Tを記録する
3. 同一枝の右端ノードをRとする
4. Rに対応する偶数 M = 3R + 1 を求める
5. M / 2 の操作を，反復し，上位奇数N’ を求める
6. これを N = 1 となるまで反復する　この回数Hを記録する

当初設計では，出力の「位置」は．(d, h, b, l) のように出力されることになっていた．

• d はノードの（最大）次数，つまり，d-正則木を構成する
• h は木の高さを示す
• b はNの一つ上の階のノードに接続する枝数合計
• l はNの親ノードに接続する同位ノードの個数

しかし，この設計はあまりよくないと思う．というのは，bの値は通常相当大きなものになってしまうからだ．実際，この値はd^(h-1)のオーダーになる．むしろ，ポジションを数列のような形式で表した方が実用的であるように思う．つまり，上記手順でT(1), T(2), …. T(h)を逆順に出力し，

{ (T(h), T(h-1)), …., T(2), T(1) }

のようなことを意味する．これは言ってみれば，市街のある地点に地番を振るようなやり方に似ている．郵便番号方式，あるいは，IPアドレスの振り方などにも似ている．たとえば， 67という数の場合のTは｛1, 2, 1, 2, 1, 1, 2, 1｝のようになるから，アドレスはこれを逆順にたどって，

1.2.1.1.2.1.2.1

のように表記されることになるだろう．この数列を見れば，その奇数が正則木上のどの位置に配置されるかは，木の全体図を見なくても決定することができる．木の高さというのはこの数列の長さであり，l は T(1) に他ならない．b の値をこの数列から推計することができるだろうか？当然できなくてはならないが，ちょっとややこしい計算が必要になりそうなので，ここではパスして先に進むことにしよう．