ぎょーむ日誌 2005-12-28

2005 年 12 月 28 日 (水)

• 0850 起床． 10 時間ぐらい寝た． おかげでよーやくアタマが修復． 朝飯． コーヒー． 1010 自宅発． すげー大雪． 1025 研究室着．
• 屋久島照葉樹の葉寿命モデリング． 年枝を Segment としてたのを YearShoot と改名してコード書きをつづけているんだが …… ここまでやらなくてもいいかも， という気がしてきた．
• なぜこのへんが複雑になりがちかというと ……
  • 末端問題: いちばん根元方向の年枝がどうなっているのかわからない 場合がある (欠測)
  • 休眠・二度伸び問題: 休眠 (根元方向の年枝齢が増加) ・二度伸び (根元方向の年枝齢が減少) が各芽鱗痕で何回生じたのかわからない
  これらをさらに「圧縮」すると
  • いちばん根元方向の年枝の葉痕数がわからない
  • 各年枝の (みかけの齢ではなく) 「ホントの齢」 がわからない
  となる． 逆にいえばこの二点以外は観測値として与えられており， 推定計算の最中に「変化」することはない．
• リスト構造になってる年枝オブジェクト， というのはある意味かんがえやすいデータ構造なんだけど， 上のような計算のためだけにわざわざ再帰を使いまくる必要あるか? ということで設計をみなおし中．
• これはデータを読ませるところから再検討したほうがいいのかな． いやはや．
• このあたりで苦闘させられる遠因のひとつは， いままで葉寿命だのシュート構造だの 研究してきた連中がいかに何も考えずに調査してたか， というあたりにあるような気がしてならない．
  • よけーな仮定をできるだけ少なくして
  • シュート伸長の休眠だの二度伸びだのの影響を考慮して
  葉寿命を推定するにはどうしたらいいか， といったすごく基本的な問題について， いままでマトモに考えられていない． ということで， 私などがここで 「欠測データの処理の方法」 とかいまさらながら検討させられてるんではないかな． 雑学的知識ばかり重視するくせに基本的計算の方法は軽視する連中， というか．
• で， データ読みこみ部分をみなおすと …… いつものごとく， こういう階層構造のあるデータをゑくせるで入力するのはよせ， と言いたくなる． 「集団の中の個体の中の枝の中の年枝の中の葉っぱ」 とゆー階層構造が認識されてないから， ゑくせるになってしまうんだろうか．
• 昼飯． 外はあいからわず大雪．
• 来月の東京出張は甲山さんからの「依頼出張」になる …… といった意味不明ぎみの趣旨の自動発信メイルを北大旅費システムからうけとる． 北大の旅費システムにもぐりこんでみたんだけど (事務処理劣悪な北大にしてはオンライン化されただけでも偉いと評価すべきなんだろうけど， ぶらうざー依存性などがひどくていまいち感も濃厚)， 状況がよくわからない． 結局， 雪野さんのところに伺うと …… 全てはここに集約されていて， 雪野さんが甲山さん名で依頼出張の手続きをだし， つぎに久保名でその依頼に対応しておられた． なンかすごいです．
• 来月始めに「東京三菱銀行」が「三菱東京 UFJ 銀行」になるので， その変更届を会計掛に提出する．
• 屋久島モデリング， データよみこみまわりの再整備， 葉数・葉齢分布のデータ構造の簡略化， 階層ベイズモデルの線形予測子の構成， 尤度計算 …… という順で作業をススめていく．
• さて葉っぱ生き死に尤度計算でいつも注意せんといかんところがある． ある齢 a の年枝に葉っぱと葉痕があるとする． 葉っぱに関しては齢 a まで生存している， と言える． このようにある葉が齢 a まで生残する確率を p(a) とおいてみよう． いっぽうで， 葉痕は「いつ死んだかわからないけど， 齢 a までには死んだ」という情報だ． こういう葉痕一個が観察される確率は? これは簡単で， 1 - p(a) でよいのである．
• 1630 ひととーり書けたように思うので試験運転開始． 現時点の計算プログラムは， 単純に (樹種間共通) + (樹種差) + (個体差) だけを計算させる階層ベイズモデル版である． 休眠や二度伸びといった常緑樹の呪われ属性は まだ考慮してない． こいつらの効果の設計・実装はたいへんそうなんであとまわしだ．
• あ， output まわりの関数準備するの忘れてた． output まわりもめんどくさい．
• しかし， やってみたら上部はともかく下部構造は意外と前のやつと重複していた． Perl のアヤしげなる @ISA 継承 でもってインターフェイスと実装を引き継ぐべきか? …… いや， びみょーにずれてるからダメだな．
• 実装の継承だけやりたい …… と書いて， ふと気づいた． ケガれ言語 Perl の場合， それは単に「ふつーの関数」 とかに $self (べつに $this と書いてもよいが) を渡してしまっていじくってもらえばよい， ってこと? いかにもケガれた解決策だな． なにしろ クラス::メソッド だってどこからでも呼べるわけで． 呪われ言語 C++ ふうの用語で説明すると， Perl においては「メンバー変数」がことごとく ``public 属性'' なんで， それが可能， ということ．
• さすがにこれはやりたくない．
• お茶部屋で休憩． また院生たちの家庭事情に詳しくなってしまった． 女性大学院生たちの挙動を理解する上で 「パパ」 たちは重要なのかも． どうなんだろう．
• 事前分布の分散パラメーターは別に出力すべきかな …… まあ， しばらく放置．
• いろいろ手直ししてよーやく MCMC 疾走するようになった． 時刻は 1930． といっても， ぢりぢりとしか進捗しないが． かなりサンプリングの間隔をあけないと Hyperspecies の階層ではパラメーターが動かない． いまのところ 20 MCMC step とばしでやっているんだけど， 毎回変わるパラメーターはない．
• 何やら M2 なヒトたちが 「修論おいこみしーづんをがんばろう夕食会」 にでるというので， 修論したうけの私などもそういうトコロに参加可能でしょうか， とお尋ねしたところ一瞬で却下された． 嗚呼， 身分のいやしいしたうけの悲哀．
• メトロポリス法で MCMC 動かしてると， ときどき 「葉っぱの生残確率 10^-100」 となってしまうようなトンでもないパラメーターを 「これどうでしょう」 と「提案」してくる． そういうのは尤度が悪くなりすぎるので， とうぜん「却下」される． しかしながら， ヒドい場合には計算機の数値精度を超えるような値になることもあり (なにしろ無情報事前分布なんで) …… その場合， 「生残確率ゼロ」 にされてしまうこともある． こうなると対数尤度が評価できなくなるんで， ごまかし補正をいれてみる．
• この小細工は最終的に， 確率 200 万分の 1 の「上下げた」をはいた logistic 関数， という奇妙な関数型にまで発展した． 私の憶測なんだけど， この方式は世界中の MCMC 使いたちのあいだでで こっそりと愛用されてるにちがいない …… いや， ぎぶすサンプラーをちゃんと書けば， かかる面倒は不要なのか?
• パラメーターひとつひとつのメトロポリスサンプリングごとに すべての個体のすべての枝のすべての年枝のすべての葉っぱでの 尤度を評価しなければならないので計算がおそい．
• いまいちうまく計算できてないような気がするまま撤退． 2105 研究室発． 2120 帰宅． 晩飯．
• 試験運転， 真夜中すぎまでつづく． というか， 計算機には徹夜計算を命じて寝る．

• [今日の運動]
  • 冬のうんどう不足状態， つづく ……
• [今日の食卓]
  • 朝 (0920): バターロール．
  • 昼 (1300): 研究室お茶部屋． 米麦 0.5 合． コマツナあえもの． ネギ・ショウガ・鶏レバ炒めもの．
  • 晩 (2150): 米麦 0.8 合． コマツナあえもの． ネギ・ショウガ・鶏レバ炒めもの．