ゼルコバの木テント村

FBグループの「数学物理etc（談話室）」で和算に関わる議論が続いている．その一環として「宿題Ⅲ楕円コンパス直線の1次方程式をθで偏微分することでアステロイド曲線の式が得られることを示せ．もし，そのような式を得ることができないとすれば，その理由を述べよ．」と言う課題を提示した．自己回答しなくてはならないが，少し下調べすることがある．①楕円と楕円コンパス線が接している，つまり，楕円コンパス線が楕円の接線になっていることを確認する．②その接点が包絡線上の点であること確認するという２点だ．

FishnetTightsEnvelope.wxmという網目タイツ包絡線図を出しているmaximaのソースコードがあるので，ここから始めることにする．楕円を出しているコードも必要だ．どうもmaximaのファイルを後から探すのは結構大変な気がする．一々開いて走らせなくてはならないし，走らせても動かないものもあったり…結局，FBの投稿に戻ってそこで探すようになったりする．こちらの方が図が見えているので探し易い．いま探しているのは「宿題Ⅱ：アルキメデスの楕円コンパスの拡張」というタイトルで掲載しているものだ．

Envelope5.gifというファイルが残っていないということは，作れなかったということだろうか？おそらく，もう少し精度を落として別のファイルで保存したのだろう．pitch=64で成功したことがあるような気がするのだが…pitch=32では保存できた．この位で満足するしかないのではないだろうか？楕円コンパスの包絡線に関する研究の端緒となった画像（楕円コンパス.png）を掲載しておこう．このファイルは拡張子がPNGになっているが，どういう経緯でそういうことになったのだろう？これを出力したwxmは残っているだろうか？これは，多分multiplot_modeをオンにして描画していると思う．

これと似た図にLineEnvelopeというのがある．下図はいま，LineSegment.wxmの出力を保存したものだ．上の曲線群は楕円で，下の曲線群は直線となっているところが異なる．これらの2つのベースはいずれも楕円コンパスだが，楕円曲線の包絡線と直線群の包絡線が同じ形状（多分一致しているはずだ）をしているという根拠を突き止めたい．

この図の線分を延長したものが網目タイツのラジアルな直線なので，この2つで比較してもよいのだが，最終的には動かしてみたいので，元になるアニメが出力できるwmxを探しているところだ．ただし，楕円曲線に関しては多分フルスペックのアニメは作っていないと思う．このwxmでもアニメを作っている形跡はあるが，出力まで行ったかどうかはわからない．楕円を出しているアニメは多分これ↓だけだろう．

このファイル（Archimedes.gif）は多分，アルキメデスの楕円.wxmかその前後の版で作っているはずだ．

お酒が切れてしまったので，業スーに買い出しにゆかなくてはならないのだが，すでに３時．欠品を点検してみたところ，まだしばらくは持ちそうなので，Wellciaでお酒とタバコだけ補充するという方針に切り替えた．4L25度の焼酎がWellciaでは業スーより100~200円くらい高くなるが，全体の出費は押さえられるのでこの方がベターだ．Wellciaではお茶を補給できないのだが難点だが（粉茶はないし普通のお茶は高い），この前（敬老の日）に市から支給された地域通貨（ネギー）で市内で購入した玉露の粉茶というのがまだほとんど手付かずで残っていた．

maximaのコードを書くのも一種のプログラミングなので，やはり，ログを付けながらでないと捗らない．二重ループを構成する必要があるが，まず，内側のシャフトがスライドしながら回転するところを作ってみよう．wikiにあるアルキメデスの楕円コンパスの模倣だ．⇒maximaの具合がかなり悪い．保存された「アルキメデスの楕円.wxm」を開いたところ，ほとんど壊れていて白紙状態になっている．「楕円コンパス.wxmx」は問題なく開けた．ここから始めることにしよう．

このサンプルでは，

parametric(k*cos(θ), (1-k)*sin(θ), θ, 0, 2*%pi)]

で楕円を描いている．とりあえず，この座標をX軸とY軸に射影して２点を結べば楕円コンパルのロッド部分になるはずだ．このサンプルはdraw2dで描画しているが，引数リストの中でFORループを使えるだろうか？というか，多分drawに書き換えないと動かないと思う．アニメのコードから始めた方がよさそうだ．⇒drawではgr2dで描画している．makelistはそれ自体ループになっているが，その中でFORループを使うことはできるのではないか？⇒makelistのループはkというパラメータで楕円の半径を制御している．

このkという値は，シャフト上の点の位置を示すものだが，それを延長したものが本来のアルキメデスコンパスだ．シャフト両端の座標は半径1の円周上の点をXY軸に移したものだから，kの値に関わりなく描画できなくてはならない．つまり，makelistの内側にループを作る必要がある．とりあえず，makelistをコメントアウトして，画面出力できるように改造しておこう．⇒どうも，maximaは思ったより難物だ．カンマのある/なしなどで動作しないのはよいとしても，安定がすこぶる悪い．「refusing」というぶっきら棒なメッセージが出たあと，メインの編集画面がほとんど壊れてしまっている．

MakingLookUpの呼び出し：現行ではNameNarabekaeではMLUは実行されていない．新規ファイルの場合はCOUPLING::OpenFamilyBaseで実行している．通常は，InitLinkTableで一度だけ実行される．CommandEndでTopologicalSortの直前に実行されるMLUは暫定的に停めてある．CommandEndでTOPOLOGY::RebuildCardListを実行している．この中でNameSortが実行されlookupが逆順になっている．lookupを並び替えるのがNameSortの役割であり，それ以外の仕事はない．

NameSortでテーブルに穴が開いている．⇒論理修正した．⇒これで一応穴を塞ぐことはできたが，RebuildCardListでテーブル並び替えを実施する必要はあるだろうか？RebuildCardListでは各種のリストを再構築している．lookupは一覧表の順位に関係するので，つねに同期を取っておくというのが正しいのではないだろうか？であるとすれば，初期オープンの場合もそうする必要があるような気がする．

NameNarabekaeはそれ自身一つのコマンドだが，その中で，BuildNumlistとRebuildCardListを実行している．RebuildCardListの引数でコマンドを渡しているので，NameSortが重複実行されることはないようだが…

▲@23を削除した後，Undoすると一覧表が逆順になる．⇒解決

▲どこかでNAMESORTを初期化している．COUPLING：CloseFamilyBase→ Cleanですべての下位クラスがリセットされるような動作になっている．TREEVIEWがやっているようにdoCleanを上書きして，必要なパラメータを保全するか，ないし，レジストリに退避して再読み込みする必要がある．NAMESORTのパラメータはレジストリで保全しているので，InitLinkTableでMakingLookUpの実行後，SortNameを実行する直前に読み直すことにした．これで上記の一覧表が逆順になったりする現象は解消した．

1. MakingLookUpはInitLinkTableでのみ実行される
2. InitLinkTableではMakingLookUpを実行し，レジストリからNAMESORTのパラメータを取り出した後，NameSortを実行する
3. テーブルソート時のリナンバーは実施しない（基準番号はパーマネント変数として原則として変更されないものとする）
4. 一覧画面では基準番号を表出しない　その代わり形式的な行番号を表示する（レコード中には保持されている）　⇒　現行のまま表示
5. テーブル並び替えはlookupの並び替えとして実装される　lookupの並び替え時には前詰めが実行される

これまではカード番号と呼んできたものが一覧画面の行番号になるとしたら，カード画面に表示される番号はどうなるのだろう？⇒基準番号がユーザから見えないようにするというのは悪いアイディアではないが，カード番号との整合という問題もあり，直ちに実装は難しいような気がする．この点に関しては現行のままとして，しばらく様子を見ることにする．⇒この問題は前々からの懸案事項だったが，ようやく一件落着としてよいと思う．ここで一度バックアップを取っておこう．

世代番号の問題はすでに解決済み．NAMEBOX::getGenerationGapという再帰関数を新設し，TRIBELIST::GetTheEldest，getGenerationGapでは動的に系列ポテンシャルを計算するようになっている．

▲垂直系線の状態がおかしい．YGroup.zelで文字数ないしフォントサイズを変更したら縦系線が伸びてしまうようになった．⇒文字数ではなく，フォントサイズの影響のようだ．文字数など別のパラメータを調整すると正常描画に戻る．⇒フォントサイズを小さい方に変更して，MARGBOX::Drawで(rect.Height() > metrix->geneHeight)のエラーになった．⇒人名枠設定パラメータを操作すれば正しい状態になる．

どうもフローがおかしくなっているようだ．UpdateDiagramもTopologicalSortも掛かってこない．フォントサイズの変更ではトポロジーは変化しないので，UpdateDiagramが

物理世代番号の計算を最終的にクリアしてしまおう．系列ポテンシャルを決定する途中計算で物理世代番号を参照しているというのがそもそもの間違いなのではないか？これを回避するためには，やはり動的に系列ポテンシャルを決定する仕組みが必要なのではないかと思う．系列木は木構造になっていて，その頂点に始系列があるという構成になっているが，最古世代系列は必ずしも始系列とは限らないため多少ややこしい話になっている．この辺りを整理する必要がある．

1. getpotential　potentialを返す
2. GetPotential　系列枠のポテンシャル値（設定すべき値）を取得
3. getPotential　系統（始系列）のポテンシャル値を取得
4. getMax　系列最大物理世代番号取得
5. getMin　系列最小物理世代番号取得
6. getGeneration　系列枠の（最小）常用世代番号
7. DEV2LOG　物理世代番号→論理世代番号
8. LOG2DEV　論理世代番号→物理世代番号
9. DEV2GEN　物理世代番号→常用世代番号
10. GEN2DEV　常用世代番号→物理世代番号
11. MakeTribesPotential　系列を系統に分解し系統ポテンシャル値を設定→使われていない
12. callSetpotential　系列枠のポテンシャル値を設定
13. Setpotential　系列枠のポテンシャル値を設定
14. setPotential　系統ポテンシャルを設定する
15. TRIBELIST::setStartPotential　
16. TRIBELIST::SetAbsolutePotential　絶対世代番号系と物理世代番号系を一致させる

▲子ども一人の結婚枠では結婚枠背景色が描画されていない．→TYW婚は結婚リンクを持たないので，MARGBOX：Drawでは描画されない．

一番の問題はTRIBELIST::GetTheEldestの中でgetFloorを使っている点ではないだろうか？最古世代の検出に物理世代番号を使わない方法を編み出す必要がある．⇒実装した．

▲TRIBELIST::CheckAbsoluteGeneは実行されていない．TRIBEBOX：CheckAbsoluteGeneではsetnodegeneでCARDLINKの絶対世代番号を設定している．つまり，絶対世代番号は確立されていない．⇒絶対世代番号は多重カードクラスタ検定の中で計算されている．この計算には抽象グラフ検証系が必要であるため，暫定的に停止してある．

▲最小反例307.zelで@23のカードを削除してTRIBEBOX::MakeUpTreeのエラーが発生する．同じカードにMakeUpが重複して掛かっている．その後， (nbox->hideflag == HIDE_UNKNOWN)というカードが検出されている．これは，MakeUp重複ノードと同一カードだ．該当ノードは#4213@31で@47の子ども．カードテーブル上では先祖ノードの@35よりも前にある．どうも，ClearTableでリセットされなかったのではないか？という気がする．子どもを３人持っているが，親は@47だけの普通のカードだ．⇒確かに初期化がパスされている．

CARDLINKは#1522だ．このリンク自体が無視されている．ClearTableに入る前にMakingLookupが実行されていない．MakingLookupはCommandEndで実行しているのではなかったろうか？CommandEndでTopologicalSortの直前にMakingLookupを実行するようにして動作するようになったが，カード削除ではlookupでアクセスできなくなるというのはやや不審だ．⇒カードテーブル上の位置は不変だが，lookup->countが減っているのではないだろうか？

初期状態ではlookup[1]の位置に入っている．更新するとlookup[0]になる．つまり，削除されたカードはlookup[0]にあったものだ．どうも，lookupの操作に何かバグがあるのではないだろうか？⇒かなりおかしい．逆順になっている．どこかで並び替えしているのだろうか？

どうも，世代番号の問題をクリアしておかないと先に進めないという状況になってきたので，じっくり，この問題に取り組むことにする．⇒どうも，いま出ている不良ノード対は世代番号とは無関係のようだ．こちらを先に見ておこう．⇒いや，もしかすると関係あるかもしれないノード対は基本世代枠リストで管理するため，物理世代番号が確定していることが必要だ．⇒いや，そのチェックはやっているようだが…

端点一致でsamepointゼロや左端点共有で種別不一致はそれほど致命的な不良という訳ではないが，回復できないという点に問題があるように思われる．これはやはり，後回しの課題なのではないか？⇒RepairCommonEndPointないし，RepairPairBoxが動作していない．これは解決する必要がある．

▲YGroup32.zelを開こうとしたら，MakePairListCleanで無限ループしてしまった．最初に以下のエラーが発生している．SUPPORTSIMPLEGRAPHをオンにしたためだろうか？

確かにそのようだ．オフにしたら描画できた．親子連結線の不良に関係があるかどうか見るためにオンにしたのだが，無関係のようだ．このオプションに関しては後日調べることにして戻しておこう．⇒YGroup.zelで不用な親子連結線が表示されている．これは少し気になるので，見ておきたい．画面右下の連結線はどこにもつながっていない．

この線はYGroupから出ているので，YGroupの子どもと考えられるが，hiddenとcheckcidの間には，printnamaeしかない．printnamaeは一世代下の箱に入っている．YGroupの子どもは13人だ．結婚点の位置もおかしい．⇒縦系図/横系図は，DrawObject.cppのbool reverseAxisで切り替えできる．結婚点などはその切替を行っていないのではないか？本来論理座標は一つであり，描画する側で対処する必要がある．reverseAxisはDrawObject.cppの中でしか参照されていない．

座標軸の変換関数として，reversePoint, reverseRectがある．_CDCというCDCの派生クラスにはこれらを使った描画関数のセットがある．_CDCを経由して描画していれば，間違いないはずだ．他の描画関数はほぼ対応済みと見られるが，Polygonは残ったままとなっていたものと思われる．⇒対処した．これで座標軸の転換は完結したものと見られる．

上記の不明な連結線の出所がわかった．

NAMEBOX::DrawLongTailでCheckYrouteのLDR垂線として描画している．しかし，CheckYrouteのLDRはYGroupの子どもとしてすでに描画されており，CheckYroute自身は実体を持っている．つまり，余分なノード対を持っているように思われる．何か操作しているときに誤って残してしまったのではないだろうか？このノード対は，CheckYroute(2)→ (1)を連結するものだ．本来の(1)→(2)はノーマルに描画されている．このようなノード対が発生していること自体問題だ．段数が2となっている．どうも，LongTailを作り損なっているのではないか？

NAMEBOX::DumpLongTail NAMEBOX::DrawLongTail > #1157 CheckYroute(2)
   1  dum#=1 #1157 CheckYroute(2)
   1  dum#=2 #1169 YRight(2)
   2  dum#=2 #1905 YRight(3)
NAMEBOX::DumpDummyChain NAMEBOX::DrawLongTail
   1  thread        #1157 CheckYroute(2) #1169 YRight(2)
   2  #1913 [結婚枠]：[2] #1905 YRight(3)

長いしっぽの構成を忘れてしまった．確か複合的なものであったような気はするが…YRightはYgroupの子どもであり，CheckYrouteとはつながらないような気がするのだが…⇒なぜ，複合構造になるかというと，LDRは複数のLDRが束ねられる場合があるからだ．確かにYRightはYGroupの子ノードであり，CheckYrouteと共通の親を持っているから，LDR束だ．しかし，YRightは親を２人持っていて，それがCheckYrouteだ．どうもかなりややこしい話になってきた．

出力ではYRightはYgroupの子ども枠の中にLDRはとして入っているように見える．結局，この線分は下図のように引かれなくてはならなかったものと思われる．

従って，描画していることではなく，描画している位置が間違っている，つまり，一世代下がり過ぎということになるのだろう．⇒できた！

かなりノーマルなモードに近づいた．バックアップを取っておこう．⇒TYW2ExtractBoxでは問題なく動作することが確認できたが，RestoreYoungWifeとどこが違うのかをチェックしておく必要がある．このために，関数の参照関係を洗い出そうとしたのだが，関数木の原本が見つからなくなってしまった．いや，その前にYGroup32.zelで出ていた部分図の障害を見ておこう．というか，この図面は相当乱れている．

いや，今度はノーマルに開けた．インストール版でテストしていた．修正の入った版では解決している．

▲YGroup32.zelで「人名枠線を表示する」をオンにしようとして，エラーになった．ResetTooYoungWifeだ．

(topology->TooYoungList->len() != ztywcount) が起きている．

ztywcountは-1で，TooYoungListのデータカウントはゼロだ．どこかで引き過ぎているのだろう．ztywcountはZTYWのカウントでTYWのカウントではない．この辺りで食い違いが生じているのでは？明らかに行き違いがある．TooYoungListに格納されているのはZTYWだけではない．それにしてもおかしいことはおかしいのだが…ztywcountをtywcountに統合するのではなく，別途tywcountをカウントすべきだろう．同様に，SymmetryCountも別途カウントすべきだ．つまり，システムの内部パラメータはつねに，２つの方法でカウントされなくてはならない．言い換えると複式でカウントされなくてはならないというのが原則だ．この考え方は徹底されなくてはならない．

1. 系列枠は個別にTooYoungCount, ZTYWCount, SymmetryCountを管理している　これに対応して大域的にtywcount, ztywcount, symcountを管理するものとする
2. これらのカウントはそれぞれの属性のセット・リセットを行うsetghostbits, resetghostbitsで同期を取るものとする
3. TouYoungList, SymmetryListへの追加，削除のタイミングで上記カウンタとの一致を確認する
4. 系列枠のカウンタを更新した場合にもそれらの合計と一致していることを確認する
5. これらの属性はすべて結婚枠の属性であるとする
6. TOPOLOGY::CountTooYoungWifeという集計関数もある

TopologicalSortの冒頭でTOPOLOGY::ResetExperimentが実行されている．このとき，3つのカウンタがリセットされているが，オブジェクトは温存されているためカウント不一致が発生する．⇒SymmetryList，TooYoungListの廃棄とtywcount，ztywcount，symcountのリセットはClearTableより後に実行することにした．ResetExperimentもそのタイミングでよいのではないだろうか？ただし，genelist, tribeListの初期化はClearTableに先行させる必要がある．

YGroup32.zelでは多重カードが３件出ている．これは削減できないのだろうか？あるいは，どこかで機能劣化してしまった可能性もある．

一番左のYGroup(♀)は祖父のYGroup(♂)の配偶者なので，多重となるのは避けられない．真ん中のCutBranch(♂)は娘のCutBranch(♀)の配偶者なのでやはり不可避だ．CheckYroute(♂)は親を3組持っているが，そのうちの一人は兄弟のCutBranch(♂)なのでやはり，避けられないということのようだ．これは，再帰ないし再入呼び出しを表現するための苦肉の策として取られた手段ではなかったろうか？

ゼルコバの木では血統循環を禁止しているため，婚姻関係を使って擬似的な血統循環を成立させていたのだと思う．⇒関数木では再帰的な呼び出しを，同名の子ノードを作りそれを親ノード（呼び出し先）と配偶させることで擬似的に表現している．再帰呼び出しは必ず血統循環を発生してしまうので，ゼルコバの木では禁止されているが，多重カードになることを許容するのなら，血統循環を許すという設計も（将来的には）考えられなくもない…

関数とその所属するクラスとの関係もある種の木を構成すると考えられるが，関数木ではクラスを部分図で代替している．ゼルコバの木では最大32個までの部分図しか登録できないが，ゼルコバの木の実装ではおおむねそのくらいの数のクラスしか扱わないので，ほぼカバーできるのではないかと思う．⇒部分図自体を一つのオブジェクトとしてその包含関係を明示できれば，部分図木のようなものを構成することも可能となるが，現在の実装では部分図は単純な集合であり，必ずしも順序関係を定義することはできないので，多分実装は難しいと思う．（関係グラフのようなものは構成できるかもしれないが…）

TYWに関係する処理の見直しを進めているところ．基本的には，「moveがゼロのときはZTYWとしない」という方針だが，障害が発生する原因は突き止めておかなくてはならない．また，衝突回数上限を決めるMAXCRUSHCOUNTと処理終了するまでの時間が必ずしも比例するものではないという点に関しても調べる必要がある．現行では，ZTYWに制限を掛けていないため，衝突回数オーバーですべてのTYW婚を解除するAbortAllFloatingBoxが発動しているが，にも関わらず障害が止まらないという問題がある．

このとき，①Yリスト上位ノード不在，②TYW婚の吸収合併成功，③NAMEBOX：CheckUnerasable 結婚枠不在のような事象が大量発生している．従来論理ではAbortAllFloatingBox→ StopTooYoungWife→ TYW2ExtractBoxでTYW→抽出枠転換していたが，現行では暫定的にRestoreYoungWifeを使っている．この理由は，TYW2ExtractBoxでは抽出枠が残存してしまうが，RestoreYoungWifeなら完全に元の状態に復元できると考えたためであるが，どうもどこかに不備があるような感じだ．⇒TYW2ExtractBoxを復活させれば正常動作可能だ．

TYW2ExtractBoxではZTYWの場合は，RestoreErasedYoungWifeが実行される．RestoreErasedYoungWifeではRestoreErasedYoungWifeで消去された仮ノードを取り出して，RetrieveGhostでそれを復活させている．従って，この処理にはぬかりはないと言える．逆にRestoreYoungWifeではそれが不十分な動作になっているように思われる．この辺りは，一度整理してドキュメント化が必要だ．呼び出し関係だけでもチェックしたいのだが，その手始めとして「関数木.zel」を復活させるというのは悪いアイディアではない．どこかにあるはずだ．

デスクトップ 2020-02-11\テストサンプル\関数木グラフというフォルダがあった．ただ，一部関数のコレクションばかりで，全体木のようなものが見当たらない．フォルダ名は2020となっているが，中身は2017～18に作られているようだ．どこかにもっと大きなサンプルがあるはずなのだが…別の場所にもいくつか関数木という名前のファイルはあるが，NONファイルに変換されてしまっていて，名前が短縮されているものしか見当たらない．2018-02-04の記事には「血統循環関係の関数参照木を作って不用関数を整理」とある．

▲デスクトップ 2020-02-11\テストサンプル\関数木グラフ\AccidentalCollisin.zelを開こうとしてエラーになった．

エラーを無視して描画は可能．⇒開発環境ではエラーにはならない．対処済みと思われる．

もっと大きな網羅的な関数木を作っていた記憶があるのだが，残っているのはどれも，特定の処理に関するコレクションばかりだ．もっとも大きなYGroup32.zelでも58点しか入っていない．

▲ YGroup32.zelで部分図 Bobject を選択して，(topology->TooYoungList->len() != ztywcount)で停止．図面もおかしい．カード数6と表示されているが，実際には7点あり，親子連結線もおかしい．⇒いや，カード数は６で正しい．多重カードが出ている．多重カードの解消機能が十分動作していないように見える．

ここでリリース版を起こしておこう．⇒インストールしたが，動作がおかしい．古い版が残ってしまっている．アンインストールして再インストールで正常動作するようになった．