ゼルコバの木テント村
日によって来訪者カウントにかなりのムラがある．今日はまだ午前10時なのに，４６５もある．現在の延カウントは106662だ．ともかく，楕円コンパスの包絡線の宿題を片付けなくてはならない．「直線と楕円包絡線の２」というwxmがあるので，ここから始めよう．これはすでにマルチプロットになっているので，あとはGIFアニメに落とすだけだ．
と言っても，この作業がまだルーチン化していない．いまのところdrawwdで直接描画しているので，これを terminal::animated_gifに落とさなくてはならない．
数学物理etc談話室のディスカッションが活発になってきているので，これに時間を取られて他のことがほとんどできない状態になっている．テーマがどんどん広がってゆくので手が付けられない．いまも，①コンウェイの定理のところで，コンウェイの六角形でL=a+b+cになる条件を求めるという問題，②加納正司氏の提出した４桁数字根の問題，③界斜等円図から派生した楕円包絡線とコンパス線の関係など，課題が山積みになっている．④QNO.77(2023/03/18)の回答にも一部疑問が残っているので，どこかでクリアしておかなくてはならない．
④はWolfram alphaでも解けないので，かなり難しい問題だ．T氏の回答はおそらくどこかからコピペしてきたものと思われるので，氏に質問しても答えられないのではないかと思う（ので黙っている）．置換積分ないし部分積分をやっているはずだが，どの部分を置換しているのかが突き止められない．maximaでも解けなかった．
どうも作業の進捗がはかばかしくない．やることは決まっていて，それほど難しいことをしている訳ではないのだが，アニメを作るところで，というかそれ以前のところでもたついている．一つにはファイル管理，つまりライブラリアンの問題があるような気がする．Your Daily Epsilon of Math Calendar のフォルダで作業しているのだが，各種のファイルが溢れかえってカオス状態になっている．ファイルの命名規則lが定まっていないという問題もある．これまでのところは仕方ないとしても，何か整理された分類法を考える必要がある．
maxima専用フォルダを作るというのはよいと思うが，どうやって管理するかが問題だ．できればテーマごとに分離した方がよいのだが，必ずしも確立したテーマが存在する訳ではない．しかし，ファイル名を決めるためにはまず，テーマを確定することが必要だ．その場限りのまちまちの名前を付けておくと，後日検索するのに手間取ることになる．ともかく，いま，YDEMCフォルダに入っているwxmとgifファイルを別フォルダに移してみよう．いま開いているwxmは３つある．閉じる前に名前をメモしておかないと忘れてしまう．
もし，wxmのコーディングが「開発」の一端であるとすれば，作業環境もFireBirdに移すべきではないか？どっちみち，ゼルコバの木と同時平行作業はできないのだから，FireBirdで作業した方が効率がよい．そうすれば，Vultureの画面も外部とのコミュニケーション用に空けておくことができる．GIFを投稿するときには，FireBird→Vultureにコピー→投稿でよい．Vultureは256GBのSDDを持っているので，そこをベースとしておけば，バックアップの手間も省けるし，Cドライブ容量の節約にもなる．⇒とりあえず，SDDにmaximaというフォルダを設置した．
EPSILON 23年3月 からGIFファイル20本，wxmファイル54本をVultureのmaximaに移動した．しかし，maximaのような不安定なコードを開発環境で実行することにも不安はある．maximaの暴走は場合によっては外部アプリないしシステムにまで影響する可能性を排除できない．BlackBirdはいまのところ手ぶらだが，ここで作業するというのもかなり無理がある．いいアイディアだと思ったのだが… maximaを開発機で実行するのはやはり，問題が大き過ぎると考えざるを得ない．ネットアクセスの部分をBlackHawkに移管できないだろうか？できないことはないような気がするのだが… 現在一番安定が悪いのが，このマシンだ．
BlackBirdは久々に立ち上げたので，カスペルスキーの定義データベースの更新にかなり時間が掛かりそうだ．一応まだ動いていないので，外部アクセス用としてはしばらく使えるだろう．もし，うまくゆけば，毎朝のルーチンになっているYour Daily Epsilon of Math Calendarの投稿もこのマシンで実行されることになり，メリハリがしっかりしたものになる．⇒BlackHawkをSNSアクセス用に使うというのはよいが，遅いのが難点だ．Cドライブの空きは2GBあるから，まだなんとかなる範囲なのだが… Vultureではログ出力を確認するだけになるので，モニターはwxmだけで占有できる．上記リストの項目2は動いているので，アニメ化するだけだ．またおかしくなっている．何もエラーは出していないのに，画面がバタバタしている．
楕円包絡線の原理が少し分かりかけてきた．楕円族の中で星芒線に接しているのは一部の楕円だけであり，それ以外のものは交差しているか，ないし完全にその外部にある．その一方直線族はすべての直線が星芒線に接している．コンパス線はペン先の移動に応じて異なる径の楕円を描くので，複数の楕円が１本のコンパス線を共有しているが，ある径以上の楕円は星芒線の描画に貢献していない．Line and Ellipse Envelopeを見ると，径が１より大きい楕円では扁平率が変化していない．これはなぜだろう？少なくとも複数の扁平率の楕円が混合しないと星芒線は現れない．最近作ったアニメの概要を拾っておこう．
さて，始めよう．アルキメデスのコンパスが描く楕円の包絡線とコンパスの軸部の直線が描く包絡線が同じものであることを示すというのが課題だ．状況を具体的なアニメで示すことが一番分かり易いので，その方向に向かっている．⇒エラーが出ている．
▲WARNING：Couldn’t write to #<SB-SYS<FD-STREAM for “descriptor 744” {1003B33583}>:パイプを閉じています。
Trying new stream.WARNING:Couldn’t write to #<SB-SYS<FD-STREAM for “descriptor 724” {1004D235B3}>:パイプを閉じています。Trying new stream.
既存コードを流用しているだけなので，問題なく動くはずなのだが… else文を停めたら動き始めた．どうも，else文が実行されてしまっているようだ．構文的には間違っていないように見えるのだが…
この図で見ると楕円と楕円コンパス線はまったく接していないように燃える．楕円自体が星芒線の領域からはみ出している．楕円の描画が間違っているのだろうか？この楕円はparametric(d*cos(θ), (1-d)*sin(θ), θ, 0, 2*%pi)という式で描画している．長軸の半径を与えるdは定数で1.5だ．コンパスのペン先の同点を描画してみればすぐに分かる．「楕円コンパス5.wxm」がGIFなしの楕円コンパスだ．
ここでは，ｋを-1~2の間でコンパスの状態を描画している．kというのは，ペン先の位置を示すものと考えられる．ブルーの点がペン先で楕円はparametric(k*cos(θ), (1-k)*sin(θ), θ, 0, 2*%pi)で描画している．このkは上記のdに相当するから，一致している．どうもわからなくなってきた．下のアニメで見ると楕円とコンパス線は完全に交差していて，接するようなところは見られない．
これはどういうことか？おそらく，楕円の包絡線と直線の包絡線は形状的には類似しているが，スケールがまったく異なるのだろう．楕円の包絡線のアニメはまだ作っていなかったのではないだろうか？それをやって見る必要がある．楕円を描いているアニメは現在のところ２つある．一つはArchimedesCompass.gifで，もう一つはArchimes.gifだ．２つとも昨日のログに掲載している．前者は長径が0.5から2までをカバーしているが，後者は長径が0.5~1の場合しかカバーしていない．包絡線を見るにはある程度の本数を引かないと見えないので，前者からスタートするしかないのではないか？コンパスの軸を直線と交換し，重ね書きできるようにすればある程度見えるようになるのでなないだろうか？
やってみよう．
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」というぶっきら棒なメッセージが出たあと，メインの編集画面がほとんど壊れてしまっている．
とりあえず，ここまでできた．
しばらくテント村にご無沙汰しているが，今日の来訪者カウントは２３時現在で，７７６を記録している．こうなると，近い将来にも来訪者/日が1000を超える可能性が出てきた．
カンブリア爆発？もしかするとわたしの誕生日に関係していたのかも？FBでは８０個を超えるお祝いをもらっている．それにしても，更新が止まっているテント村のカウントが上がっているというのはナゾだ．
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を実行する直前に読み直すことにした．これで上記の一覧表が逆順になったりする現象は解消した．
これまではカード番号と呼んできたものが一覧画面の行番号になるとしたら，カード画面に表示される番号はどうなるのだろう？⇒基準番号がユーザから見えないようにするというのは悪いアイディアではないが，カード番号との整合という問題もあり，直ちに実装は難しいような気がする．この点に関しては現行のままとして，しばらく様子を見ることにする．⇒この問題は前々からの懸案事項だったが，ようやく一件落着としてよいと思う．ここで一度バックアップを取っておこう．
世代番号の問題はすでに解決済み．NAMEBOX::getGenerationGapという再帰関数を新設し，TRIBELIST::GetTheEldest，getGenerationGapでは動的に系列ポテンシャルを計算するようになっている．
▲垂直系線の状態がおかしい．YGroup.zelで文字数ないしフォントサイズを変更したら縦系線が伸びてしまうようになった．⇒文字数ではなく，フォントサイズの影響のようだ．文字数など別のパラメータを調整すると正常描画に戻る．⇒フォントサイズを小さい方に変更して，MARGBOX::Drawで(rect.Height() > metrix->geneHeight)のエラーになった．⇒人名枠設定パラメータを操作すれば正しい状態になる．
どうもフローがおかしくなっているようだ．UpdateDiagramもTopologicalSortも掛かってこない．フォントサイズの変更ではトポロジーは変化しないので，UpdateDiagramが
物理世代番号の計算を最終的にクリアしてしまおう．系列ポテンシャルを決定する途中計算で物理世代番号を参照しているというのがそもそもの間違いなのではないか？これを回避するためには，やはり動的に系列ポテンシャルを決定する仕組みが必要なのではないかと思う．系列木は木構造になっていて，その頂点に始系列があるという構成になっているが，最古世代系列は必ずしも始系列とは限らないため多少ややこしい話になっている．この辺りを整理する必要がある．
▲子ども一人の結婚枠では結婚枠背景色が描画されていない．→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が動作していない．これは解決する必要がある．