投稿者: babalabo

どうも作業の進捗がはかばかしくない．やることは決まっていて，それほど難しいことをしている訳ではないのだが，アニメを作るところで，というかそれ以前のところでもたついている．一つにはファイル管理，つまりライブラリアンの問題があるような気がする．Your Daily Epsilon of Math Calendar のフォルダで作業しているのだが，各種のファイルが溢れかえってカオス状態になっている．ファイルの命名規則lが定まっていないという問題もある．これまでのところは仕方ないとしても，何か整理された分類法を考える必要がある．

1. アニメGIFには必ずタイトルを付けること
2. GIFタイトルとファイル名は同名とすること
3. GIFアニメはPhotoにアップロードとしてアルバムとして管理
4. wxmファイルは常時バックアップが必要だが，そろそろ日付管理が必要
5. 日付管理するとなれば，ログを残さなければ意味をなさない
6. maximaで作業する専用のディレクトリを作った方がよいのでは？
7. 安定版には追番を振らないファイル名を付ける

maxima専用フォルダを作るというのはよいと思うが，どうやって管理するかが問題だ．できればテーマごとに分離した方がよいのだが，必ずしも確立したテーマが存在する訳ではない．しかし，ファイル名を決めるためにはまず，テーマを確定することが必要だ．その場限りのまちまちの名前を付けておくと，後日検索するのに手間取ることになる．ともかく，いま，YDEMCフォルダに入っているwxmとgifファイルを別フォルダに移してみよう．いま開いているwxmは３つある．閉じる前に名前をメモしておかないと忘れてしまう．

1. 包絡線図3　「Ellipse-Lines」 楕円→星芒線を出すアニメ　３ｘ３
2. 直線と楕円包絡線2　「Line and Ellipse Envelope」　楕円，直線→星芒線　２ｘ２
3. 楕円・直線コンパス　アルキメデスの楕円コンパスのアニメ　３ｘ３　最後にエラーが出る Improper argument: gr2d 描画は完了している

もし，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を見ると，径が１より大きい楕円では扁平率が変化していない．これはなぜだろう？少なくとも複数の扁平率の楕円が混合しないと星芒線は現れない．最近作ったアニメの概要を拾っておこう．

1. 楕円とコンパス線の包絡図　楕円とコンパス線の包絡図　短径0.5，長径1.5の楕円を描画するコンパス線のマルチアニメ　終りの方になると描画が極端に遅くなる　これは公開している網目タイツ包絡線とほぼ同一
2. アルキメデスの楕円２　最初のセクションは動かない→修正して動くようにした．Arichimedes2.gifを出力，短径≦１の範囲で扁平率を変えて楕円を描画．もう一つのセクションもほぼ同じ．こちらの方がアニメが滑らかに動く，この差はkのピッチの違いだけだ．
3. アルキメデス　Arichimedes.gifを出力　上と同じ　その他，いくつかバリエーションがある
4. 楕円コンパス(GIF)　半径0.5の円とコンパス軸部のアニメ　２番目のセクションはペン先まで含めたコンパスで楕円を描くアニメ　２ｘ２　GIFは生成していない
5. 楕円コンパス3　星芒線に含まれる楕円の静止画を出力
6. 楕円コンパス4　楕円コンパス(GIF)と同じ，２番目のセクションも同じだが，スピードが速い
7. 楕円コンパス６(GUI)　アルキメデス楕円コンパスの安定版　makelistの２重ループでArchimedesCompass.gifを出力
8. 楕円コンパス包絡図　楕円コンパス(GIF)と同じ　２番目も同じ
9. 楕円コンパス包絡図2　「Line Segment Envelope」　半径0.5の円とコンパス軸部のマルチアニメ　これで見ると，包絡線に寄与しているのはコンパス軸部だけであることが分かる　SⅡは壊れている
10. 楕円とコンパス線　SⅠは動作しない　SⅡはEllipse-Compass Lines.gifを出力，このアニメはアルキメデスの楕円２と同じ　
11. 楕円と楕円コンパス線の接点　「楕円とコンパス線の包絡図」短径0.5，長径1.5の楕円とそのコンパス線のマルチアニメ．楕円とコンパス線の包絡図と同じ　pitch 64で最後まで線が飛ばない　appendの中でmakelist
12. 直線と楕円包絡線　円の中にゆっくり楕円を描くアニメ　アルキメデスの楕円２と同じ
13. 直線と楕円包絡線　「Line Segment Envelope」　直線と楕円包絡線2と同じ　
14. 直線と楕円包絡線　「Line and Ellipse Envelope」　直線と楕円包絡線2と同じだが，中央に半径1の青い円を出している　終盤の描画は遅い
15. 包絡線図　短径2，長径3未満の青い楕円と直径1と0.5の円，青のコンパス線のアニメ　動点が２つある
16. 包絡線図2　「Ellipse-Lines」包絡線図と同じ　短径は2，長径は3未満　３ｘ３　動きが遅いので時間が掛かる
17. 包絡線図3　「Ellipse-Lines」マルチプロットアニメ　楕円のマルチアニメ　３ｘ３　最後にエラーが出る
18. 包絡線図4　「Ellipse-Lines」multiplotとmakegifの切り替えができるが仕上がっていない　何も表示しないでエラーで停止する

さて，始めよう．アルキメデスのコンパスが描く楕円の包絡線とコンパスの軸部の直線が描く包絡線が同じものであることを示すというのが課題だ．状況を具体的なアニメで示すことが一番分かり易いので，その方向に向かっている．⇒エラーが出ている．

▲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」というぶっきら棒なメッセージが出たあと，メインの編集画面がほとんど壊れてしまっている．

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が動作していない．これは解決する必要がある．