グラフ理論ではグラフ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版で実施した修正の同期を取っておこう．多分まだ差分が少し残っているはずだ．
- TOPOLOGY::ClearTableで参照番号不整合が発生したとき ⇒ すでに止めてあるが，「コラッツ対応版応急措置＠20211219」というリテラルで明示する
- SearchCard.vbのSearchCommand_ClickでMakeSearchSelection ⇒ すでに止めてある，この修正は恒常的なものであるように思われるので，現状のままとする
- SelectCard.vbのSelectCard_KeyDownをまるごと止める ⇒ すでに止めてある 現状のまま
- SelectCard.vbのSelectCard_Moveをまるごと止める ⇒ 現状のまま
- SelectCard.vbのProcessDialogKeyは活きている ⇒ 現状のまま
- NAMEBOX::Drawで人名枠高が世代高を超えた ⇒ コラッツ対応版応急措置＠20211219」で止める
- MARGBOX::makeGoodSonの冒頭で「つねに中吊りする＠20211216」でゼロ復帰 ⇒ コラッツ対応版応急措置＠20211219」で対処
- class COUPLINGの定義でclass PAGESETUP *pagesetupをprotectedからpublicに暫定修正 ⇒ 「仮修正@20211216」で対処
- 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箇所くらいで発生している．かなりいい感じになってきた．