小学校入学記念写真は三本桜の下で撮影する

偶数を含めたすべての整数にコラッツ木上のユニークなアドレスを与えるユニバーサルアドレスコードという着想はコラッツ問題の最終解決に資すると考えられたので,すべてのリソースをここに集中させるという選択を行い,それ以外の部分はいわばノイズとして廃棄するという大胆な改造を行ったが,一般コラッツ木,仮想コラッツ木(長子木),完全コラッツ木という3種のコラッツ木にはそれぞれの存在意義があり,いずれも欠くことはできないという考え方に戻ってきた.この3種のコラッツ木をコラッツ三本桜と呼んでおこう.

複数のモードが入り組んでいるロジックからバグを完全に取り除くのはかなり難しいので,思い切って余分なコードを完全にソースコードから削除してしまっているので,もう一度一から作り直すことになる.それをやる以外ないのだが,その作業に入る前にゼルコバの木で頻繁に現れる不具合をできれば一掃しておきたい.あまり深入りするともどり道が見えなくなってしまうので,できるところまでということで始めよう.

画面設定で人名枠幅などを調整しても画面に反映されないという不具合がある.この不良は使い勝手をかなり損なっているので,修正しておきたい.とりあえず,垂直方向に関しては水平連結線を引く領域をゼロにすることで対応した.コラッツ木上の結婚はすべて単身婚なので,この図面の描画では結婚線は不要としても問題は生じない.水平方向で人名枠幅の変更が画面に反映されない理由を調べてみよう.いや,まだ垂直方向でエラーが出ている.今日の修正で入ったもののようだ.もう一度バックアップまで戻ってみよう.⇒しばらくはこんな↓感じで,水平連結線のレーンを持たない簡略な図面のみを扱うことにする.


image


いや,確かに垂直方向の動作もうまく行っていない.人名枠高を変えると上下でダブリが生じる.ただし,これは再計算されていないか,ないし再描画されていないためで,ファイルを読み直すと位置は調整される.しかし,wholeH % GHのエラーは止まっていない.⇒UpdateDiagramがまったく実行されていない.⇒ようやく片付いた.人名枠などの描画パラメータの変更では,計算コストの掛かる系統並び替えではなく,UpdateDiagramで座標の再計算を実施しているが,この関数がまったく呼び出されていなかった.以前はちゃんと動作していたはずなので,いつからこんなことになったのか?どこにも痕跡が残っていないので,あっさり削除してしまったように思われる.

人名枠横幅の設定はとりあえず問題なく動作するようになったが,何点か描画上の不良が出ている.①垂直な親子連結線が水平な兄弟連結線から突き出ている,②人名枠の頭の垂線が消えている.この状況は上の図面でも見ることができる.⇒結婚マークを表示するをオフにすると,突き出ていた垂線は消える.オンに戻しても再現しなくなる.結婚点と関連する描画であることは間違いなさそうだ.結婚点というのは通常は兄弟連結線よりは上にあるものなのだが…

どうも少し複雑な動作になっているようだ.結婚点を表示するか否かで反応しているのではなく,単に再描画が掛かるか否かというだけのように見える.世代枠高が50増加している.⇒MaxPairListが5→0に変化している.⇒DrawFooterLineは配偶者がいない場合は描画する必要がない.兄弟連結線までの垂線は別途引かれている.

兄弟連結線から人名枠上辺までの垂線はDrawHeaderLineで描画する.DrawNameBoxではオブジェクトのsegmentを見ている.現行ではオブジェクトのsegmentは常時クリアされているため,判定に使えない.⇒とりあえず,一律描画するように仮修正した.

山の八合目からの眺望:8進数で眺めると

だいぶわかってきた.ほとんど山の八合目辺りまでは登り詰めたのではないかと思う.あともう少しで頂上を踏むことができる.そのときの眺望を君は想像できるだろうか?ここまで来られたのはほとんど奇跡と言ってよい.というのは,ここまで来るまでの道筋は自力で開いたものというより,すべて「偶然」による展開であるからだ.ノード番号を16進表記するというアイディアはわたしが考え抜いた末に見出した方法ではない.モヒティのようにバイナリ操作に主要な興味があれば,その方向に進んだ可能性は十分あるが,わたしは早い時期にこのような方向を放棄している.それではなぜ「16進表記」のようなことを思いついたかというと,まさに「必要に迫られて」そうしたというに過ぎない.必要に迫られたというのは,ゼルコバの木のキャパシティ的な限界による.

ゼルコバの木は基本的に32ビットOS上のシステムなので,最大整数はInt32の範囲に限定される.カードを一意に識別するための「参照番号」には便宜的にそのノードのノード番号を流用しているが,ノード番号が巨大化してくると当然その範囲に収まらなくなるため,なんらかのハッシュ関数を使って番号を32ビットの範囲に収めなくてはならなくなった.もっとも簡単なハッシュ関数は対象となる数をNとしてN’=N mod Max とする方法だ.今の場合は,32ビット以内に収めればよいので,下位31ビットまで切り詰めればよい.

ところが,予想に反してこの簡便なハッシュ関数によって異常なほど多数のハッシュ衝突が発生することがわかったというのがその端緒である.ラマヌジャンは「わたしは女神が教えてくれた答えを声にしているだけだ」と言っているが,わたしの感覚もそれに近い.そのような「偶然」の度重なる助けがなければ,ここまで来ることはなかったと思う.

この問題の理想的な解決があるとすれば,与えられたノード番号のバイナリ表現を分節して,

ノード番号=親ノードのバイナリ表現
          +ノード固有の枝番を示すバイナリ表現

とすることだろう.これができれば,この等式を再帰的に適用することによって一意のアドレスコードを取得し,そのノードのアドレスコードつまりコラッツ木上の位置を完全に特定することができるようになる.現時点では,

ノード番号=長子ノードのバイナリ表現
          +ノード固有の枝番を示すバイナリ表現

として定式化することはできるようになったが,まだこれでは木構造を構成することはできない.「長子ノードのバイナリ表現」を「親ノードのバイナリ表現」に変換する操作を定式化する必要がある.問題は,「長子ノードのバイナリ表現」の方が「親ノードのバイナリ表現」より長い場合があるという点だ.これから見ても,

親ノードのバイナリ表現=長子ノードのバイナリ表現+X

のようなものにならないことは明らかだ.長子ノード番号Sを親ノード番号Pに変換する関数Fは以下の式で与えられる.

2^c*P=3S+1

このとき,cの値は1, 2, 4のいずれかであることはわかっているので,

P=F(S)=(3S+1)/2   c=1の場合:S=…011, …111の場合
    =(3S+1)/4   c=2の場合:S=…001の場合
    =(3S+1)/16  S=5=101の場合

のように記述することができる.非長子ノードMはすべてM=…b101のように表記される.ただしbは空ではないとする.LSB=0の場合は偶数なので除外できるから,上記で場合を尽くしていることは明らかだ.任意のノードNが与えられたときの親ノードPは簡単な計算で得ることができる.ノード番号を3進数として表記してみよう.Nを3進数として表記した場合の最大のメリットはそのノードが3倍数であることが末尾1桁を見るだけでわかるという点にあるが,もう一つ,3S+1という計算をシフトとインクリメントだけで構成できるという点がある.しかし,バイナリとターナリの混合計算というのはできないので,3進数に変換しても大したメリットは得られないような気がする.

もちろん,これらの相互変換を高速実行できるようなコンピュータが存在すれば,また別だ.かつてソ連には3進コンピュータというのがあったという…ノード番号を3進数表記したら,また別の見え方になるだろうか?やってみるだけの価値があるだろうか?実装はそれほど難しくはないと思われるが,3進数表記するとテキストが長くなり過ぎて巨大数を表示するのにはかなり無理があるような気がする…ハッシュ衝突の発生は枝数を少なくとも6くらいにしないと見えてこない.枝数6というと相当巨大な数字を扱わなくてはならなくなる…確かに末尾1桁を見ただけで3倍数であるか否かを判別できるというだけでも興味は湧いてくるが…

むしろ,8進数で見た方がおもしろいのではないだろうか?8進数で見ると,少なくとも長子→親ノード変換のパラメータが末尾1桁で決定できることになる.確かにこれは言えるかもしれない.8進数で表示すると使われるアルファベットは0~7でうち偶数を除くと,1, 3, 5, 7の4種だけだ.上の変換関数でc=1の場合というのは,末尾3と7に該当し,末尾1ならc=2ということになる.末尾が5というのが(きっかり5の場合を除き)非長子ノードであり,明快に分類できる.3S+1という計算を実施することによってDNA配列は完全に暗号化されてしまうから,それを復号化するためにはFの逆演算をやるしかない…しかし,S ⇔ 3S+1は完全に1対1対応しているので,計算自体には何の支障もない.C++にはstd::octというクラスがあるので,試してみることにしよう.

かなりいい感じだ!目で見て(計算しなくとも)長子ノードと非長子ノードが区別できるというのはうれしい.

image

長子ノードになるのは末尾が1, 3, 7の場合だが,これらのノードには特に規則性のようなものは看取できない.3倍数(ピンク)の分布も兄弟枠内で3つ置きという以外の規則性を見出すことはできなかった.3N+1を計算すれば,cがいくつになるのかはそのノードの末尾桁だけで決まるので,長子ノードから親ノードを即決で求めることができるようになった.すでに長子木というオプションは廃止してしまったが,これを見ればなにかわかることがあるかもしれない.ともかく,3本の木をもう一度復活させることにしよう.⇒その前に少しZTのバグを取っておこう.

▲人名枠幅を変えても画面に反映されない.

▲再描画ボタンを押して,GetPageCountで(treeview()->validcard && !NearZero(wholeH % GH))というエラーが発生する.wholeHは1210,GHは292で商は4,余り42だ.この誤差がどこで発生したのかが問題だ.wholeH には以下のような値が入っている.wholeH = treeview()->relative().Height() + treeview()->bottomcut bottomcutには10という値が入っている.


コラッツ木のノード番号を16進表示してわかったこと

コラッツ木をゼルコバの木にインポート→描画がかなり容易にできるようになってきた.コラッツ木のダンプ出力は巨大数の羅列であり,これを眺め回してもほとんど何もつかめないが,系図木として画面上に表示できると,かなりのことがわかってくる.特に,ノード番号を16進表示してやると,これまで見えていなかったことが鮮明に見えてくる.かなり重要なポイントなので多少回り道にはなるが,追求してみたい.

一つ断定的に言えることとして,「非長子ノードの最右桁はつねに5ないしDである」という点がある.逆に言えば「もし,16進表示のノード番号の最右桁が5でもDでもないとすれば,そのノードは長子ノードである」と言える.もう少し端的に表現すれば,「2進表示の最右2ビットが11ならば長子ノード,01ならば非長子ノードである」と判定できる.

長子ノードNの2進表示をb…bとするとき,左隣の兄弟ノードはb…b01,その左はb…b0101のようになるから,長子ノードNの兄弟ノードは,b…b{01}*のように表現することができる.従って,長子ノードNの親ノードのビット列はb…bとはほとんど類似性を持たないが,すべての兄弟に共通するビット列として,これを親ノードPから引き継いだDNAのようなものとみなしてもよい.つまり,すべての奇数ノードはこのDNA配列によって特徴付けられると言ってよいだろう.

DNAというより,Y染色体と呼んだ方が当たっているかもしれない.この意味で奇数ノードは水平方向にはハプログループをなしているとも言えるが,垂直方向ではある意味で「暗号化」されてしまうため,追跡は困難であるように見える.奇数ノードのY染色体はビット列の上位部分に現れるが,観察した限りでは下位ビットでも似たようなコードが高い頻度で出現することが確認されている.この理由について知りたい.

3倍数ノードがコラッツ木上でどのように分布しているか?という点にも興味がある.少なくとも兄弟枠内では3倍数は3つ置きに出現することが確認されているが,兄弟枠外ないし,血統木全体を見たときにどうなっているかを知りたい.これがわかるとノードの値を計算するのもかなり容易なものになる可能性がある.少なくとも3倍数の検出には役立つかもしれない…長子ノードとその次のノードをチェックすれば3倍数がどの位置に出現するかは確定できるので,実際には,3倍数の検出と言ってもそれほどのコストが掛かっている訳ではないが…

▲一覧画面上で行クリックすると画面全体が更新・描画される.

▲CollatzTree 1-6-4 511.zelを少し操作したあと,クローズしようとしてフェーズ遷移エラーが起きた.

上位ビットの共通部分とは,Y染色体のDNAであると言えるとして,下位ビットの共通部分というのがどういう性質のものか?少し調べてみよう.511点のコラッツ木で16進4桁以上の下位共通部を持つノードを拾い出してみよう.以下では16進数を右から左に表記している.つまり,最下位ビットが最上位に表示されるような形式だ.たとえば,3A2B1CならC1B2A3と表示される.

  1. 1748 x2
  2. 1790 x2
  3. 17C5 x5,17C52 x4
  4. 17CB4  x3
  5. 17CE5  x3,17CE52 x2
  6. 1B79    x2
  7. 1F21    x2
  8. 36F2    x2
  9. 3E21    x3
  10. 3E52    x3
  11. 3E80    x2
  12. 3E8DB x3
  13. 5170    x2
  14. 5174    x4,57148 x2
  15. 51790  x2
  16. 51C5    x5,51C52 x4
  17. 517CB  x4,517CB4 x3
  18. 517CE5 x3,517CE52 x2
  19. 51B7    x3,51B79 x2
  20. 51F2    x4,51F21 x2
  21. 5324 x2
  22. 536F2  x3
  23. 53E0 x2
  24. 53E2 x5,53E21 x3
  25. 53E5 x4,53E52 x3
  26. 53E8 x7,53E80 x2,53E8DB x3
  27. 5511 x2
  28. 5514 x2
  29. 5517 x26,55170 x2,55174 x4,551748 x2,55179 x4,551790 x2,5517C x13,5517C5 x5,5517C52 x4,5517CB x4,5517CB4 x3,5517CE5 x3,5517CE52 x2
  30. 551B7 x3,551B79 x2
  31. 551F2 x4,551F21 x2
  32. 5532 x4,55324 x2
  33. 5536F2 x3
  34. 5538 x2
  35. 553E x21,553E0 x2,553E2 x5,553E21 x3,553E52 x3,553E8 x7,553E80 x2,553E8DB x3,553E8DB4 x2
  36. 5548 x2
  37. 5550 x2
  38. 5554 x4,55548 x2
  39. 555C x34,555C1 x20,555C11 x3,555C14 x2,555C17 x6,555C179 x4,555C1790 x2,555C1B7 x3,555C1B79 x2,555C1F2 x3,555C1F21 x2,555C5 x5,555C52 x4,555C524 x2,555C9 x2,555CB x4,555CB4 x3,555CE5 x3,555CE52 x2
  40. 5579 x3
  41. 55B4 x4,55B48 x2
  42. 55C1 x20,55C11 x3,55C14 x2,55C17 x6,55C179 x4,55C1790 x2,55C1B7 x3,55C1B79 x2,55C1F2 x4,55C1F21 x2
  43. 55C5 x5,55C52 x4,55C524 x2
  44. 55C9 x2
  45. 55CB x4,55CB4 x3
  46. 55CE5 x3,55CE52 x2
  47. 55D0 x2
  48. 55D2 x5,55D21 x3
  49. 55D5 x4,55D52 x3
  50. 55D8 x28,55D80 x2,55D83 x12,55D832 x4,55D836 x3,55D838 x2,55D879 x3,55D8B x5,55D8B4 x4,55D8B48 x2,55D8DB x3,55D8DB4 x2
  51. 5B48 x2
  52. 5C11 x3
  53. 5C14 x2
  54. 5C17 x6,5C179 x4,5C1790 x2
  55. 5C1B7 x3,5C1B79 x2
  56. 5C1F2 x4,5C1F21 x2
  57. 5C52 x4,5C524 x2
  58. 5CB4 x3
  59. 5CE5 x3,5CE52 x2
  60. 5D21 x3
  61. 5D52 x3
  62. 5D80 x2
  63. 5D83 x12,5D832 x4,5D8324 x2,5D836F2 x3,5D838 x2
  64. 5D87 x4,5D879 x3
  65. 5D8B x5,5D8B4 x4,5D8B48 x2
  66. 5D8DB x3,5D8DB4 x2
  67. D832 x3,D8324 x2
  68. D836F2 x3
  69. D838 x2
  70. D879 x2
  71. D8B4 x4,D8B48 x2
  72. D8DB x3,D8DB4 x2

こんなにあった!16進4桁ということは,2進で16ビットだから,同一ビット列となる確率は1/2^15としても1/32768=0.00003しかない.このような共通ビット列はなんらかのファミリーのようなものの標識であると見てよいのではないだろうか?よく見ると,このような標識の末尾(上記リストでは先頭)は圧倒的に5ないしDが多い.これは上記したように非長子ノードであるということを意味するので,頻繁に現れるのはそれほど奇異なことではない.しかし,同じ標識を持つ2つのノードが兄弟である可能性はほとんどないのではないか?試みに,最大ファミリーである「55D8」グループをグラフでカラー表示してみよう.

直接親子関係にあるノードが2組ある.9932117→6780325205と79531349→54293400917だ.16進で表記すると,978D55→194238D55,4BD8D55→CA4238D55のようになる.図面で見るとこれらのノード(赤で着色)はすべて例外なく6-正則木の6番目の枝にあるノードだ.

image

これから類推されることは,16進ないし,2進数表示された数値の下位ビット列はそのノードの枝番と強い関連性を持っていると言えるのではないだろうか?いや,これはそれほど驚くには当たらない.つまり,上記したようにすべての奇数ノードMのノード番号はビット列で表せば,b…b{01}*のように表記されるのだから,

M={長子ノードのビット列}+{枝番号を示すビット列}

という構成になる.8D55=100011-0101010101で確かに6番目の枝に位置することは明らかだ.{枝番号を示すビット列}の直上の2ビットが11でなくてはならないことも明らかだ.もしこれが,00ないし10なら長子ノードが偶数になってしまうし,もし,01なら6番目のノードではなく,7番目のノードということになる.

ノードの直上の親ノードを求めるにはどうすればよいか?任意のノードの長兄ノードを求めるのは簡単だ.右から2ビットづつ削除を11というビット列が現れるまで繰り返せばよい.今の場合は,100011B=23H=35に到達する.親ノードは35×3+1=106→53=35H=110101Bだ.バイナリで計算すれば,100011を左シフトして1000110+100011=1101001,これに1を加えて,1101010.末尾の0をすべて除去して,110101を得る.

親ノードNから長子ノードSを得る方法はあるだろうか?今の場合で言えば,110101から100011を得る方法だ.N*2^c=3S+1となるようなcを決定できればよいのだが,3で割り切れるかどうかを判定する効率的な方法がないので,このステップをバイナリ化するのは難しそうだ.c>0であり,おそらくc≦2であるような気がするのだが,違うだろうか?それよりも大きなcは見た記憶がない.いずれにしても,cは高々1ないし2と推定されるので,試行コストはそれほど高くつくものではない.

上記の説明には誤りがある.長子ノードを求めるのに,「右から2ビットづつ削除を11というビット列が現れるまで繰り返せばよい」としているが,これは長子ノードの定義に反している.というか,定義を満たしていない.長子ノードとは,これまでコラッツ数と呼んできたものであり,「奇数Nから1を減じて4で割った値が奇数とならないもの」と定義される.従って,コラッツ数とは「奇数Nから1を減じて4で割り切れないか,ないし商が偶数となるもの」である.

これをバイナリ計算として表現すれば,「末尾が101なら右に2ビットシフトする」となる.従って,コラッツ数の末尾はつねに11であるとは限らない.001という場合があり得る.100000010101という数を考えてみよう.右端の01をすべて取り除くと偶数になってしまうから,このノードは10000001=129という数を長兄として持つことになる.

しかし,いずれの場合でも長子ノードの親を求める計算では,3N+1を2回以上割ることはないということを示すことができる.まず,末尾が11である場合を考えよう.この数Nのビット列を…b11とすると,3N+1=…b110+…b11+1=…x10となり,2で1度割り込むだけで奇数になってしまう.Nが…b001と表示される場合には,3N+1=…b0010+…b001+1=…x100となって,やはり2度続けて2で割ることで奇数になる.従って,任意の奇数の長子ノードを求め,さらにその親ノードを求める計算は十分短い時間で完了すると言える.この逆演算ももちろん有限のきわめて短い時間で実行可能であると言えるから,コラッツ木の垂直関係はこれによってほぼ確立できたと言って間違いないだろう.

モヒティが盛んに主張していた,「binary formula」というのは確かにこのことであったに違いない.彼は結局自力ではそれを突き止めることはできなかったのだが…確かに,この洞察を得ることでようやく証明に至る道が見えてきたと言えるだろう.このように見てくると我々の方法の中でもっとも重要なポイントはやはり「長子ノードの発見」ということにあるのではないだろうか?

我々の提案の中には,①一般コラッツ木,②コラッツ長子木,③コラッツ完全木という三種の木構造が含まれているが,これらのうちのどの一つも説明/証明に欠かすことはできないように思われる.この意味では,今回の修正でB面から一般コラッツ木を排除してコラッツ完全木に一本化してしまったというのは早まった措置と言わざるを得ない.もう一度これらを一から整備し直すというのもかなり難儀ではあるが,やるしかないような気がする.

上の説明でまだ一つだけ欠けている点がある.長子ノードのビット列末尾は11ないし001のいずれかとしているが,もう一つの場合がある.101B=5という場合だ.この値の場合,01を除けば1という奇数になるのだから,コラッツ数の条件を満たしているが,この場合に限っては3N+1を2で割る回数は4回になる.このノード5という数の特殊性に関してはやはり,長子木を示して説明する必要があるように思われる.(上記の手順では5を例外としないと長子ノード5をスルーしてしまう…)

1-6-4 正則コラッツ一般木でかなり奇妙なことが起きているのを発見

今日もかなり冷え込みがきびしい.今年初めて室内で手袋を着用した.

IMG_20220225_224236

1-6-4 正則コラッツ一般木でかなり奇妙なことが起きているのを発見した.このグラフは511点という比較的小さな木だが,そのうちの22点で下位31ビットが同じという「ハッシュ衝突」が起きている.ハッシュ衝突は2つのカードで起きているが,中には3つのカードで衝突ということも起きている.これをチェックするのに部分図機能を使っているが,動作が思わしくない.

一覧画面でシフトキーを押しながらクリックする「拡張選択」ができない場合がある.できる場合もある…コントロールキーを使った拡張選択もできない.⇒ドラッグすると拡張選択になる.⇒選択規則を誤解している.一覧表左端のカード番号をクリックしたときは,選択領域を変化させないという仕様になっている.選択状態を変えるためには性別より右の欄をクリックしなくてはならない.⇒現状はこの仕様に沿った動作になっている.最左列をクリックするとカード画面上のカードが切り替わる.この仕様は悪くないと思う.選択状態を保持したまま,任意のカードの情報を確認できるというのは利便性の高い機能だ.確かに,この点を知らないとかなり戸惑う可能性はあるかもしれないが…

上記22点を選択して部分図に追加しようとしてエラーが発生する.また,部分図に切り替えても全体図が表示されたままになっている.⇒下記の通り,「MAXIMALGRAPHを縮小する」に対応・修正して解決.

一覧画面で表示範囲を部分図に含まれるカードに設定すると,エラーが発生し,一覧表が空になる.⇒問題なく動作するようになった.

まず,これらの不具合を片付けないと問題の解析に入れない.ちょっと手間が掛かりそうだが,こちらを先行させることにしよう.部分図の動作不具合と,選択操作の不良の2件を片付ける必要がある.

HashCollision 511.zelを開いて,異世代多重反復カウントオーバーが起きている.⇒多重カウントが変化していない場合にはSTOPCARDSHIFTでブレークするというフローになっているが,そもそも多重になっていないので,エラーとする必要はない.

同上サンプルで任意の数点を選択し,部分図に追加してエラーになる.ただし,部分図に切り替えない場合はエラーは発生しない.1点だけなら部分図に切り替え可能.⇒対処した.

1点だけの部分図からこのノードを削除して描画でエラーになる.⇒カードゼロの状態で有効な結婚枠が残っている.セグメントリストが空になっていない.⇒対処した.

前回,MAXIMALGRAPHを縮小する@20220221の修正がまだ収束していない.segmentsとlooseboxをメモリ使用量削減のために,MAXIMALGRAPHの静的変数に変更しているので,一つの系列の処理が完了した場合にはその領域を次の系列のために解放しなくてはならないが,それをやっていない.CheckMaximalSegmentは毎回セグメントの初期化を実施しているが,問題はこの関数がHorizontalSegmentの下位関数としてだけではなく,独立の関数としても実行される場合があるという点だ.CheckMaximalSegmentの実行後にセグメントを解放してしまうと,HorizontalSegmentの処理が続かない.

OnHorizontalSegmentを見ればどちらのモードで動作しているかは判別できる.OnHorizontalSegmentがオフのときはセグメントを解放するようにすればよい.ただし,このとき,segmetcntなどをクリアしないようにしなくてはならない.

動作するようになった.ReleaseSegmentという関数を新設して,HorizontalSegmentとCheckMaximalSegmentの出口で呼び出すようにした.これで問題は基本的に解決しているが,副作用としてオブジェクトのセグメント番号が失われてしまうという欠陥がある.これがないとSUWのときにセグメントを色別表示するなどのことができなくなってしまうが,已むを得ない.どうしても必要な場合はなにか対策を講じるしかないが,今のところはこれで十分だ.

部分図に含まれる要素をすべて除去して,描画時にエラーが発生する.DrawTreeLine→ getSpecialSpouseでオーナー不在という状況が起きている.部分図では完全に空という状況が起こり得るが,有効な結婚枠が残っているということ自体がおかしい.部分図を描画したときの結婚枠とは別物なので,どこかで新たに生成されている模様だ.

TopologicalSort→ClearTableでは結婚枠を持たない結婚リンクには一律結婚枠を生成して渡している.部分図の抽出はそのあとで実行されているため,すべての結婚リンクが再生成されていると考えられる.しかし,そのあとでExtractPartialCardが実行されるので,不要な結婚枠は非アクティブになっているはずなのだが…

ExtractPartialCardではカードリンクの有効・無効は決定しているが,結婚リンクのチェックは抜けているようだ.FilteringKinshipでカードと結婚の有効/無効を決定しているが,カード無しの場合は無動作で抜けている.⇒HideNameboxを実行してから抜けるようにした.

部分図を登録・保存したあと,ファイルを開き直して,InitFileで「算術演算の結果オーバーフローが発生しました」のエラーになった.

image

OpenFileProcの戻り値の317834583をShortのInitFileに格納できないという意味だろう.lretはIntegerなのでIntegerにしてやれば間に合うだろう.⇒オープンできた.

ハッシュ衝突が起きているノードは以下のような状況になっている.

image

興味深いのは半数近くが親子関係になっているという点だ.おそらく,親子関係を持たないノードもコラッツ木の規模をもう少し大きくすればおそらく,その下に接続するノードが出てくるはずだ.隣の兄弟との関係は4N+1だから,左に2回シフトして+1という操作になる.つまり,末尾が01というパターンの繰り返しになっているはずだ.ノード番号を10進ではなく16進で表示してみればわかるのではないだろうか?やってみよう.やるとしたら,インポートするところでやる以外ないだろう.

カード上で性別を変更・登録して一覧画面の性別が変化しない.一覧画面で性別をダブルクリックすると変化するが,系列画面上のカラーは変化しない.⇒一般に一覧画面上でのデータ更新は,リターンキーによって受け付けられる.一覧画面のダブルクリックだけでは登録にならない.「カード上で性別を変更・登録して一覧画面の性別が変化しない」というのは事実誤認ではないか?登録ボタンを押すと一覧画面も更新されている.リターンキーを押すと,選択行が一つ前に進んでしまうことが動作を不明瞭なものにしている…


コラッツ木上の任意の整数ノードに一意のアドレスを与えるユニバーサルコードシステム

コラッツ木上の偶数を含む任意の整数ノードに一意のアドレスを与えるユニバーサルアドレスコードシステムを確立した.これは,コラッツ予想問題が実質的に完全に解かれたことを意味する.実装はほぼ完了して,コラッツ数列取得・枝番→番号変換,幹線木図ではすでに動作しているが,検証テストではまだ不具合が発生している.どこかに未整備のところが残っている模様だが,シューティングは難しくないはずだ.不一致が発生しているのはN=3のケースだ.

検証テストではテストのたびにStart numberを更新し,その値から検査を実施しているが,このテキストボックスの内容が更新されていない.これを行うのは枝番→番号変換だが…コラッツ数列取得では3のアドレスを(1.1)と出力している.これは正しい.また,枝番→番号変換ではこのアドレスから3を計算している.⇒いや,手抜かりがあるのは枝番→番号変換ではなく,コラッツ数列取得の方だ.枝番号リストが空になっている.⇒検証テスト中,枝番号列が更新されていない.⇒対処した.

動作するようになったが,いきなり遅い.なぜだろう?実行速度にここまで影響するような処理は追加していないつもりだが…コンソールにダンプを出していた.⇒2^5は一瞬で完了するようになった.2^13では14秒掛かっている.以前は10秒内外で完了していたような気がするのだが…リリース版に切り替えても速くならない…検証テスト中不要な処理を止めてもさして効果は出ない.完全木では15秒掛かっている.まぁ,こんなものと思うしかないだろう…

検定を偶数を含めた整数全体に拡張してみよう.これは結構興味深いテストだ.一般木で17秒掛かった.完全木で19秒だ.検証テストの出力では一般木と完全木のトポロジーは完全に一致する.実際,一般木と完全木では同一のアドレスコードを適用しているのだから,同じにならなければおかしい.逆に言うと,少なくともB面では一般木と完全木を区別する必要がなくなったと考えられる.完全木には2倍数と3倍数は含まれないので,A面では一般木と完全木は完全に区別される.

ここまでやった以上,A面出力に全体木というオプションを追加することが考えられる.全体木とは偶数を含むすべての整数をノードとするコラッツ木だ.一つの奇数ノードの下に無数の偶数ノードがぶら下がることになるので,図面的にはやや冗長なものになる可能性はあるが,出力する意味はあるのではないだろうか?試してみる価値はあるような気がする.仕様の拡張になるが,B面の検証テストには奇数のみ/すべての整数というオプションがあってもよいと思う.

1-6-4 460点の一般正則木を生成して,最大数の6949574919509が孤立点になった.このノードのアドレスは 4. 4. 4. 4 でコラッツ数列は

6949574919509→5090020693→7456085→5461→1

5090020693というノードがグラフから落ちている.CSVファイルには入っている.この図面は6-正則木なのですべてのノードが枝を6本持たなくてはならないところだが,一部のノードは数が少なくなっている.カード数は460で上限にはほど遠いが,カード番号はInt32の範囲に入らなくてはならないため,どこかでカットされているのではないだろうか?しかし,最大数が6949574919509でそれ以上の数がないとしたら,おかしい.6949574919509は画面に表示されているのだから…⇒ゼルコバの木の一覧表フォーマットファイルには入っている.このファイルには511点のカードが登録されている.一覧表のインポートで失敗しているのだろうか?

インポートファイルはShift-JISとして処理されている.また,デリミタはカンマになっている.SJISに変換したものを読み直してみたが同じだ.ファイルは読み込まれ,レコードはDLLに送られているが,DLLで失敗しているのだろう.そこまでは情報はすべてテキストで受け渡ししているため,損なわれていないが,データベース登録のところで整数化する時点で落ちているのだろう.巨大数を読み込んで整数範囲に収まるように圧縮するようなうまい方法はあるだろうか?番号の重複を無視すればそのような方法は複数考えられるが…これは結局ハッシュということと意味的には同じと考えられる…もし,ゼルコバの木コラッツ特注版を本気でリリースするというのであれば,この対策は必須ではないか?

レコードを送っているのは,Z.mSendRecordDataという関数だ.mSendRecordDataでは受信テキストを最長256文字の語句に分割して送り出している.受けているのはSendUpdateDataという関数だ.参照番号への変換は, long long(atoi(item[_REFNUM]))で実行される.atoiには類似関数として,atol, atollがある.まず,これらを試してみよう. “3379676501”という値が,-915290795に変換された.この値は16進でC971C555となるので最上位ビットが1になり,負値とみなされる.最大数の6949574919509はこれよりもっと大きいので到底longには入らない.さて,どうしたらよいか?longをulongに変えても1ビットしか増えないので焼け石に水だ.Int64というのはC++ではlong longに該当する.ゼルコバの木を64ビット対応に再編成できれば,それも不可能ではないが,いま即応するというのは無理だ.やはり,ハッシュで切り抜けるしかないのではないだろうか?方法を考えてみよう.

  1. 参照番号がlongの範囲内である場合は,現行通りとする.
  2. 参照番号がlongより大きい場合には,ハッシュ関数を呼び出して新参照番号の割当を受ける
  3. ハッシュ関数には,参照番号の計算値Nと氏名文字列Tを渡す
  4. Tという名前を持つカードがすでに存在する場合には,その番号を返す
  5. 無登録の場合には,Nを縮小してlongの範囲内の数値N’を得る
  6. N’という参照番号が登録されている場合には,N’+1を次候補とする
  7. これを未登録番号N*を見つけるまで繰り返す

通常のハッシュとはやや異なる手続きになっているが,まぁ動作するのではないか?この参照番号をあとから参照する場合にも,まったく同じ手続きが必要になる.通常,このような場合にはすでに既存カードとして登録してあるはずだから,上記のステップ4で応答することになる.この手続きでは氏名はかならずユニークで重複がないことを仮定している.コラッツ木の場合にはすべてのノードにはユニークな番号が名前として割り付けられているので問題ないが,一般の場合については,別途考えることにする.というか,一般の場合は参照番号を「与えられる」という手順になっているので,いまのところ考えなくてもよいと思う.

一つ問題がある.未登録のカードを登録する場合はこれでよいが,登録済みの場合,レコード情報には,父番号・母番号・配偶者番号は含まれるが,その氏名情報は含まれていない.つまり,これはハッシュしてダブったらアウトということになってしまう.⇒大きい数を下からカットすれば重複する可能性はほとんどないと見てよいのではないか?よほどの偶然がない限り滅多にそのようなことは起こらないような気がする.もし,この理屈が通るのなら,値を検索しないで最初から確定することができる.単純に上位ビットをカットするだけで望みの値を得ることができるだろう.とりあえず,これでやってみよう.

きれいに片付いたような気もするが,ちょっとおかしいところもある.登録カード数は498点だ.有効ノード数は511点だから,13点少なくなっている.どこへ行ってしまったのだろう?6949574919509というカードは登録されて親の5090020693も存在する.参照番号は5090020693だ.下位桁はそのまま残るのかと思ったが,まったく異なる数字列になっている.まぁ,これは仕方ないだろう.十進の数字を残すには10で割るなどの操作が必要になり,計算量が増えてしまう.

このサンプルは6-正則木として生成されているが,子ノードが1つ少ないノードがいくつかある.291157,1164629,4951381,39612757は2つ少ない.3段目で1少ないノードもある.116053だ.この段で1個消えると7個分が消滅する.3段目で2個少ないノードもある.232789だ.これで一挙に14個が消えることになる.この逆に高さ4という設定なのに6段目に子どもを持つノードが2つある.3474786993493と6949574919509だ.前者が子ども3人,後者が4人持っている.

多分これで収支はあっているのではないかと思われる.これらはすべて下位31ビットが同じカードが複数存在したために発生したものと推定されるが,対策はあるだろうか?⇒ある.上記では氏名は不明としているが,少なくともコラッツ木では「氏名」=参照番号となっているから,突き合わせは不可能ではない.しかし,これほど小さい範囲でこれだけの重複が発生するというのはかなり驚異だ.モヒティは「バイナリ操作の方法には望みがある」のようなことを言っていたが,ここまで気付いていただろうか?ちょっと上の手順を書き直してみよう.

  1. 参照番号がlongの範囲内である場合は,現行通りとする.
  2. 参照番号がlongより大きい場合には,ハッシュ関数を呼び出して新参照番号の割当を受ける
  3. ハッシュ関数には,参照番号Nをlong long で渡す
  4. Nの上位ビットを切り捨てて31ビットの番号N’を生成する
  5. N’がすでに登録されている場合:名前とNが一致している場合はN’を返す
  6. N’の登録があり名前とNが一致しない場合,N’+1を新規参照番号とする
  7. これを未登録番号N*を見つけるまで繰り返す

これでよいのではないだろうか?このハッシュ関数Fにはlong long が参照番号として渡される.Fはカードテーブルにアクセスできる必要があり,戻り値としてlongの参照番号を返すものとする.コストは結構掛かりそうだが已むを得ないだろう.

▲選択領域の部分図への追加がうまく動作しない.エラーが発生してSUWになってしまう.

▲一覧画面で行をクリックして,系図画面で移動が発生しない(場合がある).動く場合もある.

非常に奇妙なファクトを発見した.3倍数を含む一般コラッツ木で1-6-4という正則木を生成し,ゼルコバの木にインポートするとき,ノード番号が長整数の範囲を超えているため32ビット以上のビットをカットする「ハッシュ」を実行しているが,わずか511点というグラフの中でハッシュ値の衝突が13件も発生している.つまり,下位31ビットが完全に一致するノードの組が複数存在している.

一見したところ,このような一致がこれほど高い頻度で発生するなどということはあり得ないように思われるのだが…このような一致は枝番の大きいところで起きる傾向があり,ほとんどは枝番6のところで発生している.このようなノードには3倍数も含まれている.このようなことが起きる理由ないしメカニズムはいまのところまったく分からない.条件を緩和して下位15ビットが一致する場合としても,発生件数には変化はない.少なくとも言えることは,コラッツ木上の数の配置はランダムにはほど遠いものがあるということではないだろうか?

コラッツ完全木ノードアドレスコードの拡張

完全木を使いながら,すべての奇数ノードに一意のアドレスを割り当てる方式を編み出した.これは最強の解決策と言えると思う.この方式では非3倍数と3倍数を完全に分離し,非3倍数のみからなる完全木上のノードには親ノードの子ノードのうち非3倍数のみを数えた順序数を与え,3倍数では3倍数のみを数えたときの順序数を与える.これにより,すべての奇数ノードはユニークなアドレスコードによって一意に特定することができるようになる.非3倍数に与えられる枝番号は正値とし,3倍数の枝番号は負値で表記する.ただし,この負値の枝番号はつねにアドレスコードの終端にしか現れない.

このアドレス方式のメリットはアドレス→番号変換で,任意の枝番号列を指定することができるというところにある.一般木のアドレス方式ではランダムなアドレスコードを与えると大概の場合は,コード上のどこかにほぼ確実に3倍数が現れるため,「無効なアドレス」として短縮されてしまう.逆に言えば,完全木アドレス方式では無効なアドレスというのが原理的に発生しない.これにより,完全正則木の最大枝数をD,木の高さをHとするとき,D^Hの完全に均一なアドレス空間を確保することができる.完全木アドレスを拡張して3倍数ノードに負の枝番号を付与する方式(負値枝番号はアドレスコードの終端のみ)ではあらゆる長さの任意のアドレスコードが有効なアドレスとして認識される.

すでに実装して検証テストも完全木モードで動作するようになっているが,まだ多少の問題が残っている.どうもどこかで3倍数の一部が落ちているようだ.まず,このシューティングから入ることにしよう.⇒明らかに現行の隣接リスト生成には手抜かりがある.5-3という関係が落ちている.アドレス→番号変換を単独で実施したときには正しく生成されているので,検証テストで処理が脱落しているのだろう.MakeAdjacencyListで失敗しているようだ.

いや,なにか勘違いしていたのだろうか?少なくとも2^5では3倍数を含む1~63までの奇数がすべて揃っている.2^6でもOKだ.多分テストの手順を誤っていたのだろう.おそらく,Odd numberが更新されているのを忘れて大きい数から検定を開始してその結果を見ていたのではないか?2^7でも確認した.OKのようだ.コラッツ完全木対応修正はほぼ,完全に完了したのではないかと思う.

あとは,マニュアルを書きながら動作確認するまでだ.今回のマニュアル更新では「アドレス」という用語を強調する必要がある.この意味ではアドレスコードの構文に1.2.3-4のような地番表記を導入するというのは意味があるのではないだろうか?内部的に-を.-に置き換えるというだけだから,処理的には難しくない.正負の地番が存在するというより,3倍数のアドレスは3番地の4のように分筆されるとした方がわかり易いような気がする.非3倍数ノードが独立した地番を持つ宅地であるとすれば,3倍数は親ノードの地所に付属する1区分という理解でよいだろう.

▲アドレスコード中ピリオドだけが連続していると黙って後ろをカットしてしまうが,メッセージを出した方がよい.

ここまで進むと,偶数を含むすべての整数にアドレスを与えることも不可能ではなくなる.偶数の場合には,たとえば,1.2.3+4のように表記すればよい.これを使えば完全にユニバーサルなアドレスコードを確立することができる.検証テストも奇数だけではなくすべての偶数を含む整数全体のテストを実施することができるだろう.かなり大掛かりな修正になってしまうが,やるだけの価値はあるのではないだろうか?

ただし,検証テストでこれをやると作図上の問題が発生するかもしれない.偶数はコラッツ木上では必ずしも終端ノードではないので,その従属関係まで表示しようとすれば,完全木の範囲を大幅に逸脱してしまうし,解析も相当困難なものになる.偶数ノードつまり,2倍数を3倍数に準ずるような終端ノードとして扱うことは不可能ではないが,見易い図式になるかどうかはかなり疑問だ.たとえば,6, 12, 24, 48, 96,…などのノードはすべて3の子ノードということになる.かなりごちゃごちゃした見辛いものになりそうだ.

コラッツ数列やアドレス番号変換などを拡張して偶数を扱えるようにするのは悪くないが,検証テストで偶数を扱うのは,特に隣接リストを出力してグラフを描画するというのはあまりよいアイディアではない.従って,検証テストの対象は現行通り,奇数に限定するというのでよいと思う.しかし,「ユニバーサルアドレスコード」という概念が理論的には成立することはどこかで示しておいた方がよい.

偶数を表記するのに地番+枝番の形式を適用するというのは悪いアイディアではないが,実装的にはやや難点がある.評価関数では+12を単に12として扱うことしかできないからだ.現行では枝番号を符号付き整数として扱っているが,たとえばそれをInt16の範囲に限定し,それより大きい数値は偶数の枝番として扱うなどの方策も考えられないではないが,結構面倒だ.最初に+で分割してその後ろの数値を取り出してしまうということは考えられなくもない.これは比較的安全に履行できそうな気もする.⇒ユニバーサルアドレスコードというアイディアはかなり魅力的なので,なんとか実現してみたい…

4010814653485のコラッツ数列を求めようとしてエラーが発生する.⇒Exit Functionが入っていなかったため,エラートラップに入ってしまった.⇒対処した.

また厄介な問題が出てきた.完全木モードでは2倍数と3倍数を処理対象範囲に含めようとしている.完全木的にはいずれも終端ノードとして扱われるが,場合によっては2倍数が3倍数に連結するということが起こり得る.たとえば,444は2倍数だが,上位ノードの111は3倍数だ.3倍数の上位ノードが2倍数になるということはあり得ないから,2倍数→3倍数というパターンだけ考えればよいはずだが,そのような準備は整っていない.現行ではどちらか片方だけが発生するという前提になっているが,まず,2倍数を処理して,次に3倍数を処理するという手順に変更しなくてはならない.コラッツ数列と枝番号変換の両側で対応する必要がある.444を完全木で展開すると,

1. 2. 1. 1. 1. 1. 1. 1. 2. 1. 1. 1. 2. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1-1. +2

のようになる.どうもイマイチなので,以下のように変えてみた.

1. 2. 1. 1. 1. 1. 1. 1. 2. 1. 1. 1. 2. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1-1^2

これ以上複雑になることはないので,とりあえず,これでゆくことにする.⇒最終的には,以下のような書式を採用することにした.

1. 2. 1. 1. 1. 1. 1. 1. 2. 1. 1. 1. 2. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1-1*2

「.」で区切られた単位が完全木上のノードを示す番地であり,-1*2はその枝番(詳細付番)に相当する.詳細付番付きの番地はアドレスコードの終端にしか現れない.パターンとしては,a-b, a*b, a-b*cの3種だけだ.a-bは3倍数を示し,a*bは2倍数,a-b*cは3倍数に接続する2倍数である.これですべての整数にユニバーサルなアドレスコードを与えることができるようになった.

コラッツ完全木検定と呼ぶことにする

画面要素が確定していよいよコラッツ中核木に掛かるという段階だが,もう少しだけ考えてみたい.ゼルコバの木コラッツ特注版は基本的に保存機能を持たないビューアとしてリリースするつもりなので,画面にコラッツ木を表示するためには毎回CSVファイルをインポートしなくてはならない.出力される5種のCSVファイルにはそれぞれ固有の名前が付せられているが,中核木と一般木を区別することができないのはかなり不便かもしれない.これを避けるために,たとえばCollatzTree.CSVであれば,CollatzTree.Core.CSVなどのようなサフィックスを付けることが考えられる.これは大した手間ではないのでやっておこう.

Truncated treeというのも少し意味不明なので,Stem Treeという名称に変更することにする.日本語でも幹線木という呼び方をしているので,この方が実態に即しているのではないかと思う.trucated treeをstem treeと呼ぶことにすると,今度はStem treeとCore treeの混線が生じる可能性がある.この意味では,やはり,Core Treeではなく,Complete Treeの方がよいのではないか?ラベル上の問題なので後回しでもよいところだが,どういう印象になるか確認してみたいので,修正してみよう.「コラッツ完全木検定」というのが製品の正式名称だ.

もう一つ,Collatz sequenceの出力は倒立木として表示したい.これはルートである1が最下段になるような図式だが,コラッツ数列を模式化した場合には1が最下部になるような図になることが多いためだ.Collatz sequenceの出力とAddress to numberの出力が完全に同じになるというのはあまりおもしろくない.やはりこの2つは完全な逆演算になっていなくてはおかしい.あとは,branch order sequence が tree address=tree locationに他ならないという説明を加えるだけでシステムの全構図を把握できるだろう.

いや,locationという用語を用いないで,最初からaddressでもよいのではないか?IP addressという用語はすでに十分浸透しているので,そこから類推できると思う.⇒Collatz sequenceの出力を倒立木として表示するという修正は簡単に終わった.いよいよ本線の修正に入る.3倍数を取り除くというのは難しくないので,それほど掛からないのではないかと思う.古いロジックは参考にはなるが読解の妨げになるので,除去してしまうことになるだろう.CompleteTree

▲GetPageCountでエラーが出る

▲完全正則で左右対称なのに吊り位置にずれが出る.

少しややこしい問題が出てきた.コラッツ木生成を完全木対応に書き直すのは容易にできた.コラッツ数列の場合は開始ノードを奇数Nとすると,Nがどのような値であれ,1に至る経路は必ず存在する.この経路上には3倍数は登場しない.従って,コラッツ数列取得では完全木モードと一般木モードの動作は一致する.うまり,同じ関数で処理できる.しかし,その逆演算は必ずしも可能ではない.

たとえば,3倍数15のアドレスは一般木上では1.3.1.1.1と表示されるが,完全木上には15というノードは存在しない.銀河系ではこのような状況をどう始末してきたのか?銀河系ではコラッツ数列取得に限り,仮想木と一般木を併置する形式になっている.15の場合であれば,以下の2つの経路が提示される.

15 23(1) 35(1) 3(2) 5(1) 1(1)
15 23[1] 35[1] 53[1] 5[3] 1[1]

枝番号変換ないし幹線木図では上の2者のうち前者だけが採用され,純仮想木としての計算を実行する.やはり,これしかないのではないだろうか?仮想木上でアドレス(1.1.2.1.1)を適用すると,15が表示される.ただし,これは15が仮想木上の実ノードであるためであり,つねにこの逆演算が可能という訳ではない.たとえば,N=45の場合,

11 17(1) 3(1) 5(1) 1(1)
45 17[2] 13[1] 5[2] 1[1]

が併置されるが,仮想木上のアドレス 1.1.1.1で枝番号変換を実施すると,結果は45ではなく,11が表示される.完全木にもこれに類似した仕組みを導入するしかないが,仮想木の場合には,45と11の関係は比較的はっきりしている.11は45の兄弟ノードのうちの長子であるので一意に決定することができる.しかし,完全木には3倍数以外のすべての兄弟ノードが含まれているので,代替ノードを指定するというのもかなりあいまいなものになる.考えられる対応策としては,直近の兄ノードを指定のような感じだが,場合によっては兄がいない場合も考えられる.

代替案としては,たとえば,親の子ども枠の中に現れる3倍数の順序で決めるということも考えられなくはない.たとえば,最初の3倍数であれば0,2番目であれば-1,5番目であれば-4のような負の枝番号を与えるということが考えられる.このような標識があれば,そのコードから厳密なノード番号を割り出すことも不可能ではない.ただし,このような0以下の枝番号は完全木のアドレスコードの終端に現れることはあっても,中間には出現しない.仮にこのようなコードを使うとすれば,3倍数用の枝番号は0発進よりは-1から始めた方がよいかもしれない.

しかし,完全木モードで完全木の経路を扱っているところに一般木経路が潜り込むというのもあまり芳しくないような気がする.むしろ割り切って枝番号0を与えるというのでもよいのではないか?たとえば,上の45の例で言えば,下記のようになる.

45 17(0) 13(1) 5(2) 1(1)
45 17[2] 13[1] 5[2] 1[1]

完全木上では17→45という枝は存在しないことを17(0)で示している.アドレスコードでは1.2.1.0となるが,最後の0は評価できないので,親ノードの17で止まることになると思われる.これは已むを得ないのではないだろうか?仮想木経路と完全木経路の相違点は,前者では一般木経路から大きく迂回するような経路があり得るのに対し,完全木の場合は終端との接続ポイントを除けば一般木と完全木の経路は完全一致するという点だ.しかも,このようなことが起こるのは3倍数に限定されているのだから,割とわかり易いのではないだろうか?大体これでよいのではないかと思う.コラッツ数列取得処理ではほぼ一般木の論理がそのまま使えると考えてよいだろう.

しかし,3倍数に関しては負の枝番号を与えるというのもそれほど悪いアイディアというものでもない.仮にこれが導入されると,コラッツ木上のすべての奇数にユニークなアドレスを与えることができるようになるからだ.これは悪くないのではないか?確かにやってみる価値はあるような気がする.ただし,一つだけ問題がある.コラッツ完全木が完全正則木であるとすれば,本来そこに含まれないノードのアドレスを与えたとき,どのような図面が描画されるのだろう?

  1. コラッツ木生成では本来の完全正則木しか描画されない
  2. コラッツ数列取得と枝番号変換処理で出力されるコラッツ木はチェーンであり,その終端に1個3倍数を追加してもあまり問題ではない
  3. 幹線木図ではどうなるか?幹線と言っているのは,上記のチェーンであり,それらに枝数分の葉を追加しただけのものだから,問題はない.幹線木図の終端ノードはつねに単独で枝を持たないのだから,それが3倍数であっても特に問題ない
  4. 検証テストはどうなるか?検証テストはコラッツ数列取得と枝番号変換処理を組み合わせたものであり,この両者が動作すれば動作可能なはずだ.対象ノードから3倍数を除去した部分だけテストしてもよいが,もし可能なら全点テストする方がよい.多分それは可能だと思う.

これで,3倍数を間引かないで全点テストできる可能性がでてきた.この方が望ましいと思う.ただし,論理が多少込み入ったものになることは避けられない…アドレスを以下のように表記することは可能だ

1.2.3.4.5-6

この方式なら枝番号に負値を与える必要もない.最後の-6を負値と解釈してもよいが,その意味するところは「親ノードの6番目の3倍数」ということになる.1, 2, 3などの(正の)数は3倍数でないノードだけを数えた枝番号,-6は3倍数だけを数えたときの枝番号ということになる.

ただし,Splitという関数はこのような複合的な書式を扱えないかもしれない.どこかでそういうことをやった記憶はあるのだが…PythonやC#にはあるようだ.VBのSplit関数にはこの機能はないが,Replaceを使って文字列を置換して区切り文字を統一するという方法がある.ただし,どこに「-」記号が入ってくるか分からないので,やはり,別途調べるしかないかもしれない…⇒昔C++でやっていた.どこかからコピペしてきたものと思われるが,list<string> split(string str, string delim)という関数を使っている.

list<string> split(string str, string delim)
{
     list<string> result;
     int cutAt;
     while ((cutAt = str.find_first_of(delim)) != (int)str.npos ){
         if (cutAt > 0) { result.push_back(str.substr(0, cutAt)); }
         str = str.substr(cutAt + 1);
     }
     if (str.length() > 0){ result.push_back(str); }
    return result;
}

アドレスコード的には上記の方式がスマートだが,こだわらなければ下記が最短だ.

1.2.3.4.5.-6

これなら現行論理でも簡単に分離できるし,数の正負を見るだけで判定できる.これでよいことにしよう.これで行けるとすれば,次のような方法も考えられる.UI的には上記方式で行うものとし,内部で「-」を[.-]に変換した上で通常のようにSplitすればよい.これが一番スマートなのではないか?しかし,ユーザの混乱を避けるという意味からすれば,やはり,区切り文字は「.」に限定し,数字の正負で判定というのが正しいような気もする.(説明もこの方が簡単だ)まず,コラッツ数列取得から始めよう.3倍数は終端にしか現れないから,完全木と一般木で同じ論理の使い回しができるのではないか?

とりあえず,コラッツ数列取得はできた.次は枝番号→番号変換だ.⇒いや,まだできていない.一般木の枝番号を使っている.やはり関数を分けた方がよいのではないか?⇒一つの関数で間に合いそうだ.枝番→番号変換まではできた.幹線図はどうか?⇒大体終わった.検証テストも動作している.ただし,3倍数の一部の脱落が起きている.どうも隣接リストの操作に不備があるように思われる.あるいは,コラッツ数列と枝番号の受け渡しに問題があるのかもしれないが…

ゼルコバの木コラッツ特注版をASAP公開

ゼルコバの木コラッツ特注版をリリースするという方針を決定した.これは系図作成の原点に立ち還るということであり,知らず識らずのうちに大きく道を逸れていたことに気付くのがあまりに遅かったとは言え,まだ快復のすべは残っている.隣接リストとして与えられたコラッツ木データを例外処理としてではなく,基本処理として安定かつ高速に処理できるよう仕立て直さなくてはならない.その上でもう一度既存論理を見直して,どこでどう曲がってきたのかを洗い出す必要がある.

まずは,ともかくコラッツ中核木生成ツールとゼルコバの木が完全一体とは言わないまでも十分スムーズに連携できるようにするところから始めよう.すでにゼルコバの木では隣接リストをインポートして描画できるようになっている.これができるとコラッツ木生成ではあえてゼルコバの木一覧表形式でファイル出力する必要がなくなるので,仕様の簡素化という意味からも,ゼルコバの木CSV形式で出力というオプションは廃止すべきだろう.この修正が入れば,画面レイアウトは完全に固まったことになるので,いよいよ内部ロジックの修正に移ることができる.

▲コラッツ中核木のCSVをインポートしてCheckDispSizeで停止した.⇒これは「この図面はxx%以上には拡大できません」という警告を表示するためのものなので無視してよい.というか,それ以上に拡大した場合には生描画という方法があるはずなので,この警告自体表示しなくてもよいのではないか?また,描画用ビットマップサイズの制限がメモリ容量に関係するものであるとすれば,もう少し大きなビットマップを予約することも可能なのではないか?最終的にエラーが出た場合には,その旨表示して処理を中断すればよいのでは?

確かに生描画で描画は可能だが,画面の更新にかなりの時間を要するようになる.やはり,ビットマップの拡大を考えた方がよい.

▲インポート処理中はカーソルを砂時計表示する

▲64点のCollatzNumber.csvをインポートして,終端の65539でソートしようとして,GetGenerationエラーになる.

2^13の検証テスト結果をインポートして,最大カード数をオーバーする.⇒そのあと,ImportTabelFuncでインデックスが配列の境界外エラーが起きる.VerifyTest.csvのレコード数が15841になっている.レコード数をカウントして打ち切っているはずなのだが…それを変換したVerifyTest.ZEL.CSVでは17145点で却って増えている…ループが二重になっているため,脱出できていない.⇒対処した.

MDIParent.vbが読み取り専用で開かれている.なぜだろう?⇒エクスプローラ→フォルダのプロパティで読み取り専用を解除して使えるようになった…⇒デバッグ中は修正できないという意味では?

VeriflyTest.csvをインポートしてフェーズの遷移エラーが発生した.PHASEは9:DECOMPOSITIONで,modeは3:INITIALIZED.例外が発生している.-10001:メモリ不足だ.ヒープサイズはすでに1GB=1073741824バイトを予約してある.おかしい.ERR_NOMEMORYをスローしているすべての箇所にブレークを設定しているのに止まらない.fatalerrorにエラーコードを格納してからスローしているので見つからなかった.

TRIBEBOXオブジェクトを生成する段でメモリ不足が起きている.1064580バイトを請求しているが多過ぎるのではないか?TRIBELISTにリストノードとして追加しようとしているところだ.無数のTRIBEBOXを生成しようとしている.おそらくこれはカード数オーバーで処理を打ち切っているためだろう.このため親を失って孤児となったノードが無数に発生しているものと推定される.

それにしても,TRIBEBOX1個で1MBというのは大き過ぎる.⇒MAXIMALGRAPHを抱えているためだ.このオブジェクトはそれだけで1064120バイトある.これを系列枠ごとに持つ必要はあるのだろうか?MAXIMALGRAPHは大きい配列を2つ持っている.一つはSEGMENT配列,もう一つはMARGBOX配列だ.どちらもMAXPDB+MAXMDB+1のサイズを持っている.

対策を考える前に,エラーが発生したときの後処理を見ておこう.⇒「検定に失敗しました」のパネルが出るのはよいが,そのあと制御が戻ってこない.VBのInitializeDisplayではエラーを見ていない.いや,もちろん見ているが,そのあとOpenFileProcでCloseDataBaseを実行しようとして沼に嵌まり込んでいる.VBは致命的エラーのときは,FatalErrorを実行してアボートするようになっている.Z.mSendCardではメモリ不足時はそれを実行している.InitializeDisplayで「検定に失敗」したときには,FatalErrorでアボートするようにした.

▲Ancestry.zelでgetnodeegneのエラーが発生するので,SUPPORTSIMPLEGRAPHを完全に止めた.この結果(であるかどうかは確定できないが)topologicalSortの出口検査でInvestigateHSplitsのエラーが発生するので,これも一時停止した.

MAXIMALGRAPHをシステムに1個で動作可能かどうかを調べてみよう.⇒MAXIMALGRAPHは温存し,その中のSEGMENT[]とMARGBOX[]を外に出してみよう.⇒問題なく動作しているように思われる.⇒いや,結構問題がある.SEGMENT[]とMARGBOX[]はMAXIMALGRAPHのprivateメンバーとし,系列枠から直接アクセスできないようにした.

特に問題なのは,MAXIMALGRAPHで「近傍系列検定」というのをやっているという点だ.暫定的にこの処理は停止することにする.近傍系列検定というのは系列が他系列と接触しているか否かを問題にしているので,基本的にはスプリット検定などでカバーできるはずと思われるのだが…もし,それができないとしたら,なにかもう少しましな「広域検定」を編み出すしかないかもしれない.とりあえずのところは「大体動いている」というところだ.

GetAncestorsListで時間をバカ食いしている.先祖ノードが3480個もある.おそらくその大半は孤立ノードだろう.この敗因はおそらく,先祖テーブルに人名リンクではなく,参照番号を格納しているためだろう.このため,参照番号からカードを取り出すという余分なコストが掛かっているものと推定される.このテーブルに番号を格納しているのは,先祖並び替えのとき,アプリに引き渡す必要があるためと推定される.⇒いずれにせよ,これでは日が暮れてしまう.一旦打ち切ることにしよう.2^12に落としてみよう.⇒出た!

image

形状は前回表示した2^11と酷似している.前回はD=8, H=96,3236点だが,今回もD=8,H=96は変わらない.ノード数は3236から6510に増加している.点数が倍増しているのに形状がほとんど変化しないというのはフシギな感じがする.範囲を拡げたらどうなるのか,ぜひ見たいところだが,いまのところここまでが限界だ.表示までに191秒,約3分掛かっている.これににはCSVをインポートするまでの時間は含まれていないので,全体では5分近く掛かっているのではないだろうか?サンプルは確かにゼルコバの木的には巨大サンプルだが,ビッグデータと呼ぶほどのものではない.もう少し高速化の余地はあると思われるが,先にUI的な部分を手当しておくことにしよう.

主要機能5種に対し,CSVファイルは6本出力されている.これはコラッツ木生成では一般木と仮想木で異なるファイル名を使っているためだが,どちらかに統一した方がよい.とすれば,一般木と仮想木で同じファイル名を使うというのが妥当だろう.CSVファイルを出力したときには,メッセージパネルを表示するようにした.

壊れたポットの代わりに炊飯器を茶釜に

今日はこれまでで一番冷え込みがきつい.特別給付金が振り込まれたら灯油を追加購入しようと思っているのだが,市役所からは何の応答もない.ポットも壊れてしまったので,炊飯器を茶釜代わりに使っている.まぁ,これもそれなりに「優雅」な気がしないでもないが…

IMG_20220220_225526  IMG_20220220_225651

それよりも,床が沈んで冷蔵庫が傾いている方が問題だ.わたし自身が,身体的に傾きかけていることの象徴のように見える.もう,終わりも近いのかな?つまり,いよいよ末期に突入ということだろうか?

コラッツ高速道路系はプログラム的にはほぼ完成し,マニュアルを書くだけという段階に達しているが,ここに来て,「完全正則コラッツ木を構成するためのもう一つの方法」というのが見つかってしまったため,急遽方向転換を図る必要性が出てきた.もう一つの方法というのは至って単純なもので「3の倍数ノードを一律除去する」というだけだ.コラッツ核木ないしコラッツ長子木と呼ばれるこれまでの方式は,あるノードの子ノード,つまり兄弟ノードを一括して長子ノードに代表させるという方法だが,この方法にはいくつか問題点がある.

一つは,1と5が直結しているため,この状態では完全正則木とは呼べないという点がある.これはある意味で1と5という2つの整数の特殊関係を示すものとも考えられるので,一概に退けるべきものではないが,完全正則木として扱うためには5をルートとしなくてはならないということを一々説明しなくてはならないというのもかなり厄介な話だ.

梶井基次郎の「櫻の樹の下には」ではないが,コラッツ木の根本には小さな有向サイクルが埋まっている.つまり,(1, 2, 4)という有向閉路だ.これはコラッツ予想問題の鍵とも言うべき急所だが,1ではなく5をルートとして議論を進めるというのはあまりわかり易いストーリィではない.(1は地中に埋まっていると言って納得する人はいるだろうか?)また,本来なら行き止まりであるはずの3の倍数ノードが処々に出現するというのも分かりづらい点かもしれない.また,この構成では素数の一部が完全正則木に含まれないという状況も発生する.これらの難点は,3の倍数を正則木から除去することで一挙に解決する.

この意味では明らかに後者の方式に分があるように思われる.実際,以前コラッツバスケット上で問題を考えていたときにも,3の倍数を除外するというスキームを試みたことがある.このときは,それによっても問題がほとんど易しくならないので一旦は放棄されたコースではあるが,むしろこちらこそ本線なのではないだろうか?

コラッツ銀河高速道路系には,一般道路と高速道路という2つの系統の区分があり,その「相互乗り入れ」つまり,インターチェンジというのが計算上の難所になっていた.このような問題はすでに全面解決しているのだが,それらの成果をすべて捨ててまた振り出しに戻るというのもかなりきついものがある.しかし,シンプルイズベストというオッカムの剃刀の原理に従うとすれば,選択の余地はない.

ここで方向転換すると「コラッツ銀河高速銀河系」はまったく使われないことになる.なぜなら,3の倍数ノードを除去したコラッツ木には一般道路と高速路という区別は存在しないからだ.しかし,せっかくここまで練り上げたものをただ捨てるというのももったいないので,ともかく,完全に仕上げてからお蔵入りさせるということにしたい.というか,すでにその水準に達していると思われるので,いまここで「コラッツ銀河高速道路系」を恒久的に凍結するというのでよいのではないか?これまで使ってきた「仮想木」という概念も破棄されることになる.

銀河高速道路系というイメージを放棄するとしたら,3倍数を除去したコラッツ木のイメージをなんと表現すればよいだろう?この道路網の特徴は中心点から全方向に放射状に道路が伸びているという点にあるので,コラッツ放射線道路システムとでも言うことになるのではないか?この道路網の特徴はノードを水平に接続する環状線がまったく存在しないという点にある.つまり,合流点以外の交差点は存在しないという道路網だ.英訳すれば,Roads radiating in all directionであり,Radial Roads と呼ぶこともできる.

direction-choices-and-career-decisions-with-a-businessman-standing-E1E27J

このイメージを採用するとすれば,プロジェクト名はコラッツ放射線道路系,Collatz Radial Roads Systemということになる.ちょっと膨らみのない名前になってしまうが,もっと直截に表現するとすれば,Collatz Complete Regular Treeということになるので,これまで使ってきたCollatz Tree GeneratorをCollatz Complete Tree Generatorとすればよいのではないだろうか?少し長くなるが,これが状況を一番よく表現しているような気がする.あるいは,Collataz Complete Treeでもよいかもしれない.これが一番わかり易いのではないか?

Collatz Complete Treeというのは正しいネーミングであると思われるが,むしろ,これまで使ってきた,Core Treeという方が直感的かもしれない.Complete Treeというと,正則であることを説明し,それが完全正則であることを付け加えなくてはならないが,Core Treeと呼べば必要かつ最小限の核に該当するということは理解され易いのではないか?従って,製品名はCollratz Core Tree つまり,コラッツ中核木ということになる.これでゆくことにしよう.

ゼルコバの木の開発用フォルダが5GBを超えている.本来このプロジェクトは高々2MBくらいだったと思われるので※,5GBもあるというのは異常だ.この原因は.vsというフォルダにある.このフォルダ一つだけで5GBを超えている.このフォルダはテキスト入力補完のための使用頻度の高い語句を収納した一種の辞書のようなものだが,このようなものがプロジェクトフォルダの内部にあるというのは問題だ.以前は外部に置いていたような気がするのだが…しかし,どこで調整すればよいのだろう?⇒方法が見つかった.

※2MBというのはさすがに過小評価だ.ゼルコバの木アルファ版のころはそのくらいだったかもしれないが,現在は開発用フォルダ全体で730MBくらいはある.

https://stackoverflow.com/questions/19398287/ipch-files-on-a-visual-studio-project/41138541

ツール→オプション→テキストエディタ→C/C++→詳細設定→フォールバック位置で「つねにフォールバック位置を使用」をオンにすると,システムの固定の場所を使うようになる..vsフォルダをまるごと削除してみよう.ソリューションを開くとこのフォルダは再生してしまうが,ipchフォルダは消えて,以下のようなメッセージが表示される.

image

上記のフォルダに既存のipchフォルダをコピーしてやろう.⇒うまくいったようだ.これで個別フォルダに入っているipchは不用になったので,削除しておこう.1個が5GBもあるので相当な量になる.⇒いや,こういう状態になったのはつい最近,つまりOSを再インストールしてからのようだ.それまでは「適切な場所」に保管されていたようだ.

画面レイアウトは基本的に従来通りだが,ラベルの付け替えを行った.

  1. Virtual tree → Core tree
  2. Degree → Max-branches
  3. Get branch position → Branch Location
  4. Verify → Verification test
  5. Get the sequence → Get Collatz sequence
  6. Get the number → Address to number
  7. Enter a branch order sequence separated by comma → separated by period

グラフ理論で一般的に定義されているdegreeと我々の用語の食い違いを調整するため,Degreeという名称を廃止してBranchに統一した.Sequenceという用語はコラッツ数列と枝番号列として使われているが,枝番号列はBranch Locationを指定するためのアドレスとして用いるということを明確にするために,Get the numberはAddress to numberに変更した.Branchという語は支店という意味で使われるのでBranch locationというと「支店所在地」のような意味になってしまうが,このコンテキストでは「木の枝」を扱っていることは明白なので多分誤解を招くことはないのではないかと思う.

コラッツ数列というのは,13→40→20→10→5→16→8→4→2→1のような「コラッツ写像」から導かれる数列で,コラッツ予想問題をやっている人には一番わかり易い表現ではないかと思う.コラッツ数列→コラッツ木アドレス→奇数→コラッツ数列の変換がもっとも重要なポイントであり,そこの点を飲み込んでもらう必要がある.

ゼルコバの木を改造して隣接リストをインポートできるようになれば,外部出力は隣接リストだけで済むことになるので,まずそれを決めてしまうことにする.コラッツ問題を解析する上でゼルコバの木の重要性は増しているので,コラッツ中核木生成ツールのリリースと前後してゼルコバの木コラッツ特注版をリリースすることに決めた.

コラッツ木はもっともシンプルな系図木であり,この図面が描画できないようでは話にならないというところから考えても,一度原点に戻って論理を洗い直す必要があると考えている.既存ゼルコバの木は高度な機能/パフォーマンスを求めるあまり,やや偏極する方向に逸れてきたのではないかと思う.このバイアス(歪曲)を戻してオーソドックスに戻る必要がある.このためには,まず,このコラッツ特注版が安定かつ高速に動作するところから始めなくてはならない.

現行ゼルコバの木のメニューでは「一覧表のインポート」でCSVファイルを読み込んでいるが,隣接リストは一覧表データではないので,独立のメニューコマンドとして「隣接リストのインポート」を追加することにする.⇒大体できた.いい感じだ.ファイルをインポートしたときには,デフォルトで画面に合わせてズームで開くようにした.実用的に使えるようにするためには,①テーマの登録と選択,②部分図登録の部分がきちんと動くようにしておく必要がある.現行では標準画面設定は枠線なしになっているが,枠線ありで最小幅とした方がよい.⇒登録しようとしたら,エラーが発生して異常終了してしまった.「パスへのアクセスは拒否されました」となっている.

IO.File.Move(selectname, newname)というコマンドを実行しようとして拒否されている.このコマンドはファイルの移動ないしリネームを実行するためのものだ.オリジナルファイルを退避させる目的で実施されているものと思われる.フォルダは一部読み取り専用になっていたので,解除してみたが動作は変わらない.エクスプローラで手動で変更することはできる.プログラムからの変更はできないようになっているのだろうか?このファイルはProgram Files (x86)/Common Filesに入っているので,アクセス制限が掛かっている可能性はある.⇒ファイルの所有者がTrustedInstallerになっている.これはかなり厄介だ.いつからこんなことになったのだろう?

設定ファイル類をここに置いているのは,ドキュメントなどに置くとそのユーザしかアクセスできなくなることを避けるためだったのだが…そうしないと,インストール時のオプションで「誰でも使える」とする意味がなくなってしまう.⇒VSを管理者モードで起動すれば変更できる.多分一般ユーザも管理者としてログインしていればプログラムから変更できるのではないかと思う.これは確認する必要があるが…

▲画面設定を変更して保存→終了しようとして,PAGESETUP::GetPageCountで停止した.(treeview()->validcard && !NearZero(wholeH % GH))という状態になっている.全体高=1005でGH=190から,1005/190=5…55となり,余りが出てしまっているためだ.この理由は後日調べるということにしておく.⇒上記で再登録した標準設定は動作しているようだ.

▲TruncatedTree 14を206307でソートしようとしてGetGenerationで停止した.(_generation < 0 && !showUnderWear)で_generationの値が-4になっている.絶対座標系では世代番号は負にはならないことになっているのだが…かなり始末が悪い.シューティングが必要だ.

要対処項目リスト:2022-02-17

要対処項目:125件:2022-02-19

外部項目:31件

  1. zelkova-treeとayanetのアカウントから送信できない.ayanetではコマンドがrejectされ,zelkova-treeでは送信中のままになる
  2. WPOSTファイルのテキスト検索はGoogleのサイト検索を使って行う
  3. XOOPSでlocalhostのパスワードが流出している
  4. nasu@zelkova-tree.net のパスワードが流出している
  5. AYAネットへのFTPアクセスとメール送受信が可能になった
  6. Open Live Writerの画面レイアウトが平常に戻った
  7. Open Live Writerのデフォルトフォントが設定できない
  8. AYANETのメールサーバー設定では,送受信ともSTARTTLS, 通常のパスワード認証として通った.メールサーバはpop.aya.or.jpとsmtp.aya.or.jp
  9. AYAネットから送信したメールがoutlookで迷惑メールに落ちてしまう.zelkova-treeから送信したメールも同様だ
  10. 外部接続ポリシーを変更して,開発機を常時ネット接続することにした
  11. OSのクリーンインストールをルーチン化する VS2017ではInstaller Projectという拡張機能のインストールが必要
  12. 開発機・FF機の2台のOSをクリーンインストールした 2022/02/14
  13. 「暗号化された通信で接続しましたが,接続したサイトの信頼性を確認できません」に対処する
  14. コラッツ木生成ツールをリリースしてownCloudにアップロードした
  15. AYANETにメール送信時,GmailアカウントにCCしたが入ってこない.
  16. テストメールというタイトルの不審メール4通を着信した
  17. Outlook.jpのパスワードを変更しても,メールを受信できてしまうのはおかしい.
  18. Outlook.jpのパスワードはマイクロソフトアカウントと連動しているが,「お使いのアカウントの一部に注意が必要です」という警告が出るだけで,サインインできてしまう.
  19. 2022/01/31 AYANETにパスワード変更依頼を送信した時期に複数の不審事案が起きている⇒いくつかの対処策を実行した
  20. カスペルスキーの「Microsoft Windows Operating Systemの保護されたトラフィックは監視されていません」という警告⇒以下の方法で対処 カスペルスキーのルート証明書を Mozilla Firefox 及び Thunderbird に追加する方法(個人向け製品)Kaspersky / カスペルスキー 総合176 https://support.kaspersky.co.jp/14620#block4
  21. カスペルスキーはownCloudとWordPressのログインIDを区別できない⇒ownCloudに別ユーザを登録してそのIDでログインするようにする ⇒ この措置はあまりうまく行っていない
  22. ownCloudにアップロードしたファイルがフォルダごと消える ローカルフォルダには残っているが,同期できない さらにファイル2つが消える
  23. カスペルスキー通知センターからの警告が入る ⇒ EXEを削除して完全スキャン
  24. 予備機に黒い画面が出現「ZZZZZ…」のような不明テキストが表示されている
  25. カスペルスキーから奇妙なメッセージが入った.「It’s lonely here! Your sensitive PDFs are waiting to get into the vault.」⇒カスペルスキーのVaultには任意のファイルを暗号化して保存できる.ここにパスワードリストを置くことは考えられる.
  26. Acrobat Readerはデフォルトで「起動時に保護モードを有効にする」がオンになっているため,印刷できない
  27. LibreOfficeの作業は開発機で行う
  28. LibreOfficeの日本語ヘルプをダウンロードする
  29. LibreはWindowsのメタファイルへエクスポートできる 読み込みも可能?
  30. 外付けHDをFF機に接続しようとすると落ちる
  31. 2021-12-25 VAIO機がネットアクセス不能となり,2 in 1に切り替え

改修履歴:1件

  1. 2^12までの検証テスト結果をエクスポートしてゼルコバの木で描画できるようになった.最大カード数は暫定的に7000点に設定している.デフォルトズーム倍率を1%として運用している

解決済項目:3件

  1. VS2019 .NET 5.0ではEXEとともに随伴するDLLを生成しているが,ソースコードに大幅な修正を入れてもどちらもほとんどファイルサイズに変化が見られない
  2. 検証テスト中枝番号リストを更新していたため過大な時間ロスが生じていた
  3. 仮想木⇔一般木の切り替えでRoot numberを変えないようにした

仕様/マニュアル/テスト項目 29件

  1. コラッツ銀河高速系ではスタックサイズを400000H,ゼルコバの木ではスタックとヒープをそれぞれ400000Hに設定している
  2. GetTheSequenceは1を与えられたときに返す値がないので無出力となる 枝番号リストを指定してコラッツ数列の逆演算を実行する場合,「空」が与えられた場合には1が出力される
  3. 検証テストの対象奇数領域を拡大した場合,コラッツ亡霊木の形状はどのように変化するか?
  4. B面で検証テスト以外の機能を実行したとき,メール送信ボタンがアクティブになっている⇒特に実害はないようにも思われる
  5. 一般木:N(k)=(M(k)-1) / 3 = (4^(k-1)N*2^c – 1) / 3
    仮想木:Nの長子をFとして,N(k) = ((3F+1)4^(k-1) – 1) / 3
  6. ノードNの子ノードの数列で3の倍数になるノードは3つ置きに出現する
  7. Odd numberの最大テキスト長を2147483647にしてみたが,表示が消えてしまう.ただし,中身は入っているように思われる.⇒数字が表示されていない場合でも保持されている内容は正しいことを確認する ⇒スクロールバーを付ける?
  8. Get the Sequenceにはまだ高速化の余地があるのではないか?
  9. 検証テストでNまでのコラッツ数がパスしたとして,N以下のすべての奇数がテストをパスしたと言えるか?⇒言えない.テスト範囲に含まれない奇数は存在し得る.ただし,非コラッツ数はすべていずれかのコラッツ数に接続すると言えるから,検証テストは不用ということは言える.⇒同一設定のとき,仮想木と一般木でDとHは等しい,と言えるか?⇒Dは異なる場合があるが,Hは一致しているように見える.⇒非コラッツ数をMとする.(M-1)/4は奇数M’でM'<M.M→M’→M”…M°となるようなコラッツ数が存在するから,M<Nであるとすれば,M°<NでNまでの検証テストに含まれる.従って,検証済みと言ってよい
  10. コラッツ数列取得で仮想木モードのとき,先頭行の右と左の値が等しい場合は,コラッツ数である しかし,一般路と高速路で同じ経路になるとは限らない
  11. 無量大数X=10^68Xコラッツ仮想木のどの位置に現れるか.D=5,H=549にX+1が配置されている.ポジションリストは{1, 3, 1, 1, 2,….1, 1, 1, }のようになる.これが無量大数+1の仮想木上の位置だ.いや,この数字は間違っている.これは10^64+1だ.いずれにせよ,無量大数の位置を確定することは可能だ.
  12. 一般木をCSV出力したとき,コラッツ数と非コラッツ数を色分け表示する
  13. ビルドで生成されるnet5.0-windowsフォルダには実行には不用なファイルが含まれている.これらは配布パッケージからは取り除くべきだ.
  14. 仮想木モードでRoot numberに非コラッツ数を指定したときの動作を確認する⇒ルートノードは非コラッツ数でそれ以外はすべてコラッツ数になる?「与えられた数字がコラッツ数でないときには,メッセージを出してコラッツ数に切り替えることを通知する」という記述もあるが廃止されたようだ 出力を比較してみた方がよい
  15. コラッツ木構造図に含まれていた漸化式の間違いに関する修正を入れる ①N(k) = 4N(k-1)+1,②N(k)=(M(k)-1)/3 : M(k+1)=4M(k) ①と②が等価であることの証明を与えた
  16. MilkyHiwayのアイコンをデザインする
  17. 隣接リストファイルをゼルコバの木で直接読み込めるようにする
  18. 出力枠のテキストを切り詰めるとき,行単位としていた仕様を廃止
  19. 枝番号リストは「郵便番号」Postal Codeとして表記することにする いや,Address Codeの方がよい ないし,Branch Codeとする DegreeはNumber of Branchesとする
  20. 正則コラッツ木のPDFサンプルを同梱する 3-8-766
  21. ダンプ出力は切り詰められているため,最初の一行は正しくない可能性がある
  22. 用語の調整・統一
  23. ゼルコバの木で隣接リストCSVを直接読み込めるようにする.これができれば,ゼルコバの木CSV出力はなくてもよい
  24. 3の倍数ノードの個数は正確に有効ノード数の1/3
  25. ノード番号を基準番号として用いる場合にはInt32を超える値を設定できない⇒現行ではノード番号を直接基準番号とするのではなく,通番を与えている⇒コラッツ木生成ではそうなっているが,それ以外ではノード番号が使われている.
  26. 完全正則木を生成するもう一つの方法として,3の倍数ノードを除去するという方法もある
  27. Val(str) で文字列を数値に変換するとき,Integerの上限よりも大きいがUlongの上限よりは小さいような奇数文字列を変換しようとすると,偶数に化けてしまう
  28. Parseという関数はテキストが空文字列の場合には例外を発生する
  29. ノード数は奇数になる場合も偶数になる場合もある.必要な条件はノード数-1が3で割り切れるかどうか?だ

ゼルコバの木項目:47件

  1. コラッツ専用版で行った暫定修正をフィックスする必要がある.①デフォルトズーム倍率,②重婚検定のパス,③MakePariListCleanのパスなど
  2. 系図ファイルのアイコンをダブルクリックしてアプリ起動するとエラーになる
  3. テーマが登録できない.テーマ登録は実行されているが,メニューに表示されないので選択できない
  4. 参照番号とテーブルのインデックスが一致しているという標準仕様を廃止
  5. デバッグ時のダンプはすべて止めたが,”CenteringCard Refnum=0”が残っている
  6. 登録カード数1631はゼルコバの木的には特大だが,単系列の単純な木で描画までに3分掛かるというのはおかしい
  7. 「インデックスが配列の境界外です」というエラーとBobject::originateのエラー,「結婚点一致検定ループカウントオーバー」は関係しているものと見られる
  8. 部分図の属するノードをカラー表示する
  9. 部分図を設定したのに保存しないで閉じてしまう 部分図を設定しても全体図で直ちにカラーが出ない 一度部分図に移動して戻ると着色されている
  10. 保存しますか?でライセンスキーが未生成だったので,キャンセルで抜けて正常終了のはずだが,EXEがロック状態になったまま開発環境で実行できない.タスクマネージャではプロセスは走っていない.
  11. どこかでハングしてしまった.父欄ダブルクリックで白紙カードが2枚できているが,画面上には1枚しか表示されていない.⇒選択状態がおかしくなっていたようだ.領域選択したら,その後は問題なく動作するようになった.
  12. 入力欄にカーソルを置いた状態でどこかカードをクリックすると,そのカードにリンクできるようにしたい.
  13. 既存カード氏名を父欄に入力→登録したはずだが,別カードが作られてしまった.⇒現行の暫定版(特注版)ではUNDOを止めてあるので,戻る操作ができない.⇒性別を見ているためだ.このカードは女子なので父にはなれない.
  14. あいまい選択でカード巡回パネルが出ているとき,パネルを移動できない.
  15. 一覧表をクリックしたとき,数字は辞書順ではなく,数値の大きさで比較して欲しい.
  16. 既存カード369を母欄に記入して,既存カラー表示されない.⇒やはり,新規カードが作られてしまっている.⇒性別が間違っている.
  17. 部分図に移動しようとして,PARTIALNAME::ExtractPartialCardのエラーになった.
  18. 現行では確定選択したあと,登録ボタンを押さないと登録が実行されない仕様になっているが,忘れることが多い.プロンプトを出すべきではないか?
  19. 部分図を生成しても,明示的に登録しないと保存できない.アプリ終了時にプロンプトを出すべきだ.
  20. 部分図画面を開いていて,部分図に登録して画面が更新されない.
  21. 実子と養子の違いはあるが,配偶者のいない結婚でページが2つに分かれてしまっている.
  22. どうも,かなり動作が悪い.803に父1205を登録して登録が消えてしまう.この状態でファイルをCollatzCoreTree 3-5-94 – BADとして保全した.親子関係の登録で親の親との関係が切れてしまうようなことが起こっているように見える.
  23. 純血統図というのは養親子関係を完全に無視するというのではなかっただろうか?多重カードが発生している.純血統図を解いたあとも図式が戻らない.多重カードを出して開きっぱなし.
  24. CollatzTreeCoreをダブルクリックで開いてフォントサイズゼロエラーになった.Collatz Tree 3-8-766.zelでも起きている
  25. コラッツ木構造.zelを保存しようとして,PAGESETUP::GetPageCountのエラーになった.
  26. Collatz 3-5-94.zelを開き,画面に合わせてズームしようとして,PAGESETUP::GetPageCountのエラーが出た.また,親子連結垂線が途切れている.人名枠幅を小さくしても変化しない.氏名だけが右にずれてゆく.人名枠ギャップは調整可能だが,結婚枠ギャップは変更できない.⇒独立に変更できないとしても,人名枠ギャップに連動して小さくできるようにすべきだ.⇒写真枠幅をゼロにしたら,人名枠幅が狭まった.⇒CubePDFに出力しようとしたら,ハングしてしまった.⇒VS2017を2つ立ち上げていたのが影響していたかもしれない.一つ落として出力できた.
  27. CheckCommitChargeでエラーが起きている
  28. 画面設定でチャンネル数をゼロに設定して例外が発生した.⇒一般のサンプルではエラーになっていないが,33点のチェーンではGENEBOX:findSameGeneで例外が起きる.GENELIST:AddSameChainで世代枠が空になっている.このサンプルをCollatzChain 32769-32.zelで保存して後日デバッグすることにする.
  29. 軸線図の動作を確認する
  30. Collatz Tree 3-8-766.zelを人名枠幅を調整してから印刷しようとして,GetPageCountのエラーになる.
  31. tamo2氏から預かった「保家系図4代まで」を開いてエラーが続出する.「セグメント値ゼロ」エラーが発生している.最終的には描画できる.このサンプルは外付けHDのVAIO2 BACKUP 2021-12-27…デスクトップ/新しいフォルダー/077保家に入っている.ファイルを閉じるときにもエラーが発生する
  32. 下図のような設定で,垂直親子連結線が兄弟連結水平線を突き出ている.サンプルはCollatz Tree 3-10-990.zel.
  33. 白紙で起動して最初にインポートしたとき,イレギュラーなフェーズ遷移エラーが起きる.いや,起動直後ではなく,すでにインポートを実施したあとだろう.
  34. CollatzChain.csvをインポートしてエラーが発生する.内容はCollatzNumber.csvとまったく同じ.ただし,カード並びが一方が昇順,他方が降順という違いがある.読み込み後は正常に描画できる.エラーはTRIBEBOX::CheckAbsoluteGenerationで起きている.理由は系列優先ノードのbreakupがオフという理由にある.breakupという変数は「重婚クラスタ検定で除去された結婚枝の当事者ノード」というものだが,それと「系列優先ノードの絶対世代番号不一致」がどう関係するのか飲み込めない.この関数は「系列優先ノードの物理世代番号を基準に絶対世代番号を振り直す.系列優先借りノードがbreakupノード(重婚クラスタ検定でパージされた結婚当事者)の場合,そのノードが本人ノードであっても,絶対世代番号と異なる位置に配置される場合がある得る このような場合,「系列優先ノードの物理世代番号を基準にその系列に属するすべてのノードの絶対世代番号を振り直す.」のように説明されているが,このサンプルでそのようなことが起きるとは考えづらい.⇒「コラッツ対応版応急措置@20211223」で止めておくことにする.
  35. ゼルコバの木の最新版とR20210317版で実施した修正の同期
  36. コラッツ1000.zelを開くのにかなりの時間が掛かり,マネージド・デバッグ・アシスタントが作動して停止する.
  37. サンプルは単純な木であるのに,ZTYW処理が作動している.暫定的にgoodsonを空としているため,例外が発生する.
  38. 人名枠高の計算がかなりおかしい.フォントサイズを大きくすると枠が伸びて世代境界を超えてしまう.しかも,人名が消えてしまう.系図画面設定でパラメータを変更しても画面に反映しない.⇒系統並び替えで正常に戻った.
  39. 親の垂線が兄弟連結線から突き出ている.⇒系統並び替えで戻る.
  40. 氏名欄で左右カーソルキーを押すと入力された文字が消えてしまう.おそらくこれは,カーソルキーに「カード移動」機能を持たせているためではないかと思う.⇒いや,違うようだ.上下カーソルキーでカード移動になっているが,左右カーソルはそういう動作にはなっていない.既存サンプルでは左カーソルで入力欄の左端にカーソルが移動してしまうが,文字は消えない…
  41. カード画面上部ツールバーの氏名欄に表示されている名前の後ろに余分なスペースが入っている.
  42. カード選択時に表示される赤枠は主選択カードを示すものだが,常時表示されているため,スクリーンショットを取るときには邪魔になる.
  43. コラッツ木データをゼルコバの木にて入力してエラーが発生する
  44. 系図画面上で選択判定が残ってしまっている.他のカードを選択しても選択が消えない.
  45. ページ設定を開こうとしたら,エラーが発生してパネルが開けない.プリンタの電源を入れてみたが効果なし.それどころか,印刷コマンドではエラーさえ表示しないで,無応答だ.印刷プレビューは開くことができる.
  46. 並び替えするとき,数字は文字列としてではなく,数として比較できるようにしたい…
  47. 先祖並び替えが動作しない.ボタンが効かない.また,ドラッグ移動もできない.↑キーでは移動できるが,適用で戻ってしまう.系統が異なるときは移動できないのだろうか?先祖リストには表示されているのだが…

コラッツ木項目:12件

  1. CSVをエクスポートしたときには,完了時にパネルを出してユーザに保存ファイル名を伝えた方がよい.ゼルコバの木と連動して系図画面を表示できるようにするとさらによいが…
  2. A面で検定中に仮想木モードに切り替えができてしまう ⇒ 対処した
  3. メール送信ボタンはつねにアクティブになっているが,検証テスト以外では送信される情報が少な過ぎて意味がない⇒意味がないということもないとは思われるが,とりあえず,使用しないことにする
  4. コラッツ正則木の有効ノード数を事前に計算し,残り時間を計算する
  5. Get the SequenceのCSV出力は倒立木として出力する
  6. 日数の表示をDD.HH:MM:SSではなく,DD,HH:MM:SSとする.ピリオドの代わりにカンマを使う書式はどこかで見たのだが,どこで見たのかは忘れた.⇒対処した.
  7. 検証テストで2^32を仕掛けると70日という予定工期が出る.2ヶ月と10日だ.当初より5倍遅くなっている
  8. 再帰関数内で使用している変数の大域化
  9. 巨大数を表示するテキストボックスにはスクロールバーを設置する
  10. 有効ノード数を事前に計算する公式を求める
  11. ゼルコバの木CSVを出力している論理で,最大カード数を超えた場合は打ち切る⇒正則コラッツ木生成ではCollatzTreeStructureで対処した 検証テストではMakeuAdjacencyListで対処した.ExportZelkovaCsvで上限を見るようにした
  12. 枝番号リストの区切り文字をカンマからピリオドに変える ⇒ IPv6ではコロンを区切り文字に使用している,電話番号はや地番はハイフォンで区切っている ⇒ ピリオドがよいのではないか?実際に出力して比較してみる