ぎょーむ日誌 2005-08-10

2005 年 08 月 10 日 (水)

• 0810 起床． 朝飯． コーヒー． 0925 自宅発． 曇． 0940 研究室着．
• また母子里 MCMC 計算の手順の検討のつづき．
• そういや， このモデルのあやしげな絵だけ は今年の 3 月ごろ にでっちあげていたんだよなぁ …… あ， ヘンな 説明らしきもの も書いてたのか．

• これら発掘された絵をながめつつ考える． これらのハコ (box) のデータ構造を考える段階になって， ようやく手ぬきな局所明るさ計算について検討すべき段階になるわけだが ……
• ここで昨日採用した 「二匹のモンスターを同時には相手どらない」 ぽりしーを適用して， 可能なかぎりの手ぬきを試みてみたい．
• にせ三次元計算とか? センサーからの仰角を φ とすると光強度は cosφ ってヤツですね …… で， 葉数は高度の比例配分で加重， と． われながらいんちきくさい手法だな． しかも， この手ぬきでも (とゆーか手ぬきではない光計算などそもそもありえん わけだが) 葉っぱが「どっちを向いてるか」とか考慮せんといかんね． これまた単位 vector の内積を計算すりゃいいんだな． いやはや．

• これほど手ぬきをしてるにもかかわらず …… データ構造， すごくややこしくなりつつある． 高速処理が難しそう． どうしたもんかのう．
• 昼飯．
• そういや， 母子里に関してはすでにいろいろ紙資料もらってたな， とファイルをとりだしてみる． うーむ， PoorPoint 印刷出力が 70 枚ばかり． なぜかしら落ちつかなくなったので， 全部まとめて糊づけしてしまった．

[のりづけ中]

こういうときのために備えてる木工用ボンドを使用． 大型ダブルクリップ四個で固定 (しかしこういういいかげんな工作ではきれいに製本できない)． ファイルから 昨年 11 月 20 日 いろいろ教えてもらったときにつくった手書きメモもでてきた． こりゃ助かる．

• とりあえず計算世界の POV-Ray 図を描いてみる． 格子格子格子 …… なンか， すごくヤバいような気がしてきた． ケガれ言語 Perl では手におえず (R だとさらにしんどい)， 呪われ言語 C++ の出番か? まあいきなり C++ でやっても失敗するだけなんで， しばらくは Perl でおしてみるのが正解だろう．

[計算世界，の概念図]

わくで全体を示すとこういうかんぢで． 600cm × 300cm × 600cm の空間が 60cm × 30cm × 60cm のハコ 1000 個に分割されている (後記: 高さは 720cm 必要)． そして， おそらく葉っぱの三次元分布はランダムからはかけはなれた 集中分布になっているはずだ．

• 不幸中のさいわいというか leaf area index (LAI) とゆー割算値が最悪じゃなくて最大でも 4 ぐらいなので 全体の平均葉数は 9000 枚ぐらい， となりそうだ． あ， しかし現実の葉っぱはいろいろな方向を傾いてるわけで …… そう考えるとたぶん平均 10000 枚突破だな．
• そして昨日検討した基本的なアルゴリズムを実現できるよーな， そして このめんどう計算世界に秩序を与える データ構造を決めねばならんわけだが …… うーむ， これは難しい． 計算を手際よくしようとすると複雑なデータ構造が必要となり， それによってかえって計算速度が遅くなる， ということがある． しかしながら， 何も考えてないデータ構造だとこれまた激烈に遅くなることはまちがいない．
• …… ぢっさいのところ， ホントによく考えるべきは一ヶ所だけだ (それ以外はおそらく計算速度にとって重要ではない)． 個葉とハコ (box) の対応づけである． 個葉と box を分離するのか． それとも box に個葉の集合を所有させるのか， などなど ……
• そこで個葉 & box がらみの操作を考えてみる． 計算時間に影響あたえそうなのは ……
  • 手ぬき明るさ計算: 各 box において葉っぱの垂直分布が必要
  • MCMC 葉っぱ増やし: box 内の任意の高度に葉っぱを押しこむ
  • MCMC 葉っぱ減らし: box 内の任意の高度の葉っぱを抜きとる
  基本的にはこれだけか． しかしながら， 実際にはもう少し面倒になるだろう．
• まず， 手ぬき明るさ計算については現時点ではこれ以上考えなくてもよいだろう． Metropolis-Hastings (M-H) アルゴリズムに特有な 「仮の状態」 における計算などを手ぎわよくできればよい．
• 問題は葉っぱの押しこみとぬきとりだ …… ここでデータ構造以前の問題として， 基本アルゴリズムをもう一度検討しなおす必要があるように思う． というのも， ランダムに選んだ box に葉を押しこんだりするのは， やはり効率が悪すぎるように思えるからだ．
• このあたりの直観的な対策アイデアは簡単なもので， 「葉っぱが足りないところに押しこみ， 葉っぱが余ってるところから抜きとる」 とすればよい (一種の Gibbs sampler か?)． これで効率は格段に改善されるはずだ． しかしながら， この手口が MCMC 法と矛盾していない (あるいは悪影響あたえない)， と正当化してみせねばならんあたりが難しい． つまり尤度の観点から， 葉が「余ってる」「足りない」を評価するのがしんどい …… box 間の相互作用を考えんといかんからだ．
• もっとも素朴に考えると， 葉の操作ひとつずつについて， いちいち M-H 法で状態遷移を決めるという策がある． しかし， それをマジメにやるとたぶんすさまじく時間かかるような気がする． これもやはり 他の box の尤度に与える影響も計算する必要があるんで．
• 葉の増減を決める Gibbs sampler が手軽に作れないのは， 上のように box 間で相互作用があるからだ． このために， 各 box は好き勝手に状態遷移できない …… ように見える． しかしながら MCMC 法の本領とは ここでなにがしかの「好き勝手」を実現させるところにあるはずだよなぁ．
• となるとさらに事前分布が必要， というか仮定を増やすことになる． たとえば
  • 上下の明るさ「落差」が大きいところは 葉っぱが多い可能性が高い
  • となりあう box どうしは (葉数などが) 「似ている」 (あるいは葉数勾配がなめらかである)
  といった制約だ． しかしこういう制約には hyperparameter が必要になり， hyperparameter の事前分布がさらに必要で， と面倒が累積していく．
• このあたり， 何か巧妙なごまかし計算できないか， といろいろ考えてみたんだが ……
• たとえば， 光センサーの読みの観測値にゼロ (完全暗黒) がない， と仮定すれば (このあたり低温研の加藤京子さんにお尋ね中) …… よけーなパラメーターつけずに各 box の「重み」 みたいなのは計算できる． これは葉数が log(上の明るさ) - log(下の明るさ) に比例する (直上からの光に関しては) というハナシの悪用である． 明るさの観測値が何か確率分布にしたがうと考えると (このあたりいまいち理論的に弱いな) log(上) - log(下) の期待値が計算できるので， これを重みとするというやりかただ． 観測には「上が暗くて下が明るい」 という場合も多々含まれているんだけど， たたみこみ確率から計算する期待値は常に正なので， どの box も葉っぱ存在確率がゼロにならない．
• しかし， いまいちすっきりせんな．
• えーい， よけーな仮定は全部削除して， 最初は非効率覚悟で素朴な …… だめだだめだ． ランダムに box 選んで葉っぱを押しこむ， というのは阿呆すぎる．
• 時刻は 1940． 腹もへってきた． 本日はここまで， か ……
• と書いた瞬間に， よーやくにしてちょっとだけマシな策を思いついた． 葉っぱを増やすときには (葉っぱを押しこむ) box を選ぶ方式はダメだ． そうではなく， すでに存在している 葉っぱをランダムに選んでそいつを分裂 させりゃーいい …… たしかに， これをやっても 「葉っぱが足りないところに押しこみ， 葉っぱが余ってるところから抜きとる」 は実現しない． しかし， 葉っぱの集中分布は容易に実現する (これはおそらく必要不可欠)． 実に個体群生態学的な発想． 葉群のうまい配置は M-H 法にまかせるしかなさそう． たぶん定常まわりならこのアルゴリズムで良さそうだ．
• この方式について検討してるうちに (これまたよーやく) 気づいたんだけど， どういう計算方法でも次の二点が重要だ． ひとつはやっぱり初期配置をうまく選ばんといかん …… 定常状態に移行するまでの時間を短くするためには． そして第二点はもっと大切で， この林冠 MCMC 計算が Gibbs 過程であるためには， どの葉群配置状態にも 必ず遷移できることが保証されていなければならない． つまりカラの box が永久にカラのまま， というのはまずいわけだ．
• えーと， これは「葉っぱの box 間移動」で解決してみせるしかないなぁ． やはりよけーなパラメーター， 葉っぱ移動確率， といったものが必要か． これは林冠の情報エントロピーを増大させる因子だ (あてはまりが悪くなる方向に系を揺するから)． 物理屋ならこのパラメーターを「温度」とか呼ぶのだろうし (いや，「外場」か?)， MCMC な遺伝学研究者なら突然変異率とでも呼ぶのだろう．
• さーてさて， ならばデータ構造は …… と考えようとしたんだけどもはやばてたので撤退． 1850 研究室発． 2140 帰宅． 2230 自宅発北大構内走． 走ることで物理的に脳を揺すってみるという操作によって， また考えのへんてこな部分がすこし修正されてきた． 2320 帰宅． 体重 74.0kg． 晩飯．
• 上では「葉を分裂」という奇妙な方法で， (現実で観測されるような) 葉の空間的な集中分布を容易に実現できるとしている． また， Gibbs 過程の要請を満たすその他の理由でこれまた奇妙な 「葉の移動」 という過程も必要だと述べた．
• で， 北大構内走中に考えた修正案というのは， これらふたつをひとつにすればよい， というものだ． つまり「葉の分裂」をしたときに， 新しく作られた「娘」葉は「母」葉と同じ box もしくはそれに「隣接する」 box のどれかひとつに出現する， という操作だ． これによって
  • やはり葉の集中は実現しやすい
  • Gibbs 過程の必要条件 (どの状態にも遷移可能) を満たす
  • となりあう box どうしが 「似ている」 (葉数勾配がなめらかになる)
  • 「移動確率」ごときよけーなパラメーターは不要 (見かけ上は，なんだけど)
  となるわけだ．
• そして上でも書いているように 「観測データにあてはまるような三次元葉群配置」 たち は M-H 法が巧妙に見つけ出していってくれる， と期待するしかないのか ……
• もし上の方式でうまくいかないなら， やはり 「葉っぱ一枚の変化ごとにめとろぽりす」 という最も原始的な方式でいくしかない． これなら確実だ． しかし時間かかるだろう． この場合は局所的明るさ再計算の高速化がカギになる， と．
• まー， 何もかも観測データの実態とプログラムの実装しだいだな．
• [今日の運動]
  • 北大構内走 50 分間．
• [今日の食卓]
  • 朝 (0830): 米麦 0.7 合． ゴーヤ・ニンジン・ピーマン・マイタケ・豆腐・卵の炒めもの．
  • 昼 (1310): 研究室お茶部屋． 米麦 0.5 合． ゴーヤ・ニンジン・ピーマン・マイタケ・豆腐の炒めもの．
  • 晩 (2410): 蕎麦． トマト． キャベツ・ニラ・ホタテの炒めもの．