ぎょーむ日誌 2001-05-29

2001 年 05 月 29 日 (火)

• 0600 起床． 寝たのは 2330 ごろ．
• あ， 飯たくの忘れてた． 弁当用の飯だけ炊飯． 朝食はそうめんとする． 朝飯・弁当の準備． 朝飯． シャワー． コーヒー．
• 0700 自宅発． 晴れ． 特急に乗って 0709 京急平和島発． 普通に乗り換えて 0733 京急上大岡発． 0750 研究所着．
• 独房群図書室の今日のろーどく
  Simon Levin の生態系・多様性・進化・複雑系の 一般向け解説本 ``Fragile Dominion''
  Chapter 3. Six Fundamental Questions
  • Question 2: Are These Patterns Uniquely Determined by Local Environment, or Has History Played a Role (-p.46)
  • Question 3: How Do Ecosystems Assemble Themselves? (-p.48)
• ここでは第 2 と 第 3 の問いを概観． まず生態系で見られるさまざまなパターン ―― 高温多湿→熱帯林とか Serengeti の水牛の群の形状などは 局所的な物理環境で決まってるのか， はたまたシステムそれ自身にパターン形成の機構が 内包されているのか? という問いが発せられる． 後者は歴史的・進化的視点である， とする． つぎにもし地球上に N 種の生き物がいれば 2^N 種類の 群集 (community, 複数種から構成される生物集団) が生成されうる． N はたいへんな数だから 2^N は さらに莫大な数になりうるのだけど， 実際のところ群集の種類はそんなに多いとはいえまい …… ということで， さきほどのシステムそれ自身が有する 自律的な機構について言及される．
• 昨日の core 吐きエラー直しの続き． 三次元実存 Vit は仮想メンバー関数持っているので， 仮想デストラクターを持っているわけなんだが …… このデストラクターまわりがヘンだ． 動作をみると派生側のデストラクターが 呼び出されて， 次に基底側のそれが呼ばれる …… 問題ないはずだ． しかしなぜかもういっぺん基底側の デストラクターが動作して …… core を吐く． うーん， さすがわ呪われ言語 C++．
• では Vit の派生クラス VitSphere を生成している 試験運転コードで VitSphere ではなく， VitSphere* (ポインター) を生成してやると …… おおお， 派生デストラクターがいっぺん呼ばれたのに 続いて基底クラスのデストラクターが 無限回 呼び出されている． これはおそらく基底側デストラクターが 自分自身を呼ぶような仕組みになってるようだ． なんだこりゃあ． そんなこと書いてないぞ．
• 仮想デストラクターって何も難しいことは ないはずなんだが …… うーん， 原因わからん．
• なるほど， 試験運転コードの中で生成した VitSphere を三次元虚業ライブラリーに つっこんだりしないで， その場で生成・消滅させれば， 問題なく派生→基底の順で 一度ずつデストラクターが呼び出されて めでたく終了するな． ということで， 虚業ライブラリーの中で delete vit してるところ， すなわち， 三次元分譲地 Voxel のデストラクターに問題ありのようだ．
• 英国からもどられた甲山さんよりメイル． 明後日の岐阜での会議 (私はその会議不参加) の準備で多忙であるようなので， しばらくは計算発注ないだろう． ともかく来週というか今週末からの 札幌出張準備をススめておくか． 来週中には Pasoh 関係は ひととーりまとめなくてはいけない． 間に合うのか．
• 1100 仮想デストラクター問題， 解決した …… いや， 正確に言うとエラーは出なくなった． 原因がよくわからない． たぶん， 試験運転コードの最後で 暗黙のデストラクター呼ぶのと， 明示的に delete でデストラクターが呼ぶ 順番がかかわっていそうに思えるんだが …… うーむ?
• ともかく現象としては， VitSphere* としてオブジェクトを new で生成して， 使っているとエラー出ないようにしてしまった．
• こういういいかげんな対応では， もうちょっと面倒な試験をやったらエラー出そうだ． 続けてみよう．
• 1115 空がごろごろと音を立ててると思ったら， いきなりどしゃ降り． ついさっきまで晴れていたのに．
• 「一時的」という属性あたえられた Vit だけを削除する Fvision::ClearReset() 試験． とりあえずまたエラーは出ない． さてさて …… やはり問題点は利用側で生成したオブジェクトを ライブラリ側で delete してよいかどーか， という問題だな．
• 利用側で new で生成しておいて， あとはほっとく (利用側で最後に delete してもしなくてもよい)， という使いかたできるんで， 実用上は問題なさそうなんだが． なんかすっきりせんなあ． 関数名を Fvision::ClearEyesTmpVits() と変えて， ごまかした気分になってみる．
• いままで「視線」Gaze クラスのインスタンスに 割り振る ID は最上級中間管理職の Fvison で 番号管理してたんだけど， これを Gaze 内部でできるようにする． 静的 (static) なメンバー変数 というのを使えばよく

	class Gaze
	{
	private:
		static GazeId	current_id;
	protected:
		const GazeId	NewId( void ) { ....; return current_id++; }
		...
	};

などというふうにしておく． この current_id を初期化してやるために， 2 行だけの短いコード gaze.cc を 書くことになってしまった．

	#include	"gaze.h"
	GazeId	Gaze::current_id( 0 );

このように static メンバー変数は *.cc なファイルで初期化を書いてやって， コンパイルしないとならない． というのも， それも知らなくてヘッダーファイルで初期化してたら， 多重定義うんぬんという多量のエラーメッセイジに やられてしまった．
• 時刻は 1230． 昼飯にしますかね．
• 東京めたりっく通信経営危機 か． 当家の ADSL 回線どうなっちまうんだろうね． NTT に金を払うのはイヤだしなぁ．
• 15 分間で昼飯を食いつつ 東京めたりっくの暗澹たる未来を憂えたのち， 呪われコーディングと試験運転作業を再開する． なんか時間がぜんぜん足りないような気がしてきた． というのも， この先いくつぐらいバグが出て来て， それらがどれぐらい呪われているのか 全く見当がつかなくないからである．
• なぜかよゆーあるらしい甲山さんから 「出張後の土日に山でも」のお誘い． 6/19 には Princeton ですぜ． そもそも 当方の足がそれまでに回復してるかどうか．
• 1340, RegistVit() するとヘンな座標に置かれる， という問題解決． VitSphere→Vit と継承してるんだけど， そのコンストラクターにおける 初期化の問題であった． 呪われ言語め．
• 次の問題は三次元内のこいつの位置を 探索できていない， という …… うん． すごい結果だ． 1m 離れたところにある 半径 50cm のタマの真ん中を貫通してるはずが …… 1e+06 m ってのはつまり， 1000 Km ほどあさっての方向に すっとんでいるわけね．
• これは呪われ言語の問題ではなく， 単純な計算間違いだろう． やれやれ．
• 正気で書いたとは思えぬマヌケな計算間違いに満ちた EyeTest::CheckHit( Vit* ) 関数を直す …… よーやく， 「目」の前のマトには当たるようになった． 時刻は 1415．
• おおおお， 都立大からセミナー依頼 …… 7 月中ごろね． たぶん大丈夫でしょう． 諸方に感謝しつつ， うけたまわりますの返信．
• 多忙と時差にやられているはずの 甲山さんから計算発注． 樹冠の形状をさっさと決めてしまえ， か． うーむ， この三次元虚業ライブラリの出来次第． あと， いつものごとく胸高断面積と呼ばれる 不思議な数量の計算発注も． それは喫茶店で 酔っぱらいが焼酎頼むようなもんですよ． 出しますけどね．
• う， メイルやりとり始めると とたんに試験運転のほうが止まってしまう．
• 虚業ライブラリで中間管理職的な周旋業の 計算手間を減ずるリストラ． メンバー関数一個けずって一個追加． 運転試験． よしうまくいった． ちょーど 1730． ふう．
• 「改良しとかんといかん」 と思ってた点はこれで ひととーり， なんとかなったか． いやもうちょい残ってるな． 三次元実存にぶつかったときに 視点をどこまで移動するか， とか． 視点の終端処理． しかしこれはライブラリ側の仕事ではないんだな (何しろ虚業なので)．
• いったん撤退して接骨院にでも寄るか． rsync その他でファイルの同期をとる． 1740 研究所発． 雨はすでにやんでいる．
• 1745 新杉田接骨院着． 1755 から診療． 今日も 100mA の電流びりびり 13 分間流す． 腫れ上がって幼児の足のようにふくらんでる 私のまぬけな右足も ホネ医者先生がごりごりとマッサージすると 普通サイズにもどる． 自分でもマッサージやってみるべきか．
• 1810 同発． 普通に乗って 1820 京急杉田発． 快特に乗り換えて 1830 京急上大岡発． 普通に乗って 1850 京急川崎発． 1920 帰宅．
• 帰りの電車の中で三次元問題あれこれ考える． 待ち時間も含めて京急路線上で毎日 80 分ぐらい すごしてるんだけど， 何も見ないでアタマを使うにはよい場所である (というか， 他に何もできない)．
• いま使ってる方式は， 該当ソースファイルのコメント部から引用すると，

	bool VitSphere::CheckHit( Gaze* gaze )
	{
		//  view_point
		//    o------------------------> view_direction (v)
		//     \)theta |
		//      \      | distance = diff_xyz.SquareScalar()
		//       \     |
		//        \    | r = distance * sin( theta )
		//         \   |   = distance * ( 1 - cos( theta )^2  )
		// diff_xyz \  |   = distance
		//           \ |     - ( diff_xyz . view_direction )^2 / ( v . v )
		//            \|     	
		//             X
		//	location (center of the sphere)
		...

とゆーふうに三角関数使ったものなんだよね． 内積とか計算して ( sinθ )² を計算している．
• これでもいいけど 「最接近点」求めるのが面倒． というのもθが 0.5π 超えることだってあるのだ．
• で， 電車の中で思い出そうとしてたのは， 以前に 竹中さん から教えていただいたやり方だ． たしか「直線をパラメトリック表示して……」 とか言ってたような ……
• 窓の外をぼーっとながめつつ憶測した結果．

	視点 O(x0, y0, z0) と視線ヴェクトルの成分は (a, b, c)．
	「視線」の式をパラメトリックというんだから，

		t = ( x - x0 ) / a = ( y - y0 ) / b = ( z - z0 ) / c

	とか書いて，

		x = a * t + x0
		y = b * t + y0
		z = c * t + z0

	とするんだろう．つぎに球の中心 (xs, ys, zs) を通り，
	法線ヴェクトルが (a, b, c) の平面は

		a ( x - xs ) + b ( y - ys ) + c ( z - zs ) = 0

	となるから，上の式の ( x, y, z ) に「パラメトリック」表示
	の式を代入すると …… えーと 

		a ( a * t + x0 - xs ) + b ( b * t + y0 - ys )
			+ c ( c * t + z0 - zs ) = 0

	となって，直線と平面の交点P (これが最接近点) を表す t である
	tp は

		tp = ( a ( xs - x0 ) + b ( ys - y0 ) + c ( zs - z0 ) )
			/ ( a * a + b * b + c * c )

	であとは xp = a * tp + x0 というふうに (xp, yp, zp) が
	計算できる，と．

たぶん， これであってそうだ． たしかにこっちのほうが簡単か (このあと最接近点 P と 球中心 S の距離を 計算せんといかんが)． アタマの中で簡単に取り扱えるような数値例を作ってみる． とくに破綻なさそう．
• しかし帰宅するとどうもコード書く気になれん． というのも， これでもし熱中してしまうと際限なく 夜更ししてしまうためである．
• 「ぎょーむ日誌」などうだうだ書いてないで， さっさと寝てしまうか．
• 今日の食卓
  • 朝 (0620): 朝用の飯炊き忘れていたのでそうめん．
  • 昼 (1235): 弁当． 米 0.7 合． キャベツ・タマネギ・ニンジンの炒めもの． 味つけは麺つゆ・さばぶし．
  • 晩 (1950): 米 0.6 合． 昼の残りの卵とじ． 卵が余っている．