月: 2022年3月

『コラッツ木からすべての３倍数を除去したグラフをコラッツ完全木，コラッツ完全木上のノードをコラッツ数とする』これがコラッツ完全木の直截な定義だ．いや，まさかそんな単純なものであるとは思わなかった．コラッツ完全木上のすべてのノードNは，

ADR(N) = X1. X2. X3….Xk ：Xi は任意の正数，kも任意の正数

のような任意の長さのアドレスコードで位置を特定することができる．アドレスコードからノード番号を求める関数をADR2NUM(アドレスコード)とすると，コラッツ予想問題を解決するためには，以下のような定理が成立することが必要かつ十分である．

コラッツ定理：アドレス→ノード番号変換関数ADR2NUM(A)は任意のアドレスコードAとコラッツ数Nを１対１に対応させる写像である．ADR2NUMの逆変換をNUM2ADR(N)とすると，NUM2ADRは任意のコラッツ数NからアドレスコードAへの１対１写像である

我々がすでにほぼ出口に差し掛かっていることは明らかだろう．コラッツ木からはあらかじめ偶数つまり，すべての２倍数が省かれている．言い換えれば，コラッツ完全木とは２倍数と３倍数を除去したコラッツグラフであると言える．コラッツ木から２倍数が除去される根拠は任意の偶数Mを2で除する操作を繰り返すことによって，必ずあるユニークな奇数（１を含む）に帰着するという理由による．同様に３倍数Tが除去される根拠は3T+1がつねに偶数になるという理由によると言えるだろうか？

確かにこれは直観的には明らかであるようにも思われるが，根拠としては薄弱である．もし，それが可能であるとすれば，以下のような定理が数学的帰納法によって証明できなくてはならない．（ここでは「コラッツ数」とは１から到達可能なコラッツ経路が存在することとする）

前提：ある任意の素数Pより小さい素数はすべてコラッツ数である
帰結：素数Pより大きい素数で最小のものをP’とするとき，素数P’はコラッツ数である

これを言い換えると，すべての整数を含むコラッツグラフから，2倍数，3倍数，5倍数，7倍数….を除去したグラフは連結であることを証明せよ，ということになる．2倍数および3倍数をグラフから除去してもグラフの連結性には変化がないことは容易に示せるが，それよりも大きい素倍数を除去したときにどうなるかは自明ではない．このことは逆に，偶数と３倍数を含む任意の自然数を標識するアドレスコードシステムが可能であることを示している．実際それが可能であることは「詳細付番」を含むユニバーサルアドレスコードシステムとして確立された．

この「ユニバーサルアドレスコードシステム」を今後はユニバーサルコラッツアドレスコードないし，コラッツアドレスコードと呼ぶことにしよう．上記のコラッツ定理はもちろん，コラッツアドレスコードと（偶数を含む）任意の整数との相互変換について成立しなくてはならない．aを３倍数を除く奇数，ｂを３倍数，eを偶数とするとき，詳細付番には，a-b, a*e, a-b*eの3種のパターンがあり，かつそれ以外のパターン，たとえば，a-b.a’やa*e-bは存在しない．

我々はすでに「コラッツ国の公用語は４進数である」ということを知っている．つまり，「自然数Nの名前を４進数で表記すると，Nの名前の中にはNの親Pの名前と兄弟順位が埋め込まれている」ことを示すことができる．しかし，ここで一つ問題が発生する．「コラッツアドレスコード」ではコラッツ数の兄弟順位と非コラッツ数つまり，3倍数の兄弟順位を別建てで計算している．おそらく，このことが「三本桜」を復活させようとする試みの動機になっているのではないか？と推定する．まだ過去ログを読み切っていないので，もう少し読み続けることにしよう．

2月26日の記事に，『我々の方法の中でもっとも重要なポイントはやはり「長子ノードの発見」ということにあるのではないだろうか？』とある．これは，ノード番号の16進数表記を解析して，標識の上位ビットが長兄ノードのバイナリ表現，下位ビットが兄弟順序数を示すことを突き止めたあとに書かれたテキストだ．これを受けて，「我々の提案の中には，①一般コラッツ木，②コラッツ長子木，③コラッツ完全木という三種の木構造が含まれているが，これらのうちのどの一つも説明/証明に欠かすことはできないように思われる」と結論付けている．つまり，これが「三本桜復活」の動機である．翌日のタイトルは「山の八合目からの眺望：８進数で眺めると」で，その翌日が「小学校入学記念写真は三本桜の下で撮影する」だった．

ここで問題になるのは，長子ノードのバイナリ表現を親ノードのバイナリ表現に変換する方法だ．ノード番号を16進ではなく4進表記すると，

兄弟ノード番号＝長子ノード番号＋1の並び

のようになる．長子ノード番号は親ノードから引き継いだDNA配列を示していると考えられるが，子ノード番号をNとして，3N+1を2進数表記してやると，この遺伝子コードを解読することができる．つまり，

子ノードNの３N+1バイナリ表現＝親ノードのバイナリ表現＋0の並び

のようになっている．この計算を実行する代わりに3進数表示してみたらどうなるか？というのが興味の焦点だ．この実験を行うためにはやはり，長子木を任意に出力できる仕掛けが必要になってくる．この辺りは，3月3日の「コラッツ国の公用語は４進数である」にまとめられている．ここで企図した実験を効率的に実施するために，ゼルコバの木の「横書き」機能拡張が導入された．横書き機能はほぼ実装を完了したが，まだ少しバグが残っているようにも思われる．これを完全に潰してから「三本桜」に進むのが順当だろう．

未公開だが，コラッツ木ジェネレータ最終版のタイトルは，Collatz Complete Tree Experiment（コラッツ完全木検定）となっている．「完全木」とは「完全正則木」を略したもので，英訳すれば Full regular tree になる．正則グラフとはグラフのすべてのノードの次数（隣接する頂点数）が等しいものを言う．有限木の場合には必ず次数1の終端ノードを持つから正則木というときには，「終端ノードを除き」という追加規定が入る．ただし，完全正則木と言うときには終端ノードは木の最下層（最上階）にしか現れないものと仮定する．一般コラッツ木では3倍数が木の各所に現れるので，完全正則にはならない．

どうも，開発者であるわたし自身の中で「完全木」と「仮想木」の違いがあいまいなものになってきている．コラッツ仮想木とは，別名「コラッツ長子木」と呼ばれるもので，一般コラッツ木上の親ノードを共有する「兄弟ノード」を最上位の「長子ノード」1点に集約した簡約グラフを意味する．3倍数も長子ノードとなることはあるが，その下には兄弟ノードの子ノードが配置されるので，終端ノードにはならない．この意味では仮想木は完全正則であると言える．

▲コラッツ完全木検定のA面で1-3-4の設定で生成されたコラッツ木のCSVをインポートしようとして，「入力文字列の形式が正しくありません」というエラーになった．

開くファイルを間違えていたかもしれない．生成されたCSVはCollatzTree.C.csvだが，別のファイルを開いていた可能性がある．実際，”CollatzTree.C.csv”は正しく開けた．多分ZEL形式のCSVを開いていたのだろう．デスクトップ上にある，CollatzCore.CSVを開くとこのエラーが出る．CollatzTree.CSVでも同じ．CollatzTree.CSVはこれまで何度もインポートしていたような気がするのだが…テキストエディタで開いてみると確かに，これらはZELの一覧表形式CSVだ．⇒間違え易いのでZEL形式CSVは別のフォルダに移動した．

▲隣接リストCSVをインポートするとき，中間的にZEL形式CSVが生成されている．これは作業用の一時ファイルなので使い終わったら削除しておく必要がある．⇒このファイルは動作確認の意味を含めて温存していたが，「一般的な（順序不定の）隣接リストで正しく動作する」ことが確認されれば削除されるべきだ．

コラッツ完全木と仮想木の相違点がわかった．下図で左が仮想木，右が完全木と称するものだ．どちらも1-3-4という設定で出力したものだが，前者が41点に対し，後者は121点ある．

　　　　　　　

後者は厳密に完全３元木になっているが，前者では１階層目に１個しかノードが存在しない．確かに，これが「仮想木」という構成の特異な点だったのを想い出した．この５というノードの特殊性はコラッツ木を理解する上では重要なポイントであり，おそらくこの点を強調することが，三本桜を復活させる動機の一つになっていたのではないかと思う．ログをもう少し読んでみればその辺の事情もわかってくるだろう．

もう一つの用語として「コラッツ核木」ないし「コラッツ中核木」というのが出てくるが，これはコラッツ長子木の別名と考えられる．つまり，コラッツ仮想木＝コラッツ長子木＝コラッツ中核木と考えられる．いずれかに統一するとすれば，コラッツ長子木というのがもっとも直感的なのではないだろうか？「長子木」は「長子ノード」のみで構成される系図木であるという説明は，「なぜ仮想木と呼ばれるのか？」あるいは，「なぜ中核木なのか？」を説明するよりわかり易いような気がする．「仮想木」と呼んでいるのは，仮想木上のノードを接続する枝が，「コラッツ写像」を直接反映した「実像」になっていないためだ．

「長子ノード」はときに「コラッツ数」と呼ばれることもある．コラッツ数として区分される整数の集合が，コラッツ木の骨格であり，それ以外は葉肉であるというのが「コラッツ中核木」の由来と考えられる．ルートが５であるようなコラッツ中核木（の部分木）を考えると，これは完全正則木を構成可能である．つまり，コラッツ中核木からノード１を除外した部分木は完全正則木の条件を満たしている．

しかし，我々の「コラッツ完全木」はノード１を含んでいる．その構成原理を明示しなくてはならない．⇒その前に「コラッツ放射高速道路系」という概念が登場する．「木」は通常「ルートノード」を根とする樹状の図形として描画されるが，ルートを中心とする放射線路系として描画されてもよい．この意味ではコラッツ木とは１/５を始点として放射線状に投射される交差しない数直線の集合とみなすことができる．

ルート５から投射される放射線は無数にあり，１本の放射線上には無数の点がある．これらの無数の点はそれ自体が放射の中心点となって全方向に無数の放射線を投射している．５をルートとする完全正則木の終端ノードはすべてルート５から等距離にあると考えられるから，これらの集合は１個の３次元的な球面上にあると言える．この放射線を光線とみなせばコラッツ完全正則木とは１個の光の球体にほかならない．

コラッツ木を「光の球体」とみなす見方はコラッツ木を「ブラックホール」とする見方とは真逆の解釈である．コラッツ光球体の顕著な特性は，球体内部から放射される光線のどの２本も交差することがないという点にある．果たしてそのようなことが可能なのだろうか？ここからストレートに「量子論的な世界」に踏み込むというのもやや無謀であり，明らかに本論の範囲を超えるものである…

ログを日付順に読むと，コラッツ核木→コラッツ放射高速路系→コラッツ仮想木→銀河高速道路系のような展開になっている．銀河高速道路系では一般コラッツ木を一般道路として位置付け，それと並行する幹線路として仮想コラッツ木を対置している．この比喩は一般道路から高速路への乗り換えなどの連想が効くので理解し易いのではないかと考えた．

2月6日のログには「有効ノード率というのは，最大枝数と樹高を同じ値に設定したときの仮想木と一般木のノード数の比率を表すものでこの値が3/4に収束することは間違いないように思われる．」という記述が見える．この値は「コラッツ数と奇数全体の比率」を表すものであると考えられるとしている．

2月20日付けで「完全正則コラッツ木を構成するためのもう一つの方法」という提案が出てくる．「もう一つの方法というのは至って単純なもので「3の倍数ノードを一律除去する」というだけだ」というのだが…この方法の利点は「3よりも大きい素数が必ず含まれる」という点だ．「3の倍数ノードを除去したコラッツ木には一般道路と高速路という区別は存在しない」ため，「コラッツ銀河高速銀河系」というイメージは放棄され，「仮想木」という概念も破棄される．ここで「コラッツ放射線道路系」というイメージが浮上してくる．このイメージは上記の「コラッツ放射高速路系」に類似しているが，同じではない．

ここで初めて，「コラッツ完全正則木」という概念が確立したと言ってよいのではないか？この時点では別名として「コラッツ中核木」というネーミングが提案されている．ここではコラッツ中核木＝3倍数を含まないコラッツ木ということになっている．A面のオプションが「Core tree」となっているのは，この構想を反映している．2月22日に初めて「コラッツ完全木検定」という「製品名」が出てくる．

3倍数は木の終端にしか現れないので，アドレスコードをアレンジしてアドレスコードの末尾に3倍数ノードを付加するような形式に拡張することができる．たとえば，1.2.3.4.5-6で親ノードの6番目の3倍数というポジションを表記できる．もう一つのコード形式として1.2.3.4.5.-6というのも考えられる．負のコードは3倍数であることを示すものだ．これでコラッツ木上の位置を地番として表記できるようになる．英語では地番を lot number ないし parcel number という．parcelは小包という意味だ．郵便番号やIPアドレスなどとも共通する．

これをさらに拡張して偶数を含むすべての整数にアドレスコードを付与することが考えられる．たとえば，1.2.3+4とすればよい．⇒最終的には1.2.3*4で偶数を表記するようになった．これを「詳細付番」と呼んでいる．詳細付番には，a-b, a*b, a-b*cの3種のパターンがある．これですべての整数にユニークな地番を付すためのユニバーサル・アドレス・コードシステムが確立した．実装はすでに完了している．

少しだけ歩行距離を伸ばした．スマホを持ち出していないので正確なところはわからないが，3000歩くらいは行ったのではないだろうか？桜も「ほころび始め」どころか，すでに「七分咲き」という感じになっている．「三本桜の実装」に移る前に，これまでの暫定修正をフィックスしておこう．だいぶペースが落ちているが，ぼちぼちと行くことにする．冬物のもこもこスリッパを履き捨てて（と言っても来年もまた履きますが…），夏物に変えた．（去年使っていた）ダイソーのスリッパは流石に作りが悪くあちこち縫い直した（一部はボンドで仮補修）．

一通りフィックス完了した．いよいよ三本桜の復活に進むという段だが，だいぶ離れていたのでカンが鈍くなっている．少しログを読み直しした方がよいと思う．この構想の発端は「ユニバーサルコードシステム」というアイディアがでてきた辺りと思われるので，2月下旬まで遡らなくてはならない．コラッツ木生成ツールの最終ビルド日付は2月26日になっている．マニュアルの更新日付を見てみよう．というか，その前にバックアップを整理して開発履歴が見えるようにしておく必要がある．今回導入した2TBのHDDはそのために購入したものだ．

コラッツプロジェクトには現在3つのバージョンがある．

1. CollatzComplete　最終ビルド：2022/02/26　V2.2.1
2. CollatzCoreTree　最終ビルド：2022/02/22
3. CollatzMilkyway　最終ビルド：2022/02/20

わたしの感覚ではCollatzCoreTreeの方が古いような気がするのだが，違うのだろうか？走らせてみればわかるだろう．CollatzComplete が一番新しいものであることは確かだ．V2.2.1でRel 22/02/26となっている．A面のオプションがFull regularとなっている．つまり，完全正則木を生成するというオプションだが，完全正則でない場合には何を出力するのだろう？⇒少し動かしてみればわかる．Full regularでない場合には3倍数は終端ノードになるが，Full regularの場合にはそうならない，つまり完全正則木が出力される．

CollatzCoreTree はV2.0.1でリリース日付は22/02/11，タイトルはCollatz  Milky Highwayとなっている．この版ではA面のオプションはCore treeとなっている．コラッツ中核木という意味だが…コラッツ中核木では無効ノードが発生しているので，完全正則ではない．1-3-4という設定でビルドしたとき，中核木では有効ノード数41となるのに，中核木オフの場合には46になる．どうも開発者本人すらどういう仕様になっているのかよくわかっていないようだ．

CollatzMilkyway バージョンもV2.0.1 Rel 22/02/11となっていて，CollatzCoreTree とまったく同じだ．ただし，A面のオプションはVirtual Treeとなっている．ただし，名前を付け替えただけで動作的にはまったく同じように見える．タイトルも同じCollatz  Milky Highwayだ．ただし，B面の枝番号数列はコンマ区切りで，CollatzCoreTree になるとそれがピリオド区切りに変化する．ピリオド区切りの方が新しいので，上記リストの順序は妥当なものだろう．

バックアップからマニュアルの原稿を探してみよう．マニュアルの最終版は2022/01/29のCollatzTreeGeneratorManual.pdfのようだ．ownCloudにアクセスしてPDFのバージョンをチェックしてみよう．

ED:1.02 Ver1.1.5 Rel 2022-01-19で確かにこれが最終版と思われる．マニュアルで参照している画像で判断すると，このマニュアルはCollatz Regular Tree Generator V1.1.3 Rel 2022/01/26ということになる．つまり，1月26日以降の修正はマニュアルには反映されていない．少なくともタイトルがCollatz Milky Highwayに変更されたあとの版はまったく未公開ということになる．状況はある程度つかめたような気はするが，ログの読み直しは1月下旬まで遡る必要がありそうだ．

2月17～19日に要対処項目125件というのを拾い出している．これも改めてチェックし直さなくてはならない…1月25日のログのタイトルは「マニュアルはほとんど仕上がった」だ．プログラムの公開版の日付が1月26日となっているので，このころにはプログラムはほとんど仕上がり，マニュアル編集に専念していたものと思われる．併せてかなり長時間のランニングテストを実行している．また，マニュアルの印刷というのも試している．処理速度を計測するためのベンチマークテスト，用語の統一というのも重要なポイントだ．

ZELファイルをダブルクリックで起動してエラーになるという案件がある．ちょっと寄り道になるが，確認しておこう．まず，アプリをインストールする必要がある．

▲最新版ではゼルコバの木フォーマットでエクスポートする機能を廃止して，一般的な隣接リスト出力をゼルコバの木でインポートするという仕様になっている．このとき，隣接リストにはノード番号が記録されているが，インポートした時点でこれを整数範囲内の参照番号に変換（ハッシュ化）している．今のところこれで問題は発生していないが，一般的な（順序不定の）隣接リストで正しく動作するかどうかを調べておく必要がある．

▲CollatzTree 3-5-94.zelのアイコンをダブルクリックしてオープンしたとき，「基準ノード不在」エラーが発生する．描画は可能だが，画面には図面の一部しか表示されていない．データはすべて読み込まれているようだが，再描画しても是正されず，ズーム倍率を変えたりしても一部が切れる現象は残る．⇒いや，倍率100%では完全に描画できた．横書き対応のクリッピングにまだなにか問題が残っているようだ．

最終公開版はV1.1.4 Rel 2022-01-27のようだ．このパッケージを確保しておく必要はある．

▲3倍数が終端ノードとなるコラッツ木で無効ノードカウントを事前に計算する計算式を立てる．（今回の修正が完了するころには容易に書き下ろせるようになっているだろう…）

今日の閲覧数が376という驚異的数字になっている．どうしたのだろう？通常，この数字は今日の訪問者数＋1～3程度のものだったのだが… つまり，ほとんどの訪問者は最初に開いたページから移動しないで離脱するというのがこれまでの常態だったのだが…

考えられる理由としては昨日の投稿のタイトルが「非公開投稿」とあったのをなにか勘違いして，どこかにトップシークレットが漏れているのではないかと思って探し回ったため，くらいのことしか思いつかない．

暖かくなってきたので，昨日からまたウォーキングを再開した．スマホは持ち出していないので歩数はカウントできていないが，かなり短い距離しか歩いていない．おそらく2000歩は超えていないのではないかと思う．去年の冬，ウォーキング休止になる前の歩数が5000歩くらいだったと思うので，その1/3くらいの距離だ．なんとかまだ歩けるだけでもうれしい．少し歩いていれば5000歩くらいまでには回復できると思う．

さて，そろそろクリップ領域の問題にケリを付けることにしよう．クリッピングでは，①現在のクリップ領域と描画の対象となる矩形領域の論理和を取って描画を実行し，②そのあと元の状態に戻すという操作を行っている．②の操作でRGN_COPYモードでSelectClipRgnを実行するとき，第一引数を空にしてやれば問題なく描画することができる．これで事実上描画できているし，それによる実害というのも特に考えられないので，とりあえずはこのままでもよいと思われるのだが，もう少し突っ込んでみたい．⇒問題は以下の3行だ．

SetClipRegion(pdc, crect, RGN_AND, &oldrect);　（１）
DrawNameText(pdc, Frame);
SetClipRegion(pdc, oldrect, RGN_COPY, NULL); 　（２）

しかし，このパターンはここにだけ現れるのではない．少なくとも以下の複数箇所で同じパターンが使われている．しかも，縦書きではこの論理で通っているのだから，その論理が横書きで通らないということは考えられない．というより，問題だ．

1. NAMEBOX::DrawName
2. Bobject::DrawTextBox
3. Bobject::DrawTextLine
4. NAMEBOX::DrawImage
5. PAGESETUP::PrintPage
6. TITLEBOX::Draw

（１）式ではクリップ領域を取り出し，（２）ではそれを書き戻している．（１）ではoldrectをGetClipBoxで取り出している．クリッピングの対象領域crectは論理座標単位で_CDC::LPtoDPで物理座標に直交変換している．この矩形領域をCreateRectRgnIndirectでクリップ領域に変換してCDC::SelectClipRgnが実行される．デバイスコンテキストが保持しているクリップ領域は物理単位でかつ直交変換されたものでなくてはならないと考えられる．（１）と（２）の内部処理は共通でいずれの場合もCDC::SelectClipRgnが呼び出される．

どうも解決したようだ！（１）で取り出したoldrectを直交変換して保持するように修正した．これでよいのではないかと思う．この動作から推定すると，GetClipBoxで取り出される矩形領域は（明示されていないが）論理座標系であると思われる．Bobject::SetClipRegionはBobject::setClipRegionのラッパになっているので，この部分は親のSetClipRegionで実行するように切り分けておくことにする．

これでようやく三本桜の実装に移ることができる．三本桜とはコラッツ木のバリエーションで，①一般コラッツ木，②仮想コラッツ木（長子木），③完全コラッツ木の3種を意味する．小学校の入学式の記念写真を満開の桜の木の下で撮影するというのは，わたしの母校に限らず日本中の小学校で行われていたようだが，年々桜の開花日は早くなっている．今日のコースには桜土手が一部含まれていたのですでにかなりほころび始めているのが確認されたが，桜が満開になるまでにこの改修を完了できるかどうかは確言できない…まぁ，やることは決まっているので，それほど手間取ることもないだろうとは思う…

非公開投稿というのが可能なものかどうかを確認してみよう．投稿カテゴリには「テント村」と「未分類」の2つがある．多分後者は非公開になるのではないかと思う．やってみよう．いや，どうも単純に公開されている．下書きとすれば非公開になる．投稿オプションには下書きとして投稿という選択肢がある．しかし，下書き投稿したものをブラウザで見るためにはログインすることが必要だ．それも結構面倒くさい．ログインして編集するのならそもそもOpen Live Writerを使う意味がない…

なぜこんなことを考えたかというという，進捗が止まって足踏みの状態が続いているため，思いのままに気楽にロギングするという感じがつかめないためだ．読者を意識しないで書くとすれば，非公開という方法しかない．これまではそういうことまでは考えたことがなかったが，思考力や根気の衰えというのは隠しようもない．もしかすると，ロギングに使っているノートを右手に配置するというのが効果があるかもしれない．これは最後の手段と思われるが，藁にもすがってみよう．

悪くないような感じはするが，それほど効果的であるような感じもしない…フルキーボードには右にテンキーが並んでいるので画面から却って遠くなり，余分なストレスが生じるような気もする．キーボードの前面に配置するのが一番楽であることは確かだ．いっそのこと，キーボードとモニターの中間に置くというのも考えられないではない．かなり無理な感じはあるが，ロギングを作業の中心と位置付けるのならあり得ない配置ではない．⇒ただ，少しやり過ぎの感はある…

やはり，ロギング用のノートは左配置しかないような気がする．この配置に慣れてしまえばよいのではないだろうか？⇒それしかないような気がする．今のところは，これがベストと考えるしかなさそうだ．ともかく，しばらくこれで行ってみることにしよう．

何が問題なのか？それが問題だ？一言で言えば横書きにしたときのクリップ領域の問題だ．これまで縦書きでは問題は起きていないと考えられるいので，これは「横書き上の問題」であると言える．また，クリッピングをまったく行わないようにすれば描画可能であるところから，クリップ領域の問題であるとも言える．確かに，「横書き」という設定には多少の問題があることは確かだ．横書き座標系という座標系は存在しない．というか，少なくとも静的なデータとしては保持していない．内部座標系は論理座標系であり，この座標系は本来縦書きで用いられてきたものだ．縦のものを横にすれば横書きになるというのは確かであり，実際その方法で描画可能になっている．

縦のものを横にするという「変換」は描画を実行するプリミティブな関数のところで走行時に直接実施される．物理座標系はウィンドウ座標系であり，座標単位はピクセルである．クリッピングを実施するときには，その直前の状態を退避して，事後に書き戻すような動作になっている．このとき，①元のクリップ領域が復元されない，②描画時にクリップ領域の論理和を取る演算で領域空が発生する，という2つの問題が発生している．まず，①の問題から見ることにしよう．⇒すこしいじり過ぎてしまったようだ．一度バックアップに戻って安定したところから再開することにする．2022-03-17まで戻ることになった．この版ではゼルコバの木3.zelがエラーなしに描画できる．

これよりあとの版ではエラーが出る上，画面の一部が欠けてしまうなどの不具合がある．この図面は横書きに取り組んだときに最初に扱ったもので，結局スタート地点まで戻ってしまった．ともかく，ここから出直すことにしよう．3月17日のログでは最初に「reverseAxisの参照箇所をDrawingObject.cppに集約」するということをやっている．とりあえずこれはやっておくことにする．この日のログには「インポートしたときの図面に系線や人名が表示されないという問題」があるとしているが，少なくともこのサンプルでは問題なく描画できている．なぜだろう？⇒いや，確かに起きている．「インポート」が再現の条件だ．

ログにあるように「Bobject::setClipRegionでつねにpdc->SelectClipRgn(NULL)とすれば描画可能」であることは確かだ．3月21日のログには，「RGN_COPYには第一引数をNULLにしてSelectClipRgnを呼び出すようにすれば，正しく動作する」とある．⇒確かにそのようだ．ただし，Bobject::setClipRegionの中でクリップ領域をLPtoDPするとき，直交変換しないようにすると描画できなくなる．つまり，少なくともここでは直交変換が必須であるように思われる．ともかく，ここから始めるしかない．腰を落ち着けて取り組むことにしよう．

開発機のドライブEから外付けHDDへの転送は3日越しになった．99%まで完了しても，残り時間はまだ5時間15分もある．1GBの転送に6時間というのは流石に遅いのではないかという気がする．今となっては手遅れだが，SSDという選択肢もあったのではないだろうか？SSDでは2TBを超える大容量のドライブというのは見当たらないし，価格もかなり高い…まぁ，当面はこれで行くしかない．

BlackHawkのCドライブが逼迫している．容量は27.8GBで空き領域は2.75GB．ユーザデータはCドライブに置いていないのでこれ以上削減することはできない．最後の奥の手としてドライブを圧縮することにした．これまで圧縮ドライブというのは一度も使ったことがないが，背に腹は変えられない．かなり時間は掛かりそうだが，完了すれば数GBくらいの空き容量は確保できそうだ．うまく行けば10GBくらい空くかもしれない．※⇒最終的には4GB程度しか確保できなかった．

リムーバブルドライブとして使っていたUSBメモリの中身を一旦外付けに移して空にすることにした．64GBのメモリが2つある．1本はすでに転送完了しているが，もう1本は転送だけで丸一日掛かりそうだ．フォーマットもクイックでない正規のフォーマットではかなりの時間が掛かるが，まだこれからも使うものなので，やっておいた方がよいと思う．2本目の転送量は58.5GBで残り時間16時間とある．いずれ今日中には終わらない．フォーマットの方はあと1/3になったので，2,3時間後には完了するかもしれない．ドライブの圧縮の方はまだ，1/3程度の進捗だ．

※ELECOM製USBメモリ58.5GBの転送はあまりうまくゆかなかった．History.IE5のようなファイルが残ってしまうことが原因で空にできないフォルダが相当数残ってしまった．これらは主にマイクロソフトなどの外部アプリに関係するものなので，それらを残したままフォーマットを掛けた．正規のフォーマットを実行しているので完了までにはまだだいぶ時間が掛かりそうだが，これで大体の整理が完了したと言える．

ヤマダ電機からは5日前（15日火曜日）に出荷したというメールが入っていたにも関わらず，日曜日になっても届かない．配送番号を手がかりにネットで検索してみると，「宛先不明で預かり」の状態になっていた．「お問い合わせください」となっていたので佐川急便の営業所に電話を入れてみると，確かにそういう状態になっていた．電話は掛けているが，「現在使われておりません」になったという．あとでヤマダ電機の会員登録をチェックしてみたら確かに古い番号のままになっていた．

「今日は最終便の手配がすでに終わっているので明日になります」というのをねじ込んでなんとかその日のうちに届けてもらう．担当はまだ入ったばかりという中学生みたいに小柄なドライバーで一言言ってやるつもりだったが，何も言わなかった．宛名はプリンタで印字されたものだが，部屋番の2Hが行の末尾で右左に別れてしまったため，配達員には「コーポEMI 2」までしか読み取れなかったのだろう．改行が語句で区切ってあればこのような事故も発生していなかったはずだ．製品は5TBということになっているが，実際には4.5TBくらいしかない．仕様書には4GB以上となっているので，まぁこういうものなのだろう．

５TBというのは流石に大きいのでパーティションで仕切った．サイズはまちまちで，1.9TBx1，976GBx2，750GBx1という感じになった．開発機のEドライブの内容を外付けに移動しようとしたが，丸一日掛けても半分も終わらない．2つのサブノートは完全スキャンが大体１時間で完了するくらいまで軽量化したので一応目標はクリアできた．この転送が完了すれば開発機もその程度には軽くなるだろう．このHDはほぼバックアップ専用で普段は外しておくことになるのではないかと思う．

さて，ともかく横書きの不具合を片付けてしまわないことには始まらない．Bobject::setClipRegionでつねにpdc->SelectClipRgn(NULL)とすれば描画可能なので，クリッピングに問題があることは確かなのだが…⇒やはり，問題はRGN_COPYでクリッピング領域を元に戻す操作がうまく行っていないようだ．RGN_COPYには第一引数をNULLにしてSelectClipRgnを呼び出すようにすれば，正しく動作する．

机上のモニターの配置を少しアレンジしてみた．主たる作業には正面のワイドモニターを使うという基本は同じだが，サブノート２機の配置を入れ替えてみた．ログを付けるというのは作業を円滑に進める上での最大のポイントなので，これがまったくストレスなしにというより，何も考えずに移行できるようになっていなくてはならない．現行では，①ネットアクセス・メール送受→BlackHawk，②ログの編集・投稿→VAIO2，③プログラミング→FireBirdという割当てになっている．

これまでは①が②と③の中間に配置されていたが，②をメインスクリーンの近くに寄せて，視線の移動距離が小さくなるようにしてみた．この配置ではVAIO2のキーボードは使えなくなるので，撤去することになる．つまり，ほとんどすべての作業を正面のキーボードだけで行うようになる．これでよいのではないだろうか？

細かい点だが，いくつか余分な手間を掛けているポイントがある．①スマホのカメラとGoogleのPhotoは同期しているので，アップロードする必要はない，②ブラウザの表示は適当なタイミングで更新されているように思われるので，再描画しなくともよい．項目②の動作はあまり確かではないが，ムキになって再描画しなくてもよい（放置しておけばそのうち同期するだろう）という趣旨だ．ともかく，「頭に浮かんだことはその次の瞬間には画面上に表示されている」ことが必要だ．

さて，昨日の問題に戻ろう．インポートしたときの図面に系線や人名が表示されないという問題だ．縦書きでは動作しているので，横書きの実装によって起きていることは確かだ．横書きの実装に関わる修正はできるだけ複数のソースファイルにまたがらないようにしているが，reverseAxisの参照箇所をDrawingObject.cppに集中しておこう．移動した関数は以下の4つだ．

1. TREEVIEW::DrawControl
2. NAMEBOX::getViewFrame
3. NAMEBOX::DrawName
4. Bobject::SetFontOrientation

クリップリージョンが関係している可能性がある．⇒確かにそのようだ．Bobject::setClipRegionの冒頭でBobject::setClipRegionで復帰すれば描画できる．⇒Bobject::setClipRegionから呼び出しているCDC::SelectClipRgnで直交変換を実施しないようにすると，縦書きと横書きの表示が同じになる．つまり，人名枠と系線は表示され，人名は表示されないという状態になる．この方が状態としては良いような気がする．ただし，インポートでは，SelectClipRgnの戻り値が「新しいクリップ領域は空です」という値になっている．RGN_ANDでクリッピングしているので共通領域がないということになる．

やはり，どこかおかしい．SetClipRegionで対象矩形領域を直交変換してからSelectClipRgnを実行するようにして，ZELからの呼び出しの場合は正しく動作するようになったが，インポートでは元の状態に戻ってしまった．ZELを読み込んだ場合と，インポートで異なるフローを通っているということだろうか？⇒まったく表示されていないという訳ではない．画面上部のほぼウィンドウ枠サイズの領域には描画できる．_CDCを参照している箇所を拾い出しておこう．

1. COUPLING::SetTitleBox
2. COUPLING::SetTitleBox
3. TREEVIEW::BuildBitMap
4. Bobject::DrawJoint
5. PrintNumber
6. Bobject::Nprint
7. Bobject::DrawTextBox
8. Bobject::DrawTextLine
9. NAMEBOX::DrawImage
10. TREEVIEW::Refresh
11. PaintCircle
12. TREEVIEW::GetAutoZoomRate
13. PAGESETUP::getViewSizeInmm
14. PAGESETUP::PrintImposition
15. PAGESETUP::PrintPage
16. TREEVIEW::GetTitleRect
17. TREEVIEW::GetFrameRect
18. TREEVIEW::CenteringBox
19. TREEVIEW::GetDrawSize
20. TREEVIEW::DispFrameRect
21. TREEVIEW::GetWheelPosition
22. TREEVIEW::CenteringMove
23. TREEVIEW::GetFramePosition
24. TREEVIEW::GetScrollValue
25. TREEVIEW::GetCenterPoint
26. TREEVIEW::CenterPostMove
27. TREEVIEW::DPtoNormal
28. TREEVIEW::CallCenteringMove
29. TREEVIEW::getOyaFrame
30. Bobject::setClipRegion
31. TREEVIEW::LimitSizeOver
32. TREEVIEW::MouseEnterBox
33. TREEVIEW::LButtonDblClk
34. TREEVIEW::LButtonDown
35. TREEVIEW::LButtonUp
36. TREEVIEW::MouseMove

ヤマダ電機からのメールでは昨日の日付で出荷となっているので，今日中には入荷するのではないかと思う．これが入ったからといって世界が一変するものでもないが，待ち遠しい．なぜだろう？VS2017が立ち上がってこない．管理者権限を持たない通常の起動なら立ち上がってくる．⇒再起動して立ち上がるようになった．

開発機を起動したら，Windows 11インストールのプロンプトが出た．アップグレードした方がよいのか？悪いのか？ネットでチェックしてみる．Windows 10のサポート終了は2025年10月なのでそれまでは使える．ファイルのコピー・ペーストなどの基本操作が使い難いという話もある．とりあえず，今日のところはパスしておこう．

仮修正は一通りフィックス完了しているが，2021年以前の古い修正もあり，かなりの部分が「保留」として残った．横書き対応修正は一応完了しているので，いよいよ三本桜の復活に進むところだが，その前に描画までの時間をもう少し短縮できないものかどうかを確認しておきたい．VerifyTest 2^11 3236.zelは3336点というゼルコバの木としては特大図面に当たるが，初期画面が出る前にマネージドデバッグアシスタントのブレークが入ってしまう．ここまでですでに1分掛かっているが，系統並び替えまでにさらに2分掛かり，さらに1分でようやく描画になっている．⇒この修正はかなり大掛かりなものになりそうなので，後回し．

▲ZELファイルは正しく描画されているが，隣接リストのインポートではほとんど図面になっていない．拡張選択するとカードが反転表示されるので，画面には表示されているようだが，カード#1を除くと枠線も出ない．一覧表には511点のデータが表示されている．縦書きなら描画できる．なぜだろう？見当もつかない…

アマゾンから購入した中古品のWiFi HDDは速攻で返品することになった．アマゾンの返品手続きは明快かつ迅速で，製品を再梱包し，宛名ラベルを印刷したものを貼り付けて，0800-0800-111に電話すると最寄りの郵便局から集荷に来てくれる．伝票も集荷に来た職員が代筆してくれた．返品理由は①スマホにインストールしたministation2アプリから本体にアクセスできない，②バッテリの充電が4時間以上（丸一日）掛けてもフル充電にならないばかりか，かなり発熱するという2点だ．

スマホの設定→WiFiの画面では接続できていることが確認されているのに，アプリでは「接続してください」が表示され，それ以上前に進めなくなる．ネット上にもこの種の不具合は報告されていて，製品交換で解決したという事例もあるが，今回のケースは中古品なのでそれもできない．添付されてきた充電用とPC接続用のUSBケーブルは2本とも新品だったので，多分これは販売店で補充したものだろう．つまり，ケーブルも紛失したような状態で出品されたものが「ババ抜き」のように回ってきたということのようだ．あるいは，すでに何度も返品されたものを繰り返し出荷している可能性すらある．わたし自身あきらめてこのままただのUSB HDDとして使うことも考えてみたし，お金に困っていればヤフオクなどで転売していたかもしれない…

無線HDDに関しては2年前にも一度購入を試みて返品しているので，今回また同じ失敗を繰り返してしまったが，無線HDDについてのわたし自身の思い込みないし錯誤がその原因の一つであったことは否めない．大容量HDDは家電量販店の棚に山積みになっているが，その用途は主にビデオ録画であり，HDDに保存された録画データを他のデバイスで再生するというのが目的のようだ．HDDに録画データを保存するというのは以前は放送局向けのプロフェッショナルな機材でしか使えなかった機能だが，それがごく普通に日常的に使えるようになったという変化がその背景にある．わたしはそもそもテレビを見ないし，持っていないのでその辺りの環境変化にまったく気づいていなかった．

NASというのはそれとはまた少し異なる流れでRAIDなどを使った巨大データベースの構築というむしろどちらかというとビジネス用途向けの構成と考えられる．わたしの場合，無線HDDと言ってもインターネットに接続して外部からアクセスするなどのことはまったく念頭になかったし，むしろ外部から遮断されたクローズドな環境を考えていたので最初から話が食い違っていた．それを無理やり合わせようとしていたのだが，どうやってもうまく組み合わせることができなかった．USB接続なら1万5千円出せばもっと大容量のドライブを手に入れることができるし，わたし自身の用途・目的を考えるなら，USB HDDを所内LANで共有すれば十分というのが最終結論だ．

結局ヤマダウェブコムで5TBのBAFFALO製HDPGF5.0U3GWHA 16,897円というのを購入することにした．これは本体重量250gというポータブルタイプだ．これまで使っていた東芝製HDTC607JS3A1 750GB 本体147gには十分満足していたので，その代替機になると思う．ポータブルタイプを選択したのは，別のPCに繋ぎ変えるときの便ということもあるが，耐衝撃性では据え置き型より優位なのではないかと思ったからだ．（多分電気代もかなり違うのではないかと思う…）

わたしの感覚では750GBですでに大地主なので5TBならどこかの領主にでもなった気分だが，果たしてこれが何年持つ（続く）のだろう？次の大容量HDDを購入するときには，少なくとも100万人規模の系図データベースをネット上で公開するような仕掛けになっているかもしれない．いや，そうでなくてはならないだろう．24時間以内に発送ということになっているが，今日中に届くというのは無理だろう．ともかく仕事の続きに戻ることにしよう．

すでに横書きで表示できるようになっているが，もう少し手を入れる必要がある．というか，拡張選択の動作がおかしくなっている．

▲VerifyTest 1-2047 1631.zelを開いてマウスをドラッグして拡張選択しようとしたとき，選択枠の表示位置がおかしい．クリック位置から離れた場所に表示され，XYが逆転している．⇒この問題はすでに解決しているはずなのに，ぶり返している．

＿CDC::DPtoLPで直交変換しないようにしたら正常動作した．前のバージョン（2022-03-09-1）を見ると，LbuttonUPで使われているLPtoDPとDPtoLPはどちらも基本クラスのメソッドを呼び出している．実際，両側で直交変換すると元に戻ってしまう．ここは，LPtoDPではオリジナルの関数を使うようにしておこう．⇒いや，その逆のようだ．LPtoDPで直交変換し，DPtoLPではしないとすれば動作する．⇒一応これで動作するようになった．

「クリッピングを一時停止する＠20220310」を調べてみよう．⇒このオプションを外しても問題なく動作している．問題はすでに解消しているようだ．これで大体横書き対応修正は落ち着いたのではないかと思う．一度バックアップを取ってから修正をフィックスしてしまおう．

▲アプリ終了時にメモリリークが検出されている．⇒いや，これは以前から出ていたもののようだ．少なくともNODULEとして管理されている分に関してはリークは発生していない．