「ぎょーむ日誌」目次に戻る
|
KuboWeb top に戻る
|
twilog
|
atom
ぎょーむ日誌 2001-09-07
苦情・お叱りは, たいへんお手数かけて恐縮ですが, 久保 (
kubo@ees.hokudai.ac.jp
) までお知らせください.
本日
(
kubolog20010907
) |
次の日
|
1 日前
|
7 日前
|
31 日前
|
365 日前
|
top
2001 年 09 月 07 日 (金)
0710 起床. 眠い. やはり今週は夏休みの残りのうち 1 日を使うべきだったか.
朝飯・弁当の準備. 朝飯. シャワー.
0745 自宅発. くもり. 特急に乗って 0754 京急平和島発. 普通に乗り換えて 0820 京急上大岡発. 0835 研究所着.
なかなか仕事に着手できん.
葉群の上にとりつけた光センサー「目」に映る障害物である 三角形 VitTriangle たちを三次元虚業ライブラリの 総合窓口を経由して三次元区画 Voxels に登録しようとするんだが …… なぜかうまくいかない.
これもしょーもないミスで VitTriangle の複数ある コンストラクターの挙動に矛盾があったためであった. うーん, バテてるのか?
さて開空度らしき数量の計算結果なんだが …… なぜか多くの場所でとても暗い数値が出てる. これってまだ単木的な状況だよ? 変だ変だ.
しょうがないから, また「視線」を描画してみるか …… という試験の準備. 動作試験もだんだんたいへんになってきた.
というあたりで早くも午前が終ってしまった. いかんなぁ. 昼休みつつ弁当食う.
Yahoo! オークションに出してた怪しげ健康器具落札された. こちらは開始価格のほぼ 2 倍に. 昨日の電池とあわせるとコメ代 3ヵ月ぶんは助かったか? 連絡メイルなど出す.
午後も観天バグの直しのつづき. 1350 ようやくおかしなところがわかった.
[なんかへんだと思ったら]
これって逆向けにぶっぱなしてません? 期せずして葉っぱにあたった「視線」は そこでぴたっと食い止められると確認はできたけど.
おおっと, これは下向けに撃ってるんじゃなくて, 賢いというかバカな視線が 視点からもっとも近い障害物を見つけて, そちらにぶつかっていってるんだ. つまり視線のヴェクターの正負を考えてないわけだ. さーて, どのレヴェルで修正を加えるべきか.
まじめに考えるのがイヤになったので, EyePipetree の中での「あたったとき処理」の Check 関数で自分より低いところにある 障害物は無視することにした. こーいう手抜きな直しかたでいいんだろうか …… 時刻 1415.
[安直に解決?]
めでたく, 対空射撃網の完成, ということでしょうか.
開空度計算やると, 速度がガタ落ち …… まずいことに 1 ステップ (1 年) の 計算時間が三次元オブジェクトの個数に強く影響されている.
三次元区画 Voxel の大きさをいろいろと変えてみると …… ああ, やっぱり区画を小さくすると計算速度が速くなる. つまり三角形断片がすごく集中分布してるのが問題である, ということなんだろうな.
計算速度問題だのおかしな生産モデルだのにケリがつかぬまま帰宅. 今日もばてた. 1755 研究所発. 普通に乗って 1810 京急杉田発. 快特に乗り換えて 1820 京急上大岡発. 普通に乗り換えて 1840 京急川崎発. 1920 帰宅.
晩飯食ってからも Abies PipeTree の続き. 残念ながら高速化に着手せざるをえない. どうすればよいか, という方針は帰りの電車のなかで確定した. しかしかなり面倒であるので, 明日体力が回復してから.
今晩は「最大成長量問題」に取り組む. あろめとらーな制約・ あじゃすたーずの偏執的に厳密な資源配分が実現している 空想植物世界において現実ばなれしてる点は多々あるんだが …… その中でももっとも目立つのは一昨日の図にあるような 「先端肥大」 とでも呼ぶべき現象である. これを押さえこむ術策が必要とされている.
なにしろ先端枝の長さが 1 年間に 60cm とか 80cm とか 伸びたりするからなぁ …… ところが「現実にはせいぜい 30cm」 だそうで, これがなかなかやっかいなのである.
すでに作ってきた小役人的な枝先端形成システムがこのような 御都合主義な「上限」を安易に組み込むことを 拒否しているのである. これは Xg の資源が与えられたら, それに見合うような太さ長さの主軸ならびに側軸を 適切な本数形成するにようになっている. ここで急に「長さ○○センチ以上は作るな」 というルールをあとから追加すると, 矛盾が生じるのである. 具体的には余ってはいけないはずの構築用資源が余ってしまう.
ということで, 最終目的としては軸の長さを制限したいのだけど, だからといって長さを直接にいじくるのは 自分で作った法律にもとづいて自分自身に死刑判決を下すような 愚策なのである.
ではどうするか? 当然, そのひとつ上流工程に手を加えることになる. ここはアロメトリーの宗教的制約をまぬがれている.
さて具体的な定式化であるが …… 基本となるアイデアは 「10g の炭水化物を渡されたら 10g の枝を作ることができるか?」 というものである. 答はもちろん否で, そうやって下賜された資源のうち何割かをさいて 「炭水化物から枝を形成するためのエネルギー」 として用いなければならない. つまり 10g の炭水化物をもらってもできる枝は 5g とか 6g といった重量になる.
この構造材+エネルギーへの分割なのだけど, ここでも安易に 「一定の比率で ……」 などとやってはいけない. これでは上限が設定されないのである. 投資量 10g なら新しい枝 5g, 100g なら 50g というふうに, 投入した資源に呼応して 末端枝のサイズが際限なく増大してしまう.
これをうまく収束させるにはどうしたらよいか? 「いくらでも増大する可能性があるのに 有限の大きさに収束する」 といったうまい数理モデルはないだろうか …… この場合は既存の生態学のモデルは何の役にも立たず, むしろ力学あたりから借用してくるのがラクである. そう, 「空気抵抗によって決まる落体の終端速度」 である.
空気中で落っこちるモノの加速度はそのときの速度に比例する 抵抗をうける …… というのを流用して, 成長速度に比例する資源浪費 (構造材ではなく「摩擦熱」として消える炭水化物) を仮定してやると, うまく上限を入れることができる, とわかった.
他よりもたくさんの資源を与えられた枝先は それをのんびりと「消費」してよいわけではなく, 他の枝先と同じ長さの限られた成長可能期間のうちに 全部使い切ってしまわないといかない (このへんは予算完全消化を強要されるお役所と同じである, と仮定してるわけね). つまり成長速度が相対的に速くなってしまって 「浪費」も増える, という定式化である.
世の中に樹木の枝の研究者というのはたくさんいるんだろうけど (大半はあろめとらーなのかな?), こういう「枝形成速度に伴って増大する建設コスト」 みたいなのをちゃんと調べたヒトっているんだろうか?
とはいえこれもいいかげんなモデルだなぁ, と思いつつ 今晩は数枚の古紙のウラにあれこれと怪しげな数式を 書き散らして静かに夜がふけていくのであった.
夜中に落札された健康器具を落札者に宅急便で送りだす. 電話料金も支払う. 1908 円.
今日の食卓
朝 (0720): 米 0.6 合. 昨日と同じく鶏レバ煮物の炊きこみ飯. キャベツ・タマネギ・シイタケの炒めもの.
昼 (1215): 弁当. 米 0.7 合. 朝と同じ.
晩 (1940): 米 0.7 合. 朝の残り.
本日
(
kubolog20010907
) |
次の日
|
1 日前
|
7 日前
|
31 日前
|
365 日前
|
top
KuboLog
|
KuboWeb