ぎょーむ日誌 2001-07-03

2001 年 07 月 03 日 (火)

• 0630 起床． 起床を 30 分早める．
• 朝飯・弁当の準備． 朝飯． コーヒー． シャワー．
• 0725 自宅発． 晴れ． 特急に乗って 0735 京急平和島発． 普通に乗り換えて 0805 京急上大岡発． 0820 研究所着． この時間に移動するのは最悪だと分かった． 上大岡-杉田間の電車， 高校生でちょー混雑．
• えーい， 今日も今日のろーどくができん．
• あ， 昨日帰宅するときに メイルサーヴァーBookPC → (腐れファイアーウォール) → Asahi-Net という経路にメイルを転送設定するの， 忘れてた．
• あちこちにメイル書き．
• 北大のネットワーク， また通信途絶 …… と思ったら 0900 すぎに回復．
• (一言近況) 武蔵・相模は暑い …… ということで， 今週の木曜日・金曜日に 北大におじゃましまーす． (2001.07.03)
• う， なんか「ニセ」アカマツの改善に着手できん …… またカフェイン取りすぎか?
• 以前に書いてた， 旧「ニセ」アカマツの三つの「爆弾」
  1. 茎成長パラメーターの決め方
  2. 茎の親子関係の決め方
  3. 茎の集まりである枝の死に方
  のうち， 2. と 3. は解除した． 「枝」という概念を捨てて， "rank_number" (と「ニセ」枝) で代用するように 変更したわけだ． やや皮肉なのは, 以前の枝モデルよりは「ニセ」枝を使ったほうが まだマシそうな結果が得られている， ということである．
• さて， 残された問題， 茎の肥大成長のパラメーター推定， について． ある age の茎は

  diameter_age = log( 1 + b * age ) * a / b

  という (a, b) 2 パラメーターの 単純な数式で与えている (決定論的モデル)．
• パラメーター a が茎ごとに異なる値として 解体データから直接求めるのに対して， b のほうはすべての茎で共通な値としている． そのときに
  1. 一年生の最大茎と二年生の最大茎の 直径を与えて Newton 法で計算してしまう．
  2. さらに実験に用いられた 8 個体で 1. のように推定された b のうち， 最大の値のものを全個体に共通な b として用いる
  ということをやっているわけだ． 後者はこんなかんぢ．

  log( 1 + b ) / log( 1 + b * 2) = max{ d1 } / max{ d2 }

• なーんでこんなややこしいコトやってるのか? それは旧モデルにおいては茎の親子関係が重視されており， それを決めるためには親の a は必ず子供の a より 大でなければならない， といった制約があった …… つまりこのパラメーター推定と親子決定モデルが 相互にややこしく連関していたわけだ． ここ一週間ほど新モデル開発として 取り組んでいるのは， このような面倒な親子関係や枝など無くても 成長できる樹木個体シミュレイター， というのをつくり出すためである．
• ということで， もはや茎の親子関係などというものを 肥大成長パラメーター推定に持ち込む必要なし． しかし， じゃあ， よい代案があるかというと， ぢつは無いんだよね． パラメーター b 決めるべき正当な手続きがない (ホンモノの成長データはどこにも無いから)．
• さーて， 困ったぞ …… ということで， 以前から考えてきたまたまた窮余の一策， というのを持ち出さねばなるまい． やはり根拠がなくて ばかばかしいんだが， 最大値ではなく平均値を使って b を計算する， というやり口である．

  log( 1 + b ) / log( 1 + b * 2) = mean{ d1 } / mean{ d2 }

  …… こんなことをやっても意味はないんだけど …… そうねぇ， 多少はロバストになるかな， というぐらい． 「生態学者は数値の平均取れば， ケガれが祓われるという信仰を持つ」 とか言ってるわりには， 当方でも同じことをやってるわけだ． うーむ ……
• 成長関係を担当する Perl モジュール growth.pm に ちょっと手を入れてから昼飯．
• 結局， 上に書いてるような意味不明な平均値から b を計算することにする． さて， 査読者はこの意味不明ぶりを うまく指摘できるだろうか? そう， ここは 「ウソをついてもばれなければかまわない」 世界なのである．
• …… と思ったら， 楽しいねぇ． 平均値なんか使ったりしたら， b の推定値が負になっちまったよ． 調べてみると， 二年生に比べて一年生の成長が貧弱な場合には 推定に失敗するみたいだな． さーて， どうしよう．
• いくら何でも負になるのはおかしいだろう， と思ったんで数式を見直す． あ， こいつは計算機が苦手とするタイプの数値計算だな． Newton 法に与える数式を解きやすいように 変形してやると …… はーい， 上手に解けましたね． 賢い賢い．
• しかしそれから推定された生産率とかヘンだな． ヘンというか面白くない． 処理と対照の分布が似てしまうんだよなぁ (かなり終ってる発想) …… やはり全個体に共通な b を設定しないと ダメではなかろーか． でないと， 成長の差がパラメーターの値の違いで補正というか 吸収されちゃうんだよね．
• ということで， さらにばかばかしいが個体を無視して茎全体の 平均値を使って b を計算してみる …… そう， こういうふうに全個体に共通の値を与えると， 処理区ごとに差が出るんだよね．
• 全個体に共通な値として 推定された b は 8.85e-6 というような 小さいものだった． 以前に作ったグラフ作成 Perl スクリプトは 今でも使えるので走らせてみる． こいつは実行時に上の growth.pm を読み込んで 計算してくれるので， 人間は数秒間待っていれば 新しい推定方法をつかって描画されたグラフ 8 個体分得られる． ま， 図にしてみるとそれほどヘンではないな．

[全弾斉射ふたたび] しかしこのモデルは 「複雑」 すぎるとあとからわかった．

• …… 時刻は 1630． いままで「どーもヘンだ」 と思ってたんだが， やっぱりヘンだとわかった． b はなぜこんなに小さな値なのか． 考えてみれば， こんな e-6 なんて計算打ちきりの範囲に かなり近いじゃないか …… と成長式をつらつらと眺めて気づいた． これを計算機のために「易しく」変形してやると，

  mean{ d2 } * log( 1 + b ) - mean{ d1 } * log( 1 + b * 2) = 0

  …… おい． これって Newton 法使うまでもない． 暗算で解ける． 答えは b = 0 だ． それが唯一の解だ．
• うーむ …… バカというか何というか． 今まで気づかなかったなぁ． いやはや， われながらヒドい． つまりこのやり方では解は得られない． b が不定になってる．
• では， マジメに二元連立 Newton 法やるか? …… いや， その必要はない． ここで発想を転換すればよい． なんで 2 パラメーターなのか． 未知のパラメーターなどひとつにしてしまえばいい．

  diameter_age = log( 1 + age ) * a

  こうしたところで誰も困らない． なぜなら， アカマツの茎の肥大成長がどういう式に従うか， なんて誰も知らないんだから．
• 生態学で使われる成長式のほとんどは， 少なくとも 2 コ以上のパラメーターで構成されている． 1 パラメーターモデルなんてほとんど使われない． で， なんとなく「ニセ」アカマツも ふたつ値を決めていたわけだ． しかし， そうでないと不都合である， と考えるべき根拠はまったく無い． ということで， 1 パラメーターモデルに変更する． いやー， これで必要とされる説明の量が大幅に減じたぞ． さて， 計算結果はどうだ．

[パラメーター 1 個] …… に減らしても， べつにどうってことなし．

• とくにヘンではないよな． あいかわらず「ニセ」アカマツは 盛大に「ニセ」枯れあがっているし．

[第 2223 号] 処理区の中では突出して成長のよい個体． 図は 10 年生．

• …… ということで， 「推定方法の正当化面倒なパラメーターは そもそも無かったことにしよう」 という理屈によって， 大幅なる簡単化に成功した， ということにしておきましょう． オッカムの剃刀の濫用か?
• ともかく怪しげなパラメーター ひとつ減るのは大助かりである． なにしろこの b のために Appendix ひとつ準備せねば ならんかと危惧してたもんで．
• とりあえず撤退． 1805 研究所発． 普通に乗って 1815 京急杉田発． 快特に乗り換えて 1820 京急上大岡発． 普通に乗り換えて 1850 京急川崎発． 1915 帰宅．
• 帰路途中で川崎のヨドバシカメラで増設メモリを 買おうかどうか悩む． 独房内計算機 BookPC はふたつスロットがあって， いまは 64MB + 128MB = 192MB という状態である． 近ごろはメモリ安いらしいな …… とはいえ， 64MB を 256MB に取り換えたところで， 合計 384MB で倍増するにすぎない． そして「ニセ」アカマツの茎は場合によっては 1 ステップで倍増する …… かな?
• 結局， 買わずに帰宅． しかし， メモリ情報 見てココロがゆれる …… PC100 SDRAM 256MB が 4000 円ぐらい， か． うう．
• メモリー購入を決心できなかった反動で， 夜中までかかって省メモリ化かつ高速化になるように プログラムを書き換えてしまう． これはいろいろな意味でかなりヤバい作業なのである． しかも寝る時間まで削って熱中してしまうほど 中毒性の高いゲイムなのである．
• さて， 深夜 0100 ごろまで没頭していた「高速化」の成果であるが …… 確かに速くはなった． いままで 115 秒要していた計算， 同じ条件のもとで 100 秒でできるようになったのだから …… うう． メモリ節約に至ってはほとんど効果ナシ． ああ， 睡眠時間が ……
• もともとオブジェクト内の情報が隠蔽されていない Perl ふう object-oriented プログラミングでは， 安全性もへちまもないんだけど …… RedpineTree 内で (別のクラスである) RedpineStem のメンバー変数を 直接操作するようにしたんで， かすかな高速化と引き換えに ますますアブないコードになってしまった． ぢつは最後の一時間はそれに由来するバグ探しに 費されていたのである． いやはや．
• 今日の食卓
  • 朝 (0745): 米 0.7 合． ヒラタケ・タマネギ・ネギ・卵の炒めもの．
  • 昼 (1220): 弁当． 米 0.8 合． 朝と同じ．
  • 晩 (2000): 米 0.7 合． 朝の残り． ナメコの味噌汁．