KuboLog 2001-06-20

2001 年 06 月 20 日 (水)

0705 起床．目覚し鳴らなかった．よく見ると午後 6 時に設定されてる．うう．

朝飯・弁当の準備．朝飯．コーヒー．時間ないのに，アカマツ関係の資料を整理してしまう．大半が廃棄可能と判明．残ったのは重さ 1Kg ほど．シャワー．

0750 自宅発．雨．特急に乗って 0801 京急平和島発．普通に乗り換えて 0825 京急上大岡発． 0845 研究所着．

昨日から「ニセ」アカマツのとりまとめにおける難点を検討してきた．モデリングに関していうと，以下の三点が「簡単な説明をでっちあげるのが困難」なところだ．

茎成長パラメーターの決め方
茎の親子関係の決め方
茎の集まりである枝の死に方

これら相互に連関のある「呪縛」とでもいうべき難点を事前に回避しておきたい．もともとの redpine ディレクトリーから分派した redpine2 でこのあたりを簡単化することによって，とりまとめを容易にする．

これらのサブモデルが複雑なのは今年 2 月にモデリングしてたときの発想の制約によるものである．当時は茎の親子関係をきちんと定義できるようにしておかないとアカマツシミュレイターなんぞとうてい作れまい，と考えていた．そこで，あえて無理な仮定をいろいろ導入したという経緯があった (そして簡単な説明ができない …… 正当化に多言を費さなければならなくなった)．

ところが，いまとなってはそのあたりが多少いいかげんでも結果はそんなに変わらんだろうという見通しがあり，ついでに説明の力点が結果よりも方法に移ったので多少ヘンな結果がでても以前ほど深刻ではない．さらに，茎動態のモデルと「見てくれ」モデルがうまい具合に分離できそうなので，動態モデルのほうはさらに簡単化を押し進めても問題あるまい．そういう状況判断である．

自動処理の流れの中では 1 → 2 → 3 という順に計算されるのだけど，「呪縛」を簡単化という手法によってほどいていくには 3 → 2 → 1 という順番で片づけていく．なぜならば，上流の処理が下流に影響与えるので，そっちがわから変えてしまうと何もかも同時に修整しないといけない．しかし下流から着手すれば，ひとつずつ順番に直していくことができる．ということで，まずは死亡サブモデルのりすとらである．

今朝の京急車中で「枝」の死亡について考えた． (あるいはそのモジュールである「茎」) にクラスあるいはランクという概念を入れて，それに応じて死亡させてみよう，と決める．

「ニセ」アカマツでは枝を死亡させずに放置しておくと，資源生産部分に比べて資源消費部分がどんどん累積してくるので，樹木個体としては速やかに自滅してしまう．

そこで，邪魔な部品を切り捨てていくことで，延命をはかるわけだが …… たとえば， Pipe 樹木なんかでは，枝先ごとに開空度らしき指標を計算，暗い場所で「稼ぎの悪い」枝が切り捨てられていったりしたわけだ．

ところが「ニセ」アカマツにおいては，そういう現象に対応するデータがない．そもそも枝や茎が死ぬ，というデータない．しかしこういう部品を死亡させないとすぐに個体というシステムは破綻する．そこで，何かウソをついて死亡モデルをでっちあげねばならない (あるいは死亡モデルなんてそもそもいらない，というワク組を作るのもテではあるが，今回は思いつかなかった)．

で，この死亡モデルの候補として，「茎・枝の位置によって死亡」「固定した生産力の低い順に死亡」「明るさで生産力が決ってその低い順に死亡」などなど，加えてこれらの複合ワザが考えられる．

植物を扱ってるんだから，とうぜん光→光合成 (生産) → …… とゆー経路をとりたいところだけど，今回これをやると，光に対する反応と生産と死亡において 3 回でっちあげをやらねばならない．そこでこれまでの「ニセ」アカマツにおいては， (明るさなどは考えずに) 茎のひとつひとつで異なるある固定した生産力を想定し，それに応じて死ぬ「枝」が決まる，というふうにしてウソをつく回数を一回減じていたのである．

それで動かした結果の一例を以前の報告から引っぱってくると，

樹木個体としてはこういう死に方になり …… 専門家たちに言わせると，これはいかにも いんちきくさい ものだそーだ (くそう)．ついでながら，これは当方の都合にすぎないんだが，このモデルでは「どこからどこまでが『切り捨てられるべき枝』なのか?」を簡潔に定義するのが困難なのである．

そこで今回は光計算ナシで下から枯らす方便として，枝にランクというか，あるいは齢 (age) でいいと思うんだけど，下の方にある枝 (つまり古くからある枝) からばさばさ切り捨てていくようにしよう，という方針転換を考えている．

このモデルにおいてはそういう古い枝ほど資源を多量に消費しているので，以前に比べて切り捨てによる延命効果が向上しそうだ．

…… と考えを整理していたら，時刻はすでに 1115．やれやれ，さっさと取り組んでみますか．

自分の書いた Perl コードを解読していくと …… お，すでに当時から改造の予感あったのか，


			stem_sort

という関数が分離してあって，これで指定する


			$sort_key

を変えることで，資源配分の順番を変更できるように作ってあるな．よしよし．

いまは


			$sort_key

が

"a"

と指定されている．これは生産力を表すパラメーターだ．

それじゃあ，全ての stem に


			"rank_class"

という変数を持たせて，それにしたがって資源配分するようにしようか．いやいや，それではなく


			"rank_number"

という整数な変数も作って，そっちで整列させるか．

変数


			"rank_class"

は


			MAIN

と

SUB

の二つの値を取るとする．


			MAIN

からは


			MAIN

と

SUB

の両方の stem が作られるけど，

SUB

からは

SUB

しか作られない，と．

stem のうち


			MAIN

の


			"rank_number"

は毎年上昇するんだけど，

SUB

のそれは途中で分岐しても変わらず


			MAIN

あるいは

SUB

である親の数字をそのまま引き継ぐだけ，としてみるかな．図にするとこういうかんぢ．

[stem の MAIN-SUB]
つまりこういう関係．数字が "rank_number" を表す． MAIN の "rank_number" は毎年大きくなるけど， SUB は変わらず，親から数字をひきつぐだけ (途中で分岐しても)．これが大きいものに優先的に資源を分配する．逆に "rank_number" が 1 → 2 → 3 → ... の順で切り捨てられてく (MAIN が死んだら個体としては死亡)．

で，ややこしいことは一切やめて，たとえば


			"rank_number"

が 1 であるものが切り捨てられる，と決まれば，委細かまわず 1 の stem は全滅，としてみるか．とりあえず．それが一番簡単そうだ …… いや，あの，手抜きができるという意味ではなく，他の人に説明が簡単，ということで ……

一休みして弁当食うか．

昼飯食ってからコード見直してると …… おお，なんとすでに stem クラスには


			"type"

という名前で


			main-sub

を決めるようになってるじゃないか．すごいすごい．しかし当時はこれで何をやろうとしてたのか …… なーんだ，これは各 stem で子供を生成するときに中心的でまっすぐ伸長する


			main

と放射状にひろがる

sub

にわけているだけか …… この


			main-sub

はいま考えてる rank とは関係ないな．

…… 90 分ほど現実逃避にひたってしまった． global という GNU なツールで手元の C++ コードを HTML に変換して遊んでいたのである．うーん，これは便利というかよけーな行が追加されて読みにくくなったというか．

ためしに Pasoh シミュレイター (2001 年 6 月版) を Pasoh ペイジに置いてみました．いまのところ本体だけ．小川シミュレイターから余計なコードをひきずってるので (phonix モードとか) ちょっと意味不明かも．ホントは，

/* [<][>]^][v] [top][bottom] [index][help] */

というリンク行が関数ごとに付くんですが，見づらいような気がしたので勝手に


			grep -v

してしまいました．しかし，そうすると index ペイジまで戻るのがたいへんかな．

(更新情報) Pasoh シミュレイターコードを HTML 化してみました．見てもあまり楽しくないかも …… (2001.06.20)

…… えーい，いつまでも遊んでるわけにもいかん．そもそも「ニセ」アカマツ構成する Perl モジュールの中から grep で関数探しをするのに疲れたからである． Ctags 3.4 では Perl の関数の tags ファイル作ってくれないんだよねえ …… おお， ctags-5.0.1 が出てるのか． Perl もサポート． RPM もあることだしインストールしてみますか．

さて

ctags *.pm *.pl

で tags ファイルを生成 (tags ファイルとはこういうものです)． vi (vim5.8) で何かひとつ Perl モジュールのファイルを開く．メンバー関数 (らしきもの) にカーソルあわせて


			Ctrl+]

…… わーい．別のファイルにあるその関数の定義にジャンプした．


			Ctrl+t

で元に戻ります．

おっと，ともかくこの機能を活用して，


			"rank_class"

とか


			"rank_number"

というようなメンバー変数 (だろうか?) を追加しなくては．

1650 「今日は定時退社の日です」とマヌケなアナウンス．こう言われると粘りたくなる．しかし，やっぱりいつもどーりさっさと帰るんだろうな．

う，コード改造はまだ進んでないのに 1755 研究所発．雨はあがっている．普通に乗って 1809 京急杉田発．快特に乗り換えて 1819 京急上大岡発．普通に乗り換えて 1838 京急川崎発． 1910 帰宅．

あ，なんかばてた．こういうときは粛正ごっこだ …… と自分の web site のファイルをばさばさと消してみた．なんと合計 62 MB もあったんだけど，ひとまず 49 MB まで減じた．といってもどこが変わったかほとんど気づかれないだろう．よけーな隠しディレクトリがいろいろとあったので，それらを消したのである．

今日の食卓

朝 (0715): 米 0.7 合．ワカメ炊きこみ飯．コマツナおひたし．麺つゆワサビ和え．
昼 (1245): 弁当．米 0.7 合．朝と同じ．あれこれと枝殺しについて考えていたので，いつもより遅い昼飯．
晩 (1930): 米 0.8 合．豆腐・タマネギ・ピーマン・シイタケのカレー．

ぎょーむ日誌 2001-06-20

2001 年 06 月 20 日 (水)