ぎょーむ日誌 2002-02-19

2002 年 02 月 19 日 (火)

• 0615 起床． う． 5 時台に起きれん．
• 朝飯・弁当の準備． 朝飯． コーヒー． シャワー．
• 0645 自宅発． 晴れ． 寒い． 特急に乗って 0657 京急平和島発． 寒いと東京湾岸を被覆する汚塵も街の底に沈殿し， さらに晴れていると京急の電車から富士山がよく見えたりする． 普通に乗り換えて 0728 京急上大岡発． 0745 研究所着．
• 昨晩の計算結果は (といっても微小ポリゴン捨て手抜き計算やってるので， 80 年計算も 2 時間未満で終るんだが) …… pipe_bundle->AreaTotal() とバンドルの総面積に依存する死亡率ではダメだな． 死ぬ個体が少なすぎる． pipe_bundle->AreaAlive() にしてみるか． ちょっと再計算させて様子をみる．
• PipeBundle は「寝ている」ほうが折れやすいというふうにしてみたり， いきなり折れたときの処理に混入していたバグをつぶしたりして， ひととーり問題なく動くようにはしてみる． すでに時刻は 1015． うう．
• 残念ながらこの主軸-側軸長さ関係の変てこアロメトリーを強制させられている 現ヴァージョンではこれ以上の改善は不可能， と判定． くだんの「樹高のびが 8cm になりがち」問題 その他を抜本的には解決できないためだ． そこで現ヴァージョンを pipetree2002a として凍結して project archive に保管し， そのあたりの怪しげあろめとりー打ち捨てて 資源配分モデルをまともなものにしようという試み pipetree2002b を開始する． しかし残された時間がなぁ ……
• ともあれ取り組んでみる． 面倒なる制約のもとでなされる Abies PipeTree 内部の 資源配分機構はひかえめに言っても複雑怪奇なものであり， この改造ではそれを多少はわかりやすいものにしたい．

• 樹木から資源配分問題を丸投げ一任されているのは CentralAdjuster である． CentralAdjuster は動的な試行錯誤計算によって末端形成部と支持部肥大成長の バランスをとる． コードを読むと ……
  1. ResourceAllocator を介して全末端に資源獲得能力を計上させる．
  2. 全資源を p_terminal と 1 - p_terminal に分割し， そのうち p_terminal を ResourceAllocator にわたす．
  3. 末端で新規生成された PipeBundle の大きさに合わせて支持部の PipeBundle を太らせてみる．
  4. 2. と 3. に必要とされる資源に過不足が生じないように p_terminal を調節できるまで 2. - 4. を繰り返す．

• つぎ， その下請け ResourceAllocator．
  1. ある量の資源を渡されたら 各末端にそれを配分する． 各末端は TerminalAdjuster． と相談して自分の形状を決める．
  これだけ．
• さらにその下請け TerminalAdjuster． しかしここは処理の説明がややこしい． TerminalAdjusterVertical と TerminalAdjusterLateral が派生するし． 概要だけ． 2. - 4. がアタマ痛い怪しげアロメトリー制約である．
  1. 渡された資源を q と 1-q に分割する．
  2. q の資源で作れる主軸の形状 (長さ・太さ・針葉群重量) を決定する．
  3. 主軸の長さから側軸の本数と長さが決まる．
  4. 側軸の長さにあわせて側軸の太さと重さが決まる．
  5. 側軸たち全体が 1-q の資源で作れるか点検し， 過不足があれば q を調節して 2. にもどる．
  これだけみると簡単ぢゃん， と思うかもしれないけど一度計算した結果を記憶する， まぁデータベイスのようなものと連動しているので 面倒なんだよね． はい．

• 一番問題なのは この TerminalAdjuster 群でやらせてる計算でまっとうな q が見つけられない場合が多々ある， ということだ． 昨日からうだうだ言ってる「主軸 8cm」(vertical の場合) において必要とされる資源量がどかんと変化するんで， どうやっても資源が多量に余るとかぜんぜん足らない， とか ……
• 諸悪の根元は このような解決不可能な問題の答えを探し回る試行錯誤にある． どうすればよいか? 考えるまでもなく， かかる怪しげな制約条件のもとでの 主軸・側軸の形状・本数を決定する こういった試行錯誤そのものを やめちまえばよいのである． それでは試行錯誤なしで どーやって主軸と側軸の長さ・太さ・針葉群重量・本数を決めるのか?
• 解決する策はある． 主軸・側軸の間の関係の全てをトップダウン的に決めつけるのではなく， ある程度は「自主的に」やらせてしまえばよい． つまり， 主軸・側軸の「芽」を作っておいて その「芽」たちに主軸や側軸をめいめい勝手に作らせる， という方式だ． これは私が自分で考えたとは言えないもので， フィンランドの LIGNUM で芽の形成やっていたり， あるいは以前に環境研の 竹中さん に教えてもらったアイデアを， PipeTree に流用しようと企んでいる， というような ……
• PipeTree の資源配分機構の呪われ具合を この「芽」形成アイデアによって軽減する方法の概要を書いてみよう．
  1. 各末端に資源獲得能力Sを計上させる．
  2. この段階で「芽」の個数を決定する． ま， 以前のあろめとりーモデルに多少敬意でも表して 軸の長さに合わせて側軸の「芽」の個数が決まるようにする (主軸は定義から言って常に 1 本)． ただし， 新規生成される主軸 (子供) の長さではなく， 親の軸の長さにあわせて．
  3. 各末端での資源獲得能力 S を分割して， その末端に形成された「芽」に分配する． このときに， 前のアロメトリーモデルで考えてた 「主軸長さ→側軸長さ関係」なんかが 多少は反映されるように配点する．
  4. 以前と同じように CentralAdjuster のp_terminal 探索ループを動かし始める． これまた同様に ResourceAllocator が呼ばれる．
  5. 末端資源配分業者 TerminalAdjuster に渡された資源は末端にある「芽」に分割される． これはそれぞれの芽が持つ資源獲得能力に依る． 「芽」に渡された資源に合わせて 主軸や側軸の形状が決まる (これは以前と同じ)．
  これでややこしー試行錯誤計算はひとつ廃絶してしまって (CentralAdjuster では あいかわらずふらふら試行錯誤してるんだが) 樹木全体の形状が決定することができる．
• 以前との違いだけを要約しておくと，
  • 新しい主軸あるいは側軸の形成は 「芽」にまかせる． 軸の形状はいままでの長さ→太さ関係で決める．
  • 側軸用の「芽」の個数は 長さ→側軸数関係で決める． ただし親の長さを使う．
  • 主軸長さ→側軸長さ関係は使わない． ただし， 主軸「芽」と側軸「芽」の配点に際して， 観測された主軸・側軸のサイズの相関を考慮する．
• 試行錯誤をひとつやめるためのアイデアの試行錯誤で午前中終ってしまった． いやはや．
• 1205 トイレでジャージ上下に着替えて 独房群内の人目につきにくい経路を選んで脱柵． 今日も晴天． 富岡総合公園 前峰までゆっくり走って登り， 頂上でストレッチング． 反対側に降りて主峰に登る． 少し降りて芝生の野球場 10 分ほどまわってから 往路を引き返して 1245 独房群帰着． 昼飯．
• 「芽」無しから「芽」あり PipeTree への移行作戦を発動．
• 1555 よーやく TerminalAdjuster の書き直し終った． TerminalAdjuster の Vertical & Lateral 派生クラスやめ． この単純化はたいへん良い． しかし， 軸の形態形成に関しては あいかわらず数表生成 + 線形補間というへぼいアルゴリズム．
• 1630 それにあわせて PipeTerminal も改装終了． Bud というクラスのオブジェクトに (CentralAdjuster による) 試行錯誤計算を一時的に保存している． もいっぺん TerminalAdjuster にいって Bud の scoring まわりの関数かかねばならない． ひょっとして， TerminalAdjuster と PipeTerminal というこの世界の底辺で働かされてる連中を 書き換えてやるだけでよいのかしらん?
• えーと， 明るいところでは主軸に資源をまわし， 暗くなったら側軸を伸ばしていくようにすればいいんだな (ホントか??)． はしっこの場合分けに注意して TerminalAdjuster::SetBudScore 書く． 時刻は 1655．
• 全体のコンパイルを試みる …… おっと， そうか Forest でも TerminalAdjuster 使ってたな． 樹木のもとを生成するために． 1710 全体のコンパイル通過．
• 試験運転． なるほど， core 吐きエラー． いつものごとく gdb でスタックバックトレイス．
• やはり計算結果キャッシュの数表まわりのエラーか …… デストラクターでコケるということは 何かかなりヘンなのだろう． 今日はここまで， か．
• ハミガキして 1800 研究所発． うう， 今日も歯医者．
• 右上奥歯三本の何割かを代替する「ニセ」歯の装着． 今回は麻酔ナシなんで， 歯に掘削された穴の中でむきだしになってる神経に 水とか空気とか吹きつけられるとすごく痛い． なんつー純粋無比なる一点集中の激痛． これも自業自得なのか． となげいてるうちに私の口内サイボーグ化作業終了． 診療費 3240 円も支払うことになりこちらもイタい． うう． え， また来週もですか．
• まだしくしく痛む右ホオを押えつつ 1830 京急杉田横の歯医者発． 普通に乗って 1833 京急杉田発． 快特に乗り換えて 1848 京急上大岡発． 普通に乗り換えて 1910 京急川崎発． 1940 帰宅． 体重 71.2kg． C++ 呪われやせ．
• 晩飯． なぜか， まだ歯が痛い． あとで鏡みると上側奥歯は左右とも はなはだしく金属化されてしまっている． 私の場合， 白骨化死体で発見されても簡単に身元同定できそうだな．
• Linux その他で使える freeware のドローイングソフトウェアというと， tgif だの sketch だのが一般的なんだろうが …… この sodipodi って， ちょっと使ってみたんだけど (Vine Linux の場合は apt-get install sodipodi でネット経由で簡単にインストールできる)， 今までのとは異なる使い勝手というか …… まだ version 0.24 なのでこれから発展していきそうな プロジェクトではある．
• ちょっと PipeTree コードに手を出してみる． 夕方に引っかかっていた core 吐き エラーの原因はわりと単純なものだった． おお， 毎年 8cm の壁とかカクカクしたかんぢとかではなく， 樹高成長速度がなめらかーに加速してるよ …… これは嬉しい．

[「芽」が作りだした管樹木] 「主軸長さ→側軸長さと決まる」 なるあろめとりールールを廃して， 代わりに主軸・側軸を形成する「芽」を 導入した新型 Abies PipeTree． 旧型の問題点「ぎくしゃくした成長」 が解決された．

しかし， シミュレイション終了時になんかまた別の core 吐きエラーあるな． 例によって計算世界の消滅を伝言ゲイム的に告知していく 階層的デストラクターがらみのようで． うーむ．
• しかしあまり深入りせずに 2300 ごろに切り上げる．
• 今日の食卓
  • 朝 (0625): 米 0.6 合． ナバナ・タマネギ・エノキダケの炒めもの． 麺つゆ味．
  • 昼 (1255): 弁当． 米 0.8 合． 朝と同じ． 野菜炒めは水気がでないように 水でといた片栗粉でカタめる． これはよく使われるワザ．
  • 晩 (1950): 米 0.6 合． 朝の残り．