ぎょーむ日誌 2001-01-(11-20)

2001 年 01 月 11 日 (木)

• 0700 起床． 眠い． 寝たのは 0400 ごろかな．
• 朝飯・弁当の準備． シャワー． 朝飯． コーヒー． 体重 71.8 Kg． うーむ， 変化しないな (何も手をうってないから当り前だが)．
• 0752 自宅発． 曇． 0809 東京モノレイル流通センター発． 浜松町の気温 5 ℃． 0825 研究所着．
• <鳳翔>で動かしているメイリングリストプログラムの ezmlm の設定について． メイリングリストで配信されたメイルに返信すると， やはりメイリングリストに返されるように ヘッダーに Mail-Followup-To: 行をつけるようにしてみる． たぶん， これで OK のはずなんだが． まぁ， しばらく様子見よう．
• さて， 近頃の ofm-ml (小川モデリング ML) に端を発して， 昨日 Canopy Mania の ML に飛び火した問題について． 全天写真に方眼かけて， 各点において「空隙である・空隙でない」 二値をとるようなカウントをしたデータと， 森林三次元モデルの比較に関するものである． 詳しく知りたい人は田代さん管理する ML 過去ログ の ``projection'' スレッドを参照のこと．
• 私の策としては，

	そうなんですよね．しかも方眼紙上の空隙分布も残っていません
	(ついでにその方眼紙も残っていない)．

	そこで発想を逆にして，全天写真 (投影図) 上に設定された方眼を
	天球上に投影したらどういう写像になるか，という計算をやろうと
	考えています．格子点の総数はわかっているんで，

	・方眼サイズをてきとーに決める．
	・天球上に方眼を逆変換して投影．
	・「視界」内に入った格子点を数える．
	・点が実際より少なければ方眼サイズを縮め，
	  多ければ広げてまた投影 ……

	という試行錯誤計算で読み取りに使ったという方眼を計算によって
	復元しようか，と．

で， 復元した天球上に投影された方眼を利用して， モデル森林の「開空度」を計算しよう， という計画． モデル森林の中にある障害物 (樹木個体とか) の モデリングの妥当性を調べようとするものである．
• これに対して， 竹中さんが障害物の密度を過小推定するような 偏りが生じるんじゃないか， というご指摘．

	問題は，モデルと現実とで障害物たちの空間分布が一致していなくても，
	空隙点比率は一致し得るというところでしょう．

	モデルではほんとは空が見えすぎているんだけど，見える空が，立体角
	あたりの観測点密度が低いところに集中分布しているために，そのずれ
	が見かけ上検出されない，といった系統的なバイアスがないかが気にな
	りますが，どんなもんでしょうか．

たしかにその懸念ありそうですな．
• これに対するイイワケとしては，
  1. 小川の全天写真読み取りの場合， 点の数が多いから大丈夫じゃなかろーか．
  2. 方眼を球面上に射影した場合， (正射影だろうと等距離射影だろうと) 点の密度が疎になるのは 地平線方向だからいいじゃなかろーか．
  3. 読み取りに使われた方眼が残っていない ことを悪用して， 何とおりもの 「使われたかもしれない方眼」 を捏造して使用， 方眼を変えると推定結果が ばらつくようなモデルは信頼性が 低い， と評価する．
  といったことを挙げてみた．
• この返信メイル作成に 2 時間近くを費してしまった． というのも， 今朝の道中で考えたのは， 昨日の議論で田代さんが指摘されたような 「格子点が代表する球面上の領域の面積を勘案した補正」 みたいなことで何とかなるんじゃなかろーか， というコトなのであった． しかし， 実際にメイルを書きはじめてみると， それではダメと気づいたんで (元データに写真内空隙位置が含まれていないため)， 上の第 3 案をその場しのぎ的にでっちあげていたため である．
• もひとつ難しいのは， 「そのような『開空度』は カメラ近くにある障害物に かなり左右されるんじゃないか」 という田代さんのご指摘． これはいかんともしがたい． 樹木個体の位置は 5m 精度でしかわかっていないもんで．
• しかし， まぁ， そんなに精密な話でもないし． 光環境がそんなに精密に評価できたところで， 森林動態モデル全体がどれだけ改善されるかわからんし …… などとココロの中で開きなおってみる． 有効数字ひとケタの精度がある程度保証されていれば 十分なんじゃないかな． 「今日の降水確率」みたいな レヴェルの話なのである．
• 甲山さんと進めている熱帯林モデリング． 「樹冠は単純な円筒でいいんじゃないの」 ということだけど， それを採用すると こうなる かも， という懸念を返信． いぜんは こういうふうに 直したんだが． 以前の失敗なんも多少は考慮すべきだろう．
• メイル書きだけで午前中終了． なんか疲れたなぁ． 昼飯の弁当食う．
• ふーん， Mac emulator の Basilisk II って Linux 上でも動作するんだ．
• 昼飯後もメイルやりとり続く． いかん． いや， 返事出せるものは全部出したほうが良さそう．
• 1445 メイル返信終了． これでしばらくは大丈夫かな．
• 一時間ほどかけて gnuplot 出力を並べる LaTeX ファイル生成するサブルーチン書く．
• 甲山さんの曲芸的熱帯林モデリングに関する メイルのやりとり． まあ， てきとーにやりますか．
• 小川モデリング推定系で 何種類ものグラフの設定ファイルを読んだり include したのを上書きしたりして gnuplot を自動的に呼び出す Perl スクリプト …… 8 割がた完成か． ともかく eps ファイルを樹種ごとに生成して， それに対応する LaTeX ファイル吐くところまでは できた． あとは mlfitting を --plot モードで呼び出すだけだ …… しかし今日はもう帰ろう．
• 1800 研究所発． 1814 東京モノレイル浜松町発． 1845 帰宅．
• 晩飯食ってから， 自宅闇ネット経由で外付け計算機 Mate と ファイルの同期をとり， で仕事を続けようとしたんだが …… 椅子に座ったままの姿勢で 2 時間寝てしまった． 室内の気温低下で目をさます．
• 今日の朗読
  ``Analytical Population Dynamics'' (Royama, 1992)
  Part I Theoretical bases of population dynamics
  Chapter 1 Basic properties and structure of population processes
  • 1.3 Statistical requirements for population persistence
    • 1.3.1 Firest requirement: checking the trend
    • 1.3.2 Random walk in population fluctuations
    • 1.3.3 Second requirement: preventing unbounded deviations
• この節は前に定義された persistence なる概念が 適用できる個体群の統計学的な必要条件を 考察するものである． この必要条件はふたつで 増えたり減ったりのトレンドがなきこと， 時間とともにばらつきが大きくならぬこと のふたつである． まず前者についてはトレンドの大きさが 1/t で時間とともに減じることが必要． Persisitence な個体群は長い目で見れば 成長も衰退もしないのである (しかし有限集団は確率 1 で絶滅するんだけどなぁ)． じゃあランダムウォークみたいなやつなら OK かというと， そうではない． まったくデタラメに動く乱歩では 時間ともにばらつきが大きくなってしまい， やはりこれも前節で考えた persistence の 条件式を満たさない． ということで， 蝋山個体群生態学でいう regulation という 概念が重要になるんだが， それはまた次節．
• 蝋山本， 重要なトコロで面白いんだが， 読みが進まん． なんか夜は不調． 不規則生活疲れか．
• 今日の食卓
  • 朝 (0720): 米 0.5 合． 昨晩の雑炊残り．
  • 昼 (1215): 弁当． 米 0.8 合． ハクサイ・コマツナのキムチふう． ハクサイは一昨日から一日 「キムチ浅漬の素」というのに つけておいたもの． そのハクサイ取り出したあとに残った 「素」に茹でたコマツナ入れて一晩放置． どちらもちょっと塩辛い．
  • 晩 (1910): 米 0.7 合． 豆腐雑炊． 昼のコマツナの残りで味付け．

2001 年 01 月 12 日 (金)

• 0710 起床． 寝たのは 0400 ごろ． どうしてこう不規則なんだろうね． いや規則的にダメなのか．
• 朝飯・弁当の準備． シャワー． ひげそり． 朝飯． コーヒー． ねむい．
• 0805 自宅発． 晴れ． 0822 東京モノレイル流通センター発． 浜松町の気温 5 ℃． 0840 研究所着．
• <鳳翔> のメイリングリスト管理ソフトウェア ezmlm のちょっとしたとらぶる． うー． あ， ヘッダーいじって Mail-Followup-To: ... つけても有効じゃないなあ．
• 京大の長谷川さんが オブジェクト指向スクリプト言語 Ruby による データ解析法 の解説ペイジを公開されている． 勉強になります． もはや Perl などではなく Ruby なんでしょうかね， と Perl のオブジェクト指向プログラミングに イヤ気がさしてきた私は思うのであった．
• どうも この文書 見ると， むしろ Mail-Followup-To ではなく Reply-To を指定すべきなのかな (qmail だと自動的に Mail-Followup-To 付ける と書いてあるし)． メイリングリストのヘッダーに Reply-To 追加するように設定してみよう．
• ようやく終わりの見えつつある 小川モデル推定系自動お絵描き． あ， またややこしくせんといかんのか． 終わりが少し遠のく．
• 昼飯の弁当を食おうとすると， canopymania-ml に名古屋大の (lia32 の作者である) 山本一清さん の投稿． なんとも面白いので勝手ながら転載する (これは上述 ml web site にて過去ログとして公開されてるんだが)．

	魚眼レンズについては、Nikon（カメラ＆デジカメ）の等距離射影と
	Sigma（カメラ）の等立体角射影方式があります。レンズの歪みについ
	ては、Nikonはデジカメは非公開（非守義務契約が必要）で、カメラ用
	についてはレンズに補正表がついていたはずです（今は持っていません
	が）。Sigmaは連絡すれば詳しい内容を教えてくれるはずです（一般公
	開してもかまわないそうです）。

	理論的に天頂角(T)は、等距離射影の場合は
	  T=90*r/R（r:円形部分の中心からの距離、R:円形部分の半径）
	で、等立体角射影では
	  T=2*ArcSin(r/(R*Sqrt(2)))（ArcSin：逆サイン(単位：度））
	で計算できます。

	lia32では、理論的な天頂角と補正データ表から求めた現実の天頂角の
	関係を多項式で近似し、この多項式を使って歪み補正を行っています。
	ちなみに、Nikon 8mmのカメラ用レンズの場合
	T=90.0*f(x)/11.5 (x=11.5*r/R)
	    f(x)=a0+a1*x+a2*x^2......+a10*x^10
	    a[i:0..10]=
	    { 0.00000000000000e+000, 9.12271208543580e-001, 
	    9.42011147828971e-003,  -1.04300794526636e-002, 
	    6.53058821393529e-003,-2.22085050300777e-003,   
	    4.60339214208646e-004,-5.91798786465111e-005, 
	    4.60751025745559e-006,  -1.99047439334084e-007, 
	    3.66511486914382e-009};
	で計算しています。

• どうでもいいんだが， すっかり電気鼠な生活になってしまった．

[電気ネズミ]
粗悪品．どうせ鼠生活
になるんなら，とーや
師匠おススめの光学鼠
にすべきか．

• ぢりぢりと gnuplot & mlfitting --plot 召喚スクリプトを進める． なんかもう 300 行近くまで増殖しちまった．
• メイリングリストのヘッダは Reply-To で良いようである． これに返信すると， もと送信者も一緒に To に並ぶなぁ， と思ってたら， 北大のかとー先生が Mew FAQ の情報を教えてくれた． $HOME/.emacs に

	(setq mew-replyto-to-list '("Reply-To:"))
	(setq mew-replyto-cc-list nil)

を追加すればよいようである．
• それから夕刻までかかって gnuplot を拡張する Perl スクリプトを書く．
• ふう． 何とか動くようになった． 腹減ったし帰るか． 1745 研究所発． 1804 東京モノレイル浜松町発． 1840 帰宅．
• 晩飯食ったあとも， コーヒーなど飲んで gnuplot 拡張 Perl スクリプトの調整．
• しかし真夜中ごろ， ついに眠さに耐え切れず そのまま寝てしまった．
• あ， 今日は朗読できなかった． そして件の Perl スクリプトについても また明日．
• 今日の食卓
  • 朝 (0720): 米 0.5 合． 豆腐． コマツナのキムチの素つけ．
  • 昼 (1230): 弁当． 米 0.8 合． 豆腐． コマツナのキムチの素つけ．
  • 晩 (1930): スパゲッティー． タマネギ・トマト・豆腐ソース． トマトは缶詰ものである．

2001 年 01 月 13 日 (土)

• 1430 起床． うーむ， すごい． 13 時間以上寝てしまった．
• プログラムのバグとりばかりやってると アタマが壊れるので， それを修復するために 長時間寝てしまうのではなかろーか， と以前に考察したことがあった． しかし， そのときは呪われ系の言語である C++ だからこそ そうなるのであって， ケガれ系の Perl では それほどはひどくは壊れないんじゃない， と憶測していた． しかし Perl スクリプトも 長さが 200 行を超えるあたりから 徐々に病毒性を増すのかもしれない． あるいは， わざわざ use strict でケガれないようにしてるのに， use vars で宣言してしまったグローバル変数の 数が 4 コに達した時点で 「健康のためにグローバル変数の増やしすぎは 良いとは言えないかもしれないかもしれない， とゆー仮説がないわけでもないんで， ま， そのあたりは各自の責任で」 といったことを コード中に注記すべき法的義務が生じるのかも．
• それはともかく， 昨日のうちには一応は作動するようになった， 小川モデル推定系の自動お絵描き Perl スクリプトの調整である．
• 10 種類近くの異なるグラフを単一のプログラムに 吐かせる …… いや， どれも似たようなモンだけど． 意外と難しいのである．
• そのスクリプト gnuplot.pl (なんも考えてませんな) の 動作としては， まずこういうファイルを読み込む．

	replace TITLE TREE_NAME
	replace DATA OFR_HOME/output/growth/TREE_NAME
	replace DATA__X 4
	replace DATA__Y 6

	replace MLE DATA.mle
	replace MODEL1_IN DATA
	replace MODEL2_IN DATA
	replace MODEL1_FILE DATA_1.plot
	replace MODEL2_FILE DATA_2.plot
	MODEL1	Osf	0.1
	MODEL2	Osf	1.0
	MODEL1	__X	Dbh
	MODEL2	__X	Dbh
	MODEL1	__Y	4
	MODEL2	__Y	4

	replace XLABEL Dbh
	replace YLABEL Growth
	replace XUNIT (cm)
	replace YUNIT (cm)

	include "OFR_HOME/output/gnuplot/COMMON.gnuplot"

	set logscale x
	set nologscale y
	set yrange [-0.2:2.2]
	set ytics (0.0, 1.0, 2.0)

	plot "DATA" using DATA__X:DATA__Y with points ps 0.5 2 7, \
		"MODEL1_FILE" using MODEL1__X:MODEL1__Y with line lw 1 3, \
		"MODEL2_FILE" using MODEL2__X:MODEL2__Y with line lw 1 1

あなたが重篤な gnuplot 依存症であるならば， 上のほうはごちゃごちゃしてるけど， 下はふつーの gnuplot 用のスクリプトぢゃん． とみるであろう．
• しかし， replace や include ってのはいったいなんなのか． ましてや MODEL は ? なんか解説するのも面倒というより むしろこう冷静にながめてみると 阿呆らしいのだけど， 理系ものぐさ類 Unix 属な ヒトたちに愛されてるというより 惰性だけで使われ続けている 貧弱グラフ描き freeware たる gnuplot を強めるために， この世に形をとってあらわれたのが gnuplot.pl なのである． あーまーど gnuplot． いや， 蛇足 gnuplot か．
• で， 上のようなファイルを読ますと， 小川モデリング対象 24 樹種の全てについて， 例えばこーいうグラフきれっぱしを出す．

[きれっぱし]
ありがちな．

曲線で出してるのが 開空度が 0.1 とか 1.0 なんかのときのモデル成長分布の期待値で， gnuplot.pl が いちいち mlfitting を --plot モードで 召喚して計算させたのである (ケガれ言語で書かれてるくせにナマイキな)． 以前はモデルを変えてパラメーター推定結果も 当然べつモノになったときに， こうやって描画に反映させるのが たいへんだったんですね (変更するたびにテキストエディターで 曲線描画関連ファイルの修正しないと ならんかった)． うう， ただこの一点を修復するためだけに， いったいどれほどの改造がほどこされたのか． いまや plugin_function.so ごとモデルを交換しても gnuplot.pl とうつだけ． ああ， われわれは 戦争には敗れはしたが 戦闘には勝利したのだ (趣旨不明)．
• ついでに， きれっぱしだけばかり何十個も出て来ても ありがたみがまるでないので， これらを A4 用紙数枚の上にきれいに配置する 「型紙」として LaTeX ファイルも同時に生成する． そう， 末期的 gnuplot 依存症者には LaTeX が必要にして不可欠なのである．
• ともあれ， あれこれパラメーター推定結果の 一通りあれこれを俯瞰するための タテ軸・ヨコ軸をあれこれ変えたグラフ， その一形式ごとに 似たような Perl スクリプトを あれこれ用意してたような あれこれと悪しき状況は， これで終わった． ウェリントン公爵が 1815 年ワーテルローで吐いた言葉を， われわれは背筋を伸ばしつつ たまには真に受けてみても良いのであろう． すなわち， 勝利より悲惨な光景は 敗北の中にしかない， と (やはり趣旨不明)．
• どうでもいいが， 室内寒いな． 戸外を歩くときには 東京流刑地は寒いとは思わないが， だからといってここまで 防寒を軽視した構造の住宅は危険ではなかろうか． もしこの集合住宅が大森から札幌あたりに そのまま移転することになったら， どうなるのか． 寒波が襲来するたびに 屋内凍死者が続出するに違いない． そのときは誰が責任をとるのか．
• 移転といえば， 移転がらみで憂鬱になるメイルが昨晩やってきて， これをどう処分じゃない処理しようかで， もてあましているのである． 策が無いので， しばらく放っておく．
• 昨晩コーヒーが切れてしまい， 今日は一滴も飲んでいない． じつは gnuplot ばかりでなく植物の対昆虫防御物質にも 惰性的な嗜癖を有する私は第一京浜を渡渉して マルエツのコーヒー売場に． コーヒーと言ったところで 400g 398 円セイヴィングなる いかにもダイエー系列でございますな豆しか 買えないんだが， いつも手を出す勇気のない相対的に 100 円高い品が 今日は 398! ちかごろ話題のナスダック株価暴落と 連動してるんだろう， とラジオのニュースで聞きかじった知識を 動員しつつ， さっそく一袋買って帰宅． コーヒー汁 (吉田戦車(c)) ポットに128% 充填． 禁断症状を治癒する医療目的で ごくごく飲んでから， ふと正気にかえって時計をみると 2230． また時差が生じそうである．
• …… と防御物質ハイな状態で文章を書くと いつもにも増して へろへろなる文言の羅列となるのである．
• たとえ神経系がドラッグにやられようと， これで今晩は早めに安眠できるとおもったら， へっぽこ間違いを見つけて 0400 まで 修正につぐ修正を重ねたのである． ああ． 時差が．
• 今日の食卓
  • 朝 (1500): スパゲッティー． ソースは昨晩と同じ． この時刻のどこが朝飯か．
  • 昼 (1930): 朝と同じ．
  • 晩 (2230): コーヒーが補充されたので， なんとなくパンケイキを焼いて 食べる．

2001 年 01 月 14 日 (日)

• 1200 起床． 寝たのは 0600 ごろなんだが， 時差をこれ以上拡大しないように， 日曜だというのに目覚しで起床． 眠い．
• さーて， 小川モデル推定系の結果描画の完全自動化は 昨日で終わったんで， つぎは小川式 (森林総研式 1980 年代型か?) 開空度計算方法を 21 世紀の計算機上で 再現してみせる仕事に着手せねばならない． まにあっくなるメイリングリスト canopymania-ml のここ数日間のやりとりのおかげで， 魚眼レンズについては だいたいわかったんで， あとは計算するばかりである．
• …… とてきぱき取り組むことができないのが， 私の私たるゆえんである． えへん． 「早起き」と新しいコトばりあーのおかげで， なかなか着手できない． 結局， 自宅から歩いて数分の図書館に逃走． 1700 時閉館までそこに籠城． ただし本を借りだし (最大 6 冊まで) をやってしまうと， それを読んでそのまま一日が めでたく終わってしまうんで， 何も借りずに撤退．
• ここ数日の失敗を反省して， 晩飯食ってからすぐに朗読に取り組む． 蝋山本第一章の核心部なんで (というかこの第一章はどこも コい内容なんだが)， 読むにもかなりの気合いが必要なのである．
• 今日の朗読
  ``Analytical Population Dynamics'' (Royama, 1992)
  Part I Theoretical bases of population dynamics
  Chapter 1 Basic properties and structure of population processes
  • 1.4 Regulation of populations
  • 1.5 Statistical equilibrium state
    • 1.5.1 Time and ensemble averages
    • 1.5.2 Statationary and ergodicity
    • 1.5.3 Requirements for population persistence under stationary reproductive rates
• …… いやー， たぶんこんなコトどもを言及している 個体群生態学の本はこれをおいて他にあるまい (しかも著者は観測されたデータを解析する 道具としてモデルを開発するヒトなのであり， モデルの数学的性質ばかりを研究してる専門家では ないのである)． 再読してもなかなかに衝撃的である． まず短い第 1.4 節では， 前 1.3 節でランダムウォークが persistence という概念を満たしていない (二次モーメントが発散するから)， という話をうけて， じゃあ， 逆に平均値は時間とともに増加あるいは減少するけど， 分散は一定に収まるような個体群はどうかを 考察している． これは著者の決めた persistence の定義を 満たさないわけだが， 現実の集団ではこれに近いこともあるだろうから， これを regulate された集団， としようと． すなわち， persistent な集団は常に regulate されている， が regulate されてるからといって persistence じゃあない， ということである．
• で， 次の第 1.5 節が第一章前半のヤマ場である． ここまでいろいろと persistence を 規定するような条件式が出てきたんだけど， これらはいずれも定性的であって定量的ではない (これこれの式がある量を満たす， としてそのある量が具体的には与えられて いない)． ところで， 時系列データが定常状態にあるならば， このあたりはもっと定量的になる， という話である． まず時間平均とアンサンブル平均の関係が 述べられる． なにゴトもていねいなる著者の習性でもって アンサンブル平均と空間平均の類似と相違に ついても言及せずにはいられない． つぎにその時系列データが 確率過程の定常状態 (時刻 t ではなく時間 t-t' だけで 統計量が決まるような状態) にあるならば， Birkhoff-Khintchin のエルゴート定理が 成立する， と紹介し， アンサンブル平均と時間平均を同一視してよい 状況を説明する． で， 結局， 定常状態ではそーいう便利な性質があるから， 得られたデータが定常状態にあると 信仰できるならば， その有限のデータから想定してる 確率過程のパラメータが推定できると 保証されますよ， となってしまう． その応用例として， ∞ を含んでいる persistence が成立するかどうかの判定式が， 最後の小節では定常状態のもとにおいて (上のエルゴート定理を援用しつつ) 変形されて具体的な量が与えられるのである．
• ふう． なんともはや． 私としては実際の生態学的な時系列データが 定常状態にあるかどうかは判定できない， と思うんで， 上のような計算が有用になる状況があるか どうかもわからない (すでに読んだヤマネコ・ウサギデータ解析の章では， このあたりの判定式は適用されていない)． 著者はもちろんそんなことはよくよく理解しつつ， どこまでならば計算によって明らかになりうるかを， 示すために persistence という概念を 押していってるのである (というか， 押していけるように persistence という概念が 設計されているのである)． つまり， モデル屋多数派ならばエルゴート定理だのの 数学的道具立てそのものに耽溺し， 私ごとき異端派ならば 「そんなの計算できるか」 と投げてしまうような状況において， 理論と現実の双方を勘案しつつ思考の展開を継続していく バランスが絶妙なのである．
• 掃除． 流し周りはかなり丹念に． 風呂・便所はざっと． 私ごときナマケものとて家事ぐらいやるのである． そう， 住環境の persistence を維持するために．
• その後， 風呂に入り， 晩飯の準備． 炊飯開始． 味噌汁の具に一通り熱が通ったんで， あとは余熱にまかせて買い物に出る． 時刻は 2210． もはや第一京浜むかいのマルエツしか開いていない． ここの野菜はかなり高い．

[ハクサイ半株 250 円]
そこらの八百屋の 2.5 倍．

野菜はやめて， 豆腐 (88 円) やコンニャク (100 円) など買う． あ， トイレットペイパーも忘れてはいかん． 60 m 12 ロール 198 円か． これは安い， というべきだろうな．
• コンニャクなど追加して味噌汁を完成させる． 炊飯終了してる． 晩飯．
• なんか今日はこのまま仕事しないまま 終わってしまいそうである． おっと， 自宅闇ネット経由で外づけ計算機 Mate と ThinkPad の間で同期をとっておかなくては．
• 今日の食卓
  • 朝 (1230): パンケイキ． コーヒー．
  • 昼 (1800): スパゲッティー． 怪しげなトマトソースはこれで終わり．
  • 晩 (2250): 米 0.5 合． ニンジン・タマネギ・切り干しダイコン・ コンニャクの味噌汁． だしは昆布とサバぶし． キムチ浅漬の素につけておいた ハクサイを豆腐 1/4 丁に添える． お， ひさびさに一汁一菜が実現した．

2001 年 01 月 15 日 (月)

• 0700 起床． 昨晩は 0100 ごろまでには寝れた．
• 朝飯・弁当の準備． 朝飯． コーヒー． 洗濯．
• 0743 自宅発． 晴れ． 燃えるゴミ出し． 今日は最低気温が氷点下ということで， 水たまりが凍結していたりする． 0759 東京モノレイル流通センター発． 浜松町の気温 -2 ℃． 急に下がったなぁ． 0820 研究所着．
• 朝一番の仕事として， めんどー感のあるメイルを一時間かけて書く． あて先は九大の矢原さんである． いや， 別に変なこと申しつけられたわけではなくて， 矢原さん的なごく真面目なご提案だったのだが． そしてマジメなことには適性のない私．
• 小川座標系を再検討． なぜか右手系で設定してしまった． ところが毎木調査と POV-Ray (三次元レンダリングソフトウェア) は左手系なんだよね …… そのうち， 全部直さんといかんようになるかも．
• なんとなく， 中村正三郎氏 のペイジに逃避してると， バイオインフォマティックスについての 話題があり …… 「生物学にとっての情報学は 物理にとっての数学みたいなものです」 …… なるほど， さうなのかもしれん．
• 先週， 錯乱状態にあった 「天球上の太陽の軌道」 問題なんだけど， 北半球の場合は たぶん下のように考えれば OK なんだろう．

1. 春分・秋分における 太陽南中の 角度 A を求める． これは 90°- 観測地北緯．
2. 夏至における 太陽南中の 角度 B を求める． これは A + 23.5°．
3. 図のような平行線を 引っ張ると投影された 夏至太陽軌道がわかる．

あとは三角形の相似とか 三角関数とかごちゃごちゃ使うと 計算できちゃうわけだ． やはり面倒だな． 全部， 赤道上のみかけに変換するとラクになるかな． つまり， 上の図で春分・秋分点の南中高度 A が 90° になるような回転ね (反時計方向に 90°- A の回転)．
• 午前中は極座標問題考えて終わった． 昼飯の弁当食う．
• まぁ， すでに極座標クラス Polar というのを 作ってあるからそれを流用して計算してみるかな． えーと手続きとはして以下のようにやってみれば 良いのだろうか．
  1. 方眼間隔 d を決める．
  2. 極座標中心と方眼の (0, 0) を一致させる． 極座標の半径は R で固定．
  3. 方眼上の点 (x0, y0) が以下の変換のあと 最後の条件を満たすかどうか判定する． 条件を満たす点の集合を求める．
  4. 点 (x0, y0) を 半径 R の球面上に投影 (これは観測に用いた魚眼レンズの 形状に依存して決まる)． 角度θとφが出る (x1, y1, z1)．
  5. 角度θとφを y 軸回りに 反時計方向にν回転して θ' と φ' を得る (x2, y2, z2)． これは北緯ν度における観測の場合 (赤道上での 見え方に変換したのである)． Polar.Rotate( const Polar& ) 関数を使う．
  6. このときに 角度θ'とφ' の xyz 座標系の x2 がある範囲に収まってるかを 調べる． 「春分→夏至」ならば (右手座標系で) 0 <= x2 <= R * sin 23.5° である (23.5°は地軸の傾き)．
• これで正木さん (森林総研) が使ったという 「全天写真上に方眼をかけて， 春分→夏至に太陽が通過する領域の方眼点だけ 拾った」 というのを再現してるハズ．
• そうか． 上の手続き 6. では x 座標の値 x2 だけ 見ているわけだから． これだけ計算すればいいんだ． えーと「y 軸回りの回転」というのは y1 == y2 で， と …… ならば， もっと単純に x2 = x1 * cos ν - z1 * sin ν， でいいんじゃないかな． これなら， Polar クラスだとか C++ とか使わないで， Perl だけでも計算できそうだ．
• 魚眼レンズ逆変換のところ (4.) はあらかじめ 数表を作っておけば速いかな． つまり先週の山本一清さんの canopymania-ml 投稿にあったように， これは方眼上の原点となす角度 (→ θ) と原点からの距離 (→ φ) だけで計算できるんで．
• よし． Perl でやってみよう． 図学用語集 によると， 正射影が orthogonal projection で， 等距離射影は equidistant projection かな ?
• ニコンの魚眼レンズ一覧 で気になっていた「対角魚眼」というやつなんだが …… シグマ のペイジで見ると， 写真の対角線が 180°になるようなレンズ (ふつーの魚眼レンズだと四角いフィルムの中に 丸く写る)， というものだとわかった． つまりこのレンズは全天写真撮影には 使われないから考慮しなくてよい． 結局， 開空度調査に使われる魚眼レンズの投影法は 以下の三種類だけであろう．
  • 正射影 orthographic projection
  • 等距離射影 equidistant projection?
  • 等立体角射影 equisolidangle projection
• おおっと， これを書いていたら田中浩さん (森林総研) からメイルが来て，

	ニコンの型式については、8mm F8，
	すなわち等距離射影ということになります．

なるほど等距離射影だったのか． わーい， これで山本一清さんの補正式が使えるぞ．
• 原点からの距離→仰角φに変換する 数値リストを返す関数できた．
• おっと， 広島から郵便． 出張申請書を作らなければならぬ． そう， 月末に広島出張なのである．
• さてと， 方眼復元問題だが …… 座標変換と 方眼間隔を求める問題の 両方を考えなければならない． 同時に着手すると面倒になるので， まずは後者から． そうだな 「半径 1 の円内にちょうど N 個の 格子点が入るような方眼間隔を求めよ」 としてみるか．
• 2000 ごろまで苦闘して， N プラスマイナス 2 ぐらいに 収束するところまではできた． ところがあとちょっとで きちんとはまらない．
• とりあえず撤退するか． 2005 研究所発． 2025 東京モノレイル浜松町発． 野菜など買う． 2105 帰宅．
• 晩飯食ってから， ふと思いついて 「方眼を少しずらしてやると ぴったりする位置が見つかるんじゃ なかろーか」 と思いついて試してみる． つまり， モノがぴったりとはまらない場合， がたがたとゆするじゃないですか． 計算機の中でそれをやるわけです．
• システマティックにずらす方法 思いつかなかったので， 方眼間隔を変えるたびに 0〜方眼間隔の一様乱数を二つ取って 「ずらす」という操作をしてみる． ふーむ． かなり間隔がせまくなっても， 「ずらし」の効果は大きいな．
• 夜中までかかって， まあまあの結果を得る． 不思議なことに， この「ずらし」技術を使うと かならずぴったり N 個となる 方眼間隔と位置が求まるのである． どうやら， この問題の正解はひとつではなく， たくさんなのであり， 今の手法はそのひとつを見つけ出す， というものであるようだ． ま， 実用上はそれでもいい． どうせ実際に使った方眼はわからないんだから．

[収束，かな]
だいたい 100 反復未満で
収束，ということで．横
軸は反復数で縦軸は方眼
間隔．10 回の独立試行．

• あ， もう 2400 すぎている． しょうがないんで， 今日は朗読は中止して， 明日の準備して寝ることにする．
• 今日の食卓
  • 朝 (0715): 米 0.6 合． 昨晩の味噌汁の残りで作った雑炊．
  • 昼 (1220): 弁当． 米 0.8 合． キムチ浅漬の素につけておいた ハクサイを豆腐 1/4 丁に添える．
  • 晩 (2120): 米 0.6 合． 朝と同じ．

2001 年 01 月 16 日 (火)

• 0700 起床． 6 時間ぐらい寝たか．
• 朝飯・弁当の準備． 朝飯． シャワー． コーヒー．
• 0742 自宅発． 晴れ． 0802 東京モノレイル流通センター発． なんか眠いな． 浜松町の気温 0 ℃． 0820 研究所着．
• がさがさ「ゆすって」 ある条件を満たすような方眼点の集合を 探索する Perl スクリプトの修正． つまらんバグがいろいろとある (入出力がらみで)． これは Perl の リファレンス (\ で生成するやつ) と予約語 my の関係を よく理解してないことが原因だった． ローカルに生成したつもりのオブジェクトが ずっと残るわけで …… ちょっと不安な気もするんだが， たしか Perl は使わなくなったオブジェクトを メモリー上から自動削除する機能が 内蔵されてたはずだから， まぁ大丈夫なんだろう．
• がさがさゆする範囲をあまり大きくしないで， 小刻みなものにしてみる． 結果の見てくれが (対称性の点から) 良くなる． ついでに収束も速くなる． さらに方眼間隔の推定値の幅も狭くなる． たぶん今まではゆすりすぎていたんだろう．
• と言っても， 魚眼レンズの視界に投影した場合については まだ計算していなくて， 「半径 1 の円の中にちょうど N 個の方眼が 収まるような方眼間隔 d (と方眼のずらし) の ひとつを求めよ」 という単純化された問題なんだが．
• 昨日つくりかけていたニコン F8 魚眼レンズ補正の 山本近似式の計算を Perl モジュール化する． その計算結果としては こんなもん である (横軸は相対化された写真上天頂からの距離， 縦軸はラジアンで表された仰角)． 青線が理論的な等距離射影で， 赤線が 10 次 (!) 多項式近似による 補正である． 当り前だけど， 補正と言っても小さなものである．
• 午前中はチェック部分を魚眼レンズのそれに 置き換える作業． 試験運転してバグ取りやろうかと思ったけど， やり始めると時間がかかりそうな予感あったので， 昼飯の弁当を食うことにする．
• 午後からバグとり． 動くんだが， どこかで極座標上の計算間違えている． 赤道上なら， うまくいってるんだが．
• …… と思ったら， 甲山さんから熱帯林データ． さっさと小川を何とかしなければ．
• 1455 よーやくにしてそれらしい結果， つまり 太陽軌道掃く領域 → 等距離射影 (ニコン F8 補正つき) → それにかかる方眼， というのが出るようになった．
• 三次元図にして点検しようとすると povray うまく動かん． 新しいものにパッケイジに交換してみる …… 結局， 判明したのは povray-3.1g-1vl2.rpm の PNG ファイル出力はどこか変なところがある， というもの． 出力を PPM に切り替える．
• やー， なかなか楽しそうな絵ができた．

[太陽軌道あーち]
北緯 37 度において春分-
夏至に太陽が通過する領域．
黄色点はモデル上の「光源」
できっちり588 点ある．

• これの解説 web page 準備． だいたい私自身が自分でやったことを すぐに忘れてしまうので．
• 1745 研究所発． 1806 東京モノレイル浜松町発． 京急平和島むこうの ATM で現金を下ろす． なにしろ財布内の残り数百円． 1850 帰宅．
• 晩飯食ったらいきなり 3 時間ほど熟睡してしまった． すでに真夜中． いかんなぁ． しばらくは眠れそうにない．
• しょうがないんで， 解説 web page 作成の続き． いつものごとく， Netscap4.x のだめだめな スタイルシート対応に悩まされる． 0300 ごろ， ひととおりできる．
• (更新情報) 小川モデル開発 のペイジに 「幻の開空度推定方眼を憶測で復元する」 を追加． (20010116)
• ああ， 今日も朗読できなかった． 次の節は長いんで読むほうも 気合いがいるんだよね．
• 今日の食卓
  • 朝 (0710): 米 0.5 合． 雑炊． 昨晩の残り．
  • 昼 (1220): 弁当． 米 0.8 合． ハクサイ浅漬キムチふう． 鶏レバーの煮物． これは昨晩コンヴィニエンスストアーで 買ったもの． 100g 100 円ぐらいだったかな．
  • 晩 (1900): 米 0.7 合． 味噌汁の残りと冷や飯で雑炊．

2001 年 01 月 17 日 (水)

• 0730 起床． 結局， 寝つけたのは 0500 すぎ． まぁ， その前に 3 時間寝たわけだが．
• 朝飯・弁当の準備． コーヒー．
• 0808 自宅発． 晴れ． 0825 東京モノレイル流通センター発． 浜松町の気温 0 ℃． 0840 研究所着．
• 12 日のぎょーむ日誌に乗っている ニコン 8mm F8 魚眼レンズの補正式で， なぜ r/R に 11.5 をかけたり割ったりしてるのか ? という質問を canopymania-ml に投稿したところ， 山本一清さんから回答いただき，

	x = 11.5 * r/R と変換した値を使うのは、Nikon 8mmの場合、円形画像
	の半径が11.5mmであることを前提に補正表が作れれていたからだったと
	思います（今，手元に魚眼レンズのマニュアルがないので、確認できま
	せんが）

ということであった．
• 小川モデル開発と 樹冠まにあなメイリングリストに 「憶測方眼解説ペイジ作りました」 投稿．
• さて， 小川シミュレイター改造に着手． まずは， 天球上の光源分布ファイルを パラメーターファイルからだけでなく， コマンドラインオプションでも 指定できるようにする (evision.h)．
• Evision クラスの SkyWatch 関数に 単一の Eye を与えて全天走査させる 場合も多重定義する． これまで何となく， Eye (の派生クラス) のポインターを Evision にまとめて登録 → まとめて SkyWatch， という手続きにしていた． 今回追加したのは， Forest や Tree で Eye 派生クラスを一個生成 → そのたびに SkyWatch， というものである． どちらがよいだろうか． 試験してみるか．
• 今日はちとやかましいな． しかし年頭の人事異動でうるさい某お役人氏が めでたく御栄転なさったんで (人事院の国家公務員配置転換方針に万歳三唱)， それ以降はずいぶんとマシになった． 一人やかましいのがいると， 周囲もそれに引き込まれるようである．
• ofr2000 を手直ししているうちに， 考えがかわって， 結局「目」の管理は従来どーりとする． 改良作業中断． 元にもどす． ただし， 新関数 SkyWatch( Eye* ) は残す．
• Quadrat クラスに観測点に置くやり方を検討．
• 昼飯を食ってから， 昨日やった計算の数値間違いに気づいた． 「散乱光」モデルの方眼数は 488 点ではなく， 448 点だ． 計算やりなおし． 図も作り直して， 解説ペイジを修正する．
• さて， 小川観測点を小川シミュレイターに組み込む準備． 方針が立たんので， とりあえず xvHtml で解毒してテキスト表にした データシートを BEGIN-END なファイルにしてみる． うーん． 意味無い， かな．
• いや， でもいずれは 5m 方形区には 観測点を置かねばならんし． そうか． 方形区の観測点 Eye は恒久的なものにしてしまう， と． すると， 午前中にごちゃごちゃやってた SkyWatch( Eye* ) が活用できるな． 一方で， 樹木や葉っぱにつけてる一時的な観測点は Evision に渡してしまって用済みになったら 先方におまかせで削除してしまえばよい． そういう使い分けにするか． ややこしいかな．
• やはり明確な方針立たぬまま，
  • 観測点座標
  • 観測点の設置場所の種類
  • 観測値など
  を並べたものを読ませてみることにする． EyeOfr を継承して 新しい Eye を派生しようか． いや， 単に方形区が観測点を持って， さらに観測点が EyeOfr を持たせればよいのか．
• …… とコードを書こうとした瞬間に， 何もかも面倒になってしまったので， EyeOfr から派生して EysObs を作ることにする． いつものごとく， 基底クラスのprivate を protected に変えてしまって public 継承する安易な手法である． なんかそのうち呪われそうだ．
• ついでに EyeOfr (樹木とかに付けるやつ) も ちょっとメンバー変数ふやす． いままで開空度 (らしきもの) を 比率だけで保持していたんだけど， その分子・分母の整数も覚えるようにしてみる． これは役に立つんだろうか．
• ついでに視界内障害物クラス Vit の小川派生版 VitOfr にあった「光減衰」という いんちきな概念をやめてしまう． 光線が当たればゼロ． 完全遮蔽． うん． こちらのほうがいさぎよいです．
• ごちゃごちゃ書いてるうちにまたわからなくなった． 基底クラスの friend 関数は 派生クラスの friend 関数になっているのか ? なってそうな気がするが確信もてない． どうでもいいようだが (最悪でもコンパイルエラー出るだけ)， 気になったんで 短いサンプルコード書いて実験してみる …… なるほど， 派生クラスの friend 関数になっている (in g++)．
• …… などとやってるうちに， また方針転換して派生クラス EyeObs は放棄． その基底クラスだった EyeOfr を ちょびっとだけ機能強化して対応させたほうがよい， とわかった． Firlereader クラスの能力的限界なんかが その原因． BEGIN-END 入力は使わないけど Filereader は使う． これは安直なベタ読みモードで動かす． 小川シミュレイターには観測された開空度を 教えてやらんことにする． シミュレイションの計算結果と観測値の比較は 全部外部でやる． そういうふうにしてみませう．
• FileReader をちょっと改良して， 行頭だけでなく 行中のコメントマークより 後ろも削除するようにしてみる． またまた STL の文字列 string を操作する関数が わからなくなったので， 短いコードで試行錯誤してみる．

	string	line( "abcde#fghijklmn" );
	string::size_type	i( line.find( "#" ) );
	if ( i != string::npos )
		line.erase( line.begin() + i, line.end() );

こんなかんじで良いようである (実行すると line は "abcde" と短く切断される)． Perl なら一行で切断できるのにね． いやいや， STL のおかげで私のような不注意人間でも 文字列が安全に扱えるようになって ありがたいことです， と言うべきか．
• 上のようなちょっとした変更を入れただけで， 呪われコンパイラー g++ は山ほどエラーメッセイジ 出してくれる． この関数に放りこまれた 文字列切断されるんで， どんどんさかのぼって const を消してまわらねばならんのである．
• あちこち細部を調節で終わった． 帰宅しようと思ったら， 見計らったように甲山さんから 論文ドラフトみるようにメイル． なぜかしらん私の名前も入ってしまってるので， 見ないといけない． PDF ファイルをダウンロードして印刷．
• 1755 研究所発． 1806 東京モノレイル浜松町発． 車内でその原稿をざっと読む． 本文 7 ペイジだけの短報である． 1900 帰宅．
• 晩飯食って， メイルをダウンロードすると， 来年度の研究計画を月末までに提出しろ， なる研究所事務局からの無体な通知． 今月末は研究紹介やったり広島に行ったり， とあれこれたて込んでいるのに． 一人で立案する学振なんかの気楽な研休計画と違って 「担当のグループリーダ又は領域長に調整済みの研究計画」 などという脅し文句つきである． つまり北大にお伺いを立てねばならんので， さっさと文案をでっちあげねばなるまい． やれやれ． 腹のたつことに「早急に」などという 不必要にして無意味なせかし文句までついてる (しかも同じ内容の英文の通知にはない ……)．
• 晩飯食うといつものごとく眠くなるが， コーヒーなど飲んでがんばる．
• 今日の朗読
  • どうせ読まねばならん宿題なので， 今日は Royama 本ではなく， Kohyama, Kubo and (Eric) Macklin なる 短いドラフトを繰り返して読む． 律義な Eric 氏がかなり文章を 直したので読みやすい英文， とのこと． たしかにそうかも．
• えーい， 読んで言い回しを参考にするだけでなく， なんかケチをつけねばならんのだが． 数式の展開なんかは 半年前に甲山さんと私でひねくりだしたものだし …… その他はどうかな． そもそも， ひどく極端なモデルを想定して， それの 「あるサイズにおける平均値」 の計算法だもんなぁ． 文部科学省的というか． そしてデータ処理は離散モデルでやって， 正当化は連続モデルでやってる． いいのか． しかしまっとうな離散化はしんどい， とすでにわかっているんで， ほうっておこう． 最後になされている推定もよくわからんものだ． いや， 手法は単なる StatView か何かの直線回帰なんだけど， そんなふうにしてよいという正当化がわからん． しかしやり直すとなると私が 整合性のあるような推定法を考えんといかん． それもたいへんだから ……
• あっ． 阿呆なことぼやいてるうちに気づいてしまった． これはちょっとまずいんじゃないか． 悪くすると自殺点的な． いやいや， ちょっとここは落ち着いて検討してみよう． 事態を見極めなくては ……
• うーむ． 私の勘違いでなければ． おっと， すでに真夜中． こんなこと考えてると， どんどん時差が生じる． そして夜中に考えることは勘違いが混入しやすい． さっさと寝て続きは明朝だ． 寝る前に朝飯・弁当の準備， と．
• 今日の食卓
  • 朝 (0745): 米 0.8 合． ハクサイ・ピーマンの炒めもの． 中華スープの素味．
  • 昼 (1220): 弁当． 米 0.8 合． 朝と同じ．
  • 晩 (1930): スパゲッティー． ソースは朝昼の残りを流用したもの．

2001 年 01 月 18 日 (木)

• 0730 起床． 眠い． 布団にもぐり込んだのは 0030 ごろだったけど， それから例の「自殺点疑惑」について 考え続けてしまい， 0100 すぎにクロと認定． それから 1 時間以上も策を考えていたんだけど …… いやー， 難しいですね． しかも， 言わなきゃたいてい気づかれない， というところが悩ましい． 寝たのは 0300 ごろか．
• 朝飯・弁当の準備． 朝飯． コーヒー．
• 0810 自宅発． 晴れ． 0829 東京モノレイル流通センター発． 浜松町の気温 1 ℃． 0845 研究所着．
• 甲山さんに「ちとまずいです」メイル書く． 30 分以上かかる． つぎに面倒感のある研究計画書の LaTeX ファイルを準備する． とりあえず基本的な設定だけ． 本文は書く気にもならん．
• 小川シミュレイターに固定観測点をおく作業を続ける．
• 北大と怪しげなメイルのやりとり． そうか． 一番大もとの数式からして …… 「強い仮定」に汚染されている．
• 午前中は小川の改良進まず， メイル書きとごまかし策を考えることに 費されてしまった． 腹減った． 昼飯．
• fj.editor.vi より． なんと vi の置換 (s) の区切りは / でなくてもよいのか． :%s:aaa:bbb:g (ファイル全体の aaa を bbb に置換) てなことも OK なわけだ (区切り文字は何でも良いらしい)．
• 昼からはココロ静かに， 観測点を小川シミュレイターに設置する準備作業． STL なコンパイルは時間かかる．
• ときどき北大からメイルが来信． 破綻してるところに関してはごまかしはやめて 有用そうな conjecture ですと言う路線を提案． 甲山予想， とでもいうのかしらん． フェルマーのそれに比べれば ぐっと易しいんだが …… 私にはとても証明できそうにない．
• 森林から方形区管理者を呼び出し， 方形区管理者から方形区を呼び出し， そこに観測点を設置して …… という経路を作っていく．
• 北日本某大学の先生からよくわからぬメイル．

	なにをおっしゃる．日記の，どんどん深みにはまる小川進化過程
	を問題創造型人間の営みと呼ばずに何と呼ぶんじゃね．

まぬけなことに， しばらくたってから， ようやくこれがイヤミだと気づいた (送信者はイヤミ嫌疑を否認中)．
• ともあれ， 新しいバグを生成するためにコード改良に取り組む …… 1645 ひととーりコンパイルできた． しかし， 挙動が少し変．
• 以前から脆弱だったコマンドラインオプション 処理をちょっといじったんで， それが壊れてしまったようである． やれやれ． まさに問題創造．
• その点は無視して， イキオイで観測点の生成・出力関係の 関数を仕上げていく． これでデータファイル読み込んで初期化するところから 最後に出力するところまでは書き上がった． コンパイラー通るようにする．
• 空腹になったんで， いったん撤退するか． 1800 研究所発． 1816 東京モノレイル浜松町発． 1850 帰宅．
• 晩飯食ったら， 一瞬にして寝てしまった． 「自殺点疑惑」に前夜の睡眠時間を削られたためか， はたまた C++ な呪いか． 目をさますと 2300． うう． もはや， ぢたばたしません． 風呂でも入ろうかな．
• 風呂に入ってから， 電気代払いにいく． 一月ぶん 4863 円． セラミックファンヒーターを使ってるせいで 高くなっている．
• 夕方に呪われていた C++ コードに取り組む． Ethernet Lan カードを浜松町に置き忘れてきたんで， 自宅外づけ計算機 Mate と接続できない． あー， もう起動しちゃったじゃないか． しょうがないんで， キーボードだけ接続． 例によって頭の中にディスプレイを想像しつつ， shutdown 処理 (…… って， じつは root でログインして !sh するだけなんですが)．
• バグ狩り． あやしいところを追跡しつつ 頭の中でプログラムを実行 …… してるうちに， 引数処理の自作ライブラリーに ちょっと手を加えたときに 間違いが混入したのが原因， と判明． 文字列 " false" と書くべきところが "false" となっていた． こういう脆弱なコード作法はいかんなぁ． 真偽値についてはできるだけ bool 型を使うようにしてるけど， ここは文字列を使わないと ダメなところなのである．
• あ． もう 0300 すぎ． もう寝るかな． 待て， まだ明日の飯の準備してない． なんか帰宅後の時間の使いかたがむちゃくちゃなんで， なかなか「今日の朗読」が進まない． こーいうのはトレイニングなんだから， 毎日続けんといかんとおもうんだが．
• 今日の食卓
  • 朝 (0740): 米 0.6 合． 一昨日の鶏レバーの残り． タマネギ・ピーマン・ネギ・卵の炒めもの．
  • 昼 (1220): 弁当． 米 0.7 合． タマネギ・ピーマン・ネギ・卵の炒めもの．
  • 晩 (1920): 米 0.7 合． 雑炊． 朝昼の残りを流用．

2001 年 01 月 19 日 (金)

• 0800 起床． 4 時間ぐらい寝たか． その前に 3 時間寝てるんで， まあ， なんとか．
• 朝飯・弁当の準備． 朝飯． 時間ないな．
• 0813 自宅発． 晴れ． 0829 東京モノレイル流通センター発． 浜松町の気温 2 ℃． 今日か明日に自宅用の Ethernet LAN PC カード 購入を決意してるので， ちょうど 0845 から稼働している 浜松町の ATM でお金下ろす． 0850 研究所着．
• やっぱりまだ不具合の取れていない引数処理の 修復に取り組む．
• バグとは直接関係ないんだが， (他ならぬ自分で作った) Filereader クラスにあった， ExsitsMapVectorUnival という呪われた関数名を ExsitsKey と改める． いったい何を考えて命名したのか． SetMapVectorUnival とゆーのもあったので AddNewLine と改名． private な属性の関数であるなら 前者みたいなやつでも許容できるが， これは protected 属性なのである．
• バグはなかなか取れないけど， へっぽこコーディングは推敲されていく． ありがちなことである． う． 先日， むやみと const を外したことによって， 良からぬコトが生じている， と判明． よく考えて改造しなくては．
• コマンドラインオプションに関係するバグを取り， 観測点ファイルの読み込みができるようになる． ちょっと試しに実行してみると …… なんかやけに時間かかるな． そうか， いままで天球上の「光源」は 100 点ぐらいだったのに， 小川測定法だと 448 点とか 588 点とかになるんで， 時間かかってしまうんだ．
• 新しく --no_eye_tree モードというのを作って 対応する． これで動かすと， 地上におかれた観測点だけに「目」が付与されて， (24ha で計算する場合は) 20000 本からなる 樹木には目は持たなくなる (当然， 開空度の計算やらない)．
• だいたい動くようになってきたんだが …… なんかヘンだな ? 固定観測点で調べた開空度って， いつも同じ分布になってる． ちょっと三次元図に描いてみよう …… ああ． わかった． 「表皮」だけで表現されている地形， それよりずっと下の法に 263 個の観測点が 浮遊している． シュールですなあ．
• 観測点に地標高を加えて …… あれ， ちゃんと地面の上に表示されているけど， 位置関係変だな …… 最初のデータ変換から たどっでわかったことは， なんと座標系が逆． うーん． どこかにメモしといたはずなのに． 危ない危ない．
• なんとか観測点を表示．

[小川こあぷろっと]
6ha 中の 1.2 ha に
シードトラップや全
天写真撮影点などな
どが設置されていま
す．263 点．

• さーてカンジンの開空度はどうか． 三次元モデルの中で計算した値と， 写真から読まれたそれ， は …… うーん， まあ， 樹冠の形とかてきとーなんで， モデルの中のほうが数倍明るいな．
• 「閉鎖林冠下」 という生態学なコトバがあるけれど …… ホントに林冠の下ってのは 暗いものらしい， と実感． 樹冠を構成する「球」の 密度を高くしたり， サイズを変えてみたりする．
• 行き当たりばったりな調節試行ながらも， だんだん観測値に近づいてくる． この合ってない部分は …… 谷底部分にあるギャップ周辺か． 実際には「暗い」はずなんだが， モデルではずいぶんと「明るい」 (といっても空隙率 0.1-0.2 ぐらいだけど) と評価されている．
• モデル森林の三次元図を描いて 上から俯瞰してみる． うん， ぽっかりと大穴が開いてるよな， このあたり． さて， どうしよう．
• まあ， それ以外は思ったほどは悪くない． パラメーター調節で何とかなる 範囲とは言える． その前に考えんといかんのは， この計算法のもとで合わせてしまっていいのか， ということだ．
• 今日はここまで． 1800 研究所発． 1814 東京モノレイル浜松町発． 1900 帰宅．
• 晩飯食ってから， お茶など飲みつつでれでれとする．
• Unix 用の描画ソフトウェアとして Tpng というのが最も普及している． ところでグラフ描き Gnuplot には 出力形式がいろいろとあるんだけど， Tpng もまたそのひとつである． 近ごろ Gnuplot だけでなく Tpng はっきんぐも やっっておられる北大某院生から質問メイル． えー? Tpng 出力の線の太さを変えたい? これは難問ですなぁ．
• しょうがないんで， まず Tpng でいろいろな太さの線を描いて， ファイルに保存． ありがたいことに， Tpng は描画データをことごとく テキストファイルとして保存しているので， 容易に中を見られる．

	poly('black','',2,[
		50,100,250,100],0,1,1,0,0,0,0,0,0,0,0,'1',0,0,
	    "0","",[
	    0,8,3,0,'8','3','0'],[0,8,3,0,'8','3','0'],[
	]).

	poly('black','',2,[
		50,120,250,120],0,2,1,2,0,0,0,0,0,0,0,'2',0,0,
	    "0","",[
	    0,10,4,0,'10','4','0'],[0,10,4,0,'10','4','0'],[
	]).

…… というふうに． これは二本の平行な水平の線分で， 上が太さ 1， 下は 2 である．
• 憶測するに， ...,[50,100,250,100],0,1, ... [x0, y0, x1, y1] という 始点終点の座標であり， その次の次の 1 というのが線分の太さを 表してるらしい．
• この値を変える実験してみるとたしかにそうなっていた． Perl の正規表現を用いた置換で， これを変えるしかないんじゃないですかね． 他にも Gunuplot 実験などやってみて， そういう趣旨の回答メイルを送信．
• 今日の朗読
  ``Analytical Population Dynamics'' (Royama, 1992)
  Part I Theoretical bases of population dynamics
  Chapter 1 Basic properties and structure of population processes
  • 1.6 Ecological mechanism underlying population regulation
• …… とゆーのを読みはじめたんだが， この節は長ったらしいだけでなく， 読みながらいろいろと考えさせられる， まぁ， かなり面白い内容だったんで， 一日で終わらなかった． 報告はまとめて明日， ということで．
• というか， このぎょーむ日誌は 翌日の夕方に書いているのである．
• 今日の食卓
  • 朝 (0805): 米 0.5 合． ネギ・ハクサイ浅漬キムチを炒めたもの．
  • 昼 (1245): 弁当． 米 0.8 合． ネギ・ハクサイ浅漬キムチを炒めたもの．
  • 晩 (1930): 米 0.6 合． 豆腐・タマネギ・ニンニクの茎のカレー．

2001 年 01 月 20 日 (土)

• 1200 起床．
• ふと思いついて， 炊飯器でパンケイキを焼いてみる．

[炊飯器で焼いたパンケイキ]
一時間以上かけたんだが
…… はっきり言ってお
いしくない．中まで火が
通ってないのである．

不精して， いっぺんにたくさん焼こうとしたのが 敗因だな． リリエンタール (19 世紀のドイツのグライダー研究家) 曰く「進歩には犠牲がつきものである」．
• 夕方まで， 三次元開空度計算法の改良案を考える． 昨日， 小川データを使った計算をやっていて 「こりゃあ， そろそろ改造したほうが良いかな」 という必要性を感じたため．
• 今のところ， 小川モデルにおいては障害物オブジェクトの Voxel 化において 1m 立方のモノを使っているんだが (地形は別の取り扱いになるんで 5m × 5m × 1m)， このサイズだと樹冠の葉群を表すには小さく， 一方で幹を表すには幅が広く高さが足りないのである．
• 現在の Voxel 化のやり方の限界は 以前からウスウス感じていたので， 先月中ごろに行ったライブラリー大改造においては， 将来の改良を考慮した設計になっているのである． というか， そのための大改造だったのである． そのときの図をもう一度引用すると ……

• この Vit なるものが， いまのところは 1m 立方のソリッドな Voxel として 実現している VitFoliage なるカタチを与えられて 計算に使われている． まあ， なんか具体的なモノ， というかんぢですよね． しかしながら， この図を最初に紹介したときに書いていたように， Vit はもっと抽象的なオブジェクトであっても 差し支えないのである． たとえば 「林内のとある 5m 立方 Voxel の中に存在する 三次元オブジェクトの簡単なデータベイス」 みたいな．
• つまり， これまで PipeTree や小川モデルの開空度計算で 特徴的であった，
  • 細かい Voxel を集めてオブジェクトを表現．
  • それを必要最小限のメモリーに格納して 効率良く検索する Voxelmap すなわち map<Grid, Vit*>．
  というのはヤメにして， 代わりに，
  • 大きめの Voxel をとり， その中に障害物オブジェクトの 詳細情報を格納する．
  • 相対的に個数の少なくなった Voxel を 最も高速に検索できる Voxelarray すなわち vector<Vit*> (まだ作ってない)．
  というふうに切り替えたほうが良さそうだ． 少なくとも小川モデルに関しては．
• 後者に切り替えたばあい， 最大の問題は計算時間の増大だろう． いままで整数計算によって高速化が実現していた． しかし Voxelarray を構成する Voxel 数はそんなに多くないので (おそらく現在のものに比べると 100 分の 1 未満になる)， Bresenham だのといったアルゴリズムを使っても 対して速くなるわけではない． その代わり浮動小数点計算の量はかなり増えるはずで， これを抑えるところがカギになりそうだ．
• どうせ今月中は もはやのんびりとコーディングしてるヒマなさそうだけど， 上の構想がそもそも成立しうるかどうか， いくつかのオブジェクトに関して 「視線とぶつかってるかどうか， の当たり判定法」 に関して 計算回数を最小限にするにはどうしたらいいか， 図を描きながらあれこれと考えてみた．
• そのうちちゃんとした解説ペイジとか作るかもしれないけど， 球・ ポリゴン (三次元空間にうかぶ三角形のコト)・ 円柱についての計算法はこんなふうになるか， と思えた． 忘れんようにちょっとメモ書き．
  • 球：これは視点から視線方向・障害物方向の 内積を取り (cosθを計算)， あと視点・障害物間の距離 R が分かればよい． R sinθ (実際には R²(1 - cos²θ)) が r (同じく r²) より大きいか小さいか判定． これで視線上に球がひっかかってるかわかる．
  • ポリゴン：これは視点から 3 頂点へのヴェクトルを 並べた 3x3 行列 V の逆行列を計算して 視線ヴェクトルにかけたときに， 出てくるヴェクトルの要素が 全部正なら「当たり」 (のはず，要再検討)． 3x3 の逆行列計算にはベタ書きした数式を使うと， 9 要素 + 3 行列式． 行列の積の計算 3 行と正負判定 3 回， か． 家庭用ゲイム機用三次元ゲイムで なぜ三角ポリゴン多用されるのか理由が わかったような気がする． 三角関数とか使わない一次三元連立方程式の計算に 帰着できるからだ， たぶん．
  • 円柱：視線上に円柱あるかどうかを判定するのは 難しそうだけど， 竹中明夫さん (環境研) に教えてもらった 方法使うと比較的計算量少なくてすみそう． 私の憶測も交えつつその方法を説明すると； 円柱を (0,0,0) を起点とする 極座標ヴェクトルで表現しておいて， その方位角・仰角ぶんだけ視点を逆回転 (自作の Polar.Roate() 関数使うとよけーな計算増えそうだな)． 円柱 (樹木の幹) 直立してるとすれば楽なんだが， 将来的には斜めに伸びるイヌブナとか 計算するかもしれんから， マジメに回転すべきなんだろう． これで標的の円柱が z=0 の X-Y 平面上に の見かけに変換されるんで， 変換された視線の X-Y 平面上での交点求める． あとはその (x,y) が円柱の X-Y 射影 (長方形の領域) に入ってるかの大小判定 4 回．
• …… とゆーような計算を， 視線にそって視点を 5m とか 10m ずつ動かしながら， 周囲の Voxel にらみつつやっていくわけだ． あ， やっぱりたいへんそう． しかし従来方式ではやはりスケイラビリティなるものに 欠けるところがある， と言わざるを得ないので， そのへんに関しては今考えてるやつのほうがマシである．
• 夜になってから昼飯と称する食事を終えてから， 急に怠惰になって久しぶりに 4 時間ほど Nethack に没入． おそるべき時間浪費ゲイムである． 今回はペットを「変化の杖」で かなり強いモンスターに変えたところ， ヒトの弱味につけこむ 憎むべき強欲な店主たちを次々に殺戮してくれるんで (しかもそのことによって自分の評価は下がらない， ペットが勝手にやったことだから)， ついつい長時間遊んでしまった．
• 真夜中近くに晩飯を食ってると， いきなり右上小臼歯の一部が欠けてしまった． どうやら以前から虫歯だったようである． うーむ． 近ごろは痛まないから直ったのかと錯覚してたんだが， 実は悪化してたんだなぁ． とほほ．
• 鏡でみると …… ああ， なんということか． 歯の 10% ぐらいが欠落して 「あれがエナメル質， こちらは象牙質，セメント質 ……」 と解説できるぐらいでかい断面が露出してしまっている． けっこうショッキング．
• 冷たい水とかに触れないかぎりは痛まないんだけど， 気になるんで明日歯医者に行こう． 電話帳とネットを検索して， 日曜日でも診療してくれる歯医者を探す． 大田区内で 3 件ほどみつかったんで， まぁ， なんとかなるだろう． だめなら明後日でもいいや．
• 今日の朗読
  ``Analytical Population Dynamics'' (Royama, 1992)
  Part I Theoretical bases of population dynamics
  Chapter 1 Basic properties and structure of population processes
  • 1.6 Ecological mechanism underlying population regulation
    • 1.6.1 Feasibility and robustness of population regulation
    • 1.6.2 Density-dependent and density-independent factors
    • 1.6.3 Effect of ecological factors and process structure
    • 1.6.4 Fragile regulation by a pure density-independent process
    • 1.6.5 Robust regulation by a density-dependent process
    • 1.6.6 Examples of fragile and robust regulation
    • 1.6.7 Negative correlation between reproductive rate and density in a persistent population
• 蝋山本第一章の実に三分の一 (15 ペイジ) を占拠している 第 1.6 節である． 集団の密度変化の性質を表す語として persistence だの regulated だのと出て来て， ここでは robust というのが登場する． これは外部からの擾乱に対してなお persitence を 維持する性質で， robust じゃないやつは fragile となる． この後のながーい解説を 思いっきりはしょって まとめると； 集団密度に無関係な density-independent な 要素だけで変化してる集団は persistence になりうるけれど， 外からノイズが入ったときにどんどんばらつくので robust にはなりえない． それに対して 密度にたいして再生産速度が負の相関もつような density-dependent な機構をもつ個体群動態は robust になりうる． ただしこれは必要条件であって …… と感動的なまでに論理的で偏執的な著者は 第一章の残りの部分で このあたりをツメていく予定なのである．
• このあたりで解説されてることはまさにこの本の独壇場． 古今独歩， というやつか． ただし本を開いていきなりこの第一章を読んでしまった 生態学者はかなりつらいキモチになるだろう． 私が先に読んだようなヤマネコ・ウサギ話などを 見ておかないと， 何でこんなことばっかりやってるのか， ありがたみがわかりにくいのではないかと思う． 具体的な描像が頭の中にあると， 読んでいてなかなか興奮させられるんだけどね．
• しかし朗読するのは苦しい長丁場でした． 英語でたくさんの数式読みあげていくと 頭がヘンになりそう． いんてぐらるふろむ …… ふぁんくしょんおぶえっくすさぶてぃーぷらすわん …… いずいくぉーるとぅ ……
• ああ， 明日は歯医者か．
• 今日の食卓
  • 朝 (1320): 炊飯器で焼いたパンケイキ． 失敗作． コーヒー．
  • 昼 (1930): 米 0.5 合． 豆腐・タマネギ・ニンニクの茎のカレー．
  • 晩 (2340): 米 0.5 合． 豆腐・タマネギ・ニンニクの茎のカレー．