ぎょーむ日誌 2006-07-03

2006 年 07 月 03 日 (月)

• 0830 起床． 朝飯． コーヒー． 0940 自宅発． 曇． 0955 研究室着．
• なぜかあちこちから (それぞれ独立した) 問い合わせあれこれが． 順番に始末していく． なぜか大陸奥地に繁殖生態学 GLM 解析結果を送りつけてひととーり落着． 時刻は 1125．
• 母子里 Gibbs 林冠モデルの特に光計算まわりの記法 (notation) というか「説明用モデリング」の研究． 私の計算アイデアを厳密に反映しているプログラム言語のコード (in 呪われ C++) がすでに存在しているにもかかわらず， 論文をかく段になってこのあたりを考えねばならぬことがときどきある．
• プログラム言語によって記述されている光計算モデルは
  • その計算世界を表現するにあたりいっさいの手ぬきなし
  • 計算世界を構築できている点において完ペキ
  • 計算機のごとき 「この世界」理解わくぐみが欠落したやつでも理解できるほど 基本要素のあつまりに還元されている
  • 複雑なデータ構造も正確に表現されている
  などなどといった諸点にすぐれているわけだが， 人間が読むとなかなかツラい場合が多い． 自分で書いたコードであってもだ …… 書いてるときにはあっちの世界むけにアタマの中が再構成されているので， しんどくないんだけどね．
• ようするにあたりまえのことで， 計算機 (あるいは対計算機格闘モードにある人間) にとってわかりやすい表現と， ふつーのヒトにとってわかりやすい表現は異なる， というだけのことで．
• なんでこんなことになってしまうのか端的に言えば， 自然現象の 「ちょっと現実っぽい」 数理モデル化は複雑なデータ構造を要求し， 現代のプログラミング言語はそれを可能にしてしまうからである．
• 論文の「方法」にあたる部分は「正確」に書けってことになっているんだけど， これをマにうけると光計算の部分だけで A4 single space で 30 ペイジを超えることはまちがいない …… そして， そのかなりはデータ構造の定義と生成方法について費されるであろう． さらに， それを書いたところで， 読者は数理モデルによる抽象化と 何重にも階層化されているデータ構造の ふたつを同時に理解しなければならないので， よほど忍耐力と時間をついやさなければ何が何だかわからないだろう．
• まあ， Knuth 先生みたいに literate programming をココロがける， ってのは魅力的な考えなんだけど …… これは「ホントに (字義どおり) 正確に書く」 という数学ではあたりまえの作法を， コードと対応させつつ計算機科学・情報科学の分野にもちこんだ方法， とでも考えるべきなんだろうね． しかし自然科学の論文の読者は歓迎しないような気もする．
• とゆーのも， 自然科学の論文のたいはんの読者は (おそらく私自身も含めて)， 文字どおり「正確」にわかりたいのではなく， 「正確」にわかったふりができる せいぜい数ペイジぐらいの説明が読みたいのだろう．
• つまり必要とされているのは， 「これは正確だ」と思わせる説明なのである． いきなりどろくさいハナシになるけれど， そこに書くべき内容はとうぜんながら， どこに投稿するか， どういったら査読者に読まれるのかといったことに強く依存するわけで．
• かなり情報をけずりとって (犠牲になるのは 工夫をこらしたデータ構造とそれにまつわるアルゴリズムまわりだ) 相手にわかったふりをしてもらえる作文を構築する， ってのは書いてるがわからするとなかなか気分が悪いわけだが …… まあ， 今回もその計算コードをネット上に公開する (とうぜん査読段階でダウンロードできるようにする)， といったことを考えると気分の沈降速度が多少は緩和されるわけで．
• …… といったうだうだとした考えにナヤまされつつ， 「光のモデル化」 という部分を簡単な数式で表現できないか工夫してみる． まだ作文できる段階ではなく， 紙の上で数式をひねくりまわしてる状況である．
• そうすると， コードで表現されている架空世界とはずいぶんと異なった印象の世界となる． 自分がひとつの「計算区画」のかたわらにたつ傍観者のようなもので， そこだけわかれば他もわかるはず， そこだけえらく具体的で あとはひどく抽象的といった奇妙な遠近法を適用したような． 何とおりもの異なる方法で 架空世界を理解しようとするアタマってのは 不思議な動作のものだと思わせられる．
• ぢりぢりと前進したので昼飯． 現在， みなさん野外調査にでかけてしまって院生密度が低いわけだが， お茶部屋では「とりのこされた」院生たちが地図をひろげつつ 「とにかく何でもいいから外に出たい」 計画を立案検討中であった． お茶部屋には不思議な相互作用がみちている．
• 数学なんかでは 「ホントに (字義どおり) 正確に書く」 とか書いたけど， これと関係して Radium software さんの Proof that 1 + 1 = 2 はいろいろな意味で面白く考えさせる内容だ． 19 世紀後半から 20 世紀前半にかけての数学基礎論の発展の中で， 「基礎」をきちんと記述するには 尋常ならざるどえらい労力がかかるということがあきらかになってきた． たとえば， ここで紹介されている例だと， Whiltehead and Russell (1910) による Principia Mathematica (「数学原理」) では準備に記号びっしりの 379 ペイジばかりを費してよーやく

  From this proposition it will follow, when arithmetical addition has been defined, that 1+1=2.

  つまり 1 + 1 = 2 が成り立つことを証明できたわけだ． 楽しくもあり， すなおに笑えぬ側面もあり．
• また母子里のつづき．
• 何やら， これから書く予定の論文のタイトルをだせ， 空想的でもよいから， といったメイルが． じゃあ， ひとつでっちあげてみるか …… いや待て． 母子里林冠のハナシも使えないかな? みかけ上は関係ないわけでもないよね． 母子里論文に OTC の言及でも追加するか? けっきょく， (そのプロジェクトとは無関係にススめてきた) 母子里林冠モデリングと まだ何も計算してもいないハナシをあげておいた．
• ともあれ， いまさらながらだけど， こちらのぷろぢぇくとに関しても何かやらねばならんわけですなあ …… 人間やめますかそれとも「やすうけあい」やめますか， ということか． あるいは「何でも屋」と思われていることの利害得失いやいや自業自得か．
• ぢりぢりとしてススまぬので， 気分転換に炭・七輪のかたづけ． 先日のジンパでつかったやつ． A803A 講義室奥のものおき区画におくことにする．
• 稲葉さんと海浜植物データ構造 & モデリング議論． 植物ごとにデータ構造がかわってしまう， というのは今までありそうでなかったハナシ． そして「データ構造」といったコトを検討せねばならぬ状況にあって， ゑくせるはやはり非力だ， と痛感させられる． OpenOffice.org の データベイス で階層データ構造をあつかうには …… すこしばかり研究・実験が必要とされるみたいだな (例: OpenOffice.org Base の利用方法)．
• データ構造はまだいいとして， 問題はモデリングだ． じつはそのあたり明らかにされぬままデータがとられているわけだが …… ひとつ確実なのは， たとえば「葉の発育と花の発育の相互作用」 みたいなものを調べねばならぬとして， このときに
  1. 季節変化・時間変化の効果
  2. 場所の効果
  3. 個体差・個体の中の器官の効果
  みたいなものも「つきまとってくる」という面倒さだ． 場所や個体差は時間的に変化しないと (やや強引ながら) 仮定しまえば， いつものごとく random effects としてあつかえるわけだが …… やはり季節変化をふくむ生態学の観測データってのは格段に難しい． モデリングにいろいろと工夫が必要とされる．
• さらにある特定の季節にだけ (どの個体でも) いっせいに花が咲いた場合， それが季節の効果なのか開花の効果なのか推定計算の上では判別できない． しかもぱっと咲いて散るならまだしも， 海浜ではだらだらと咲きつづけてくれるらしいんだよね ……
• 1955 研究室発． 2010 帰宅． 晩飯．
• [今日の運動]
  • うんどう休養日
• [今日の食卓]
  • 朝 (0850): 米麦 0.6 合． ホタテ飯． ネギ・ブナシメジのスープ．
  • 昼 (1320): 研究室お茶部屋． 米麦 0.6 合． ホタテ飯． ネギ・ブナシメジのスープ．
  • 晩 (2230): うどん． 金曜日の研究室じんぱののこりもの． タマネギ・豆腐のシチュー．