アメリカは、ハリケーン・カタリーナのニュースでいっぱいであるが、日本では、衆議院議員選挙で盛り上がっているのではないだろうか。

僕は、基本的に小泉内閣支持である。かつて、ここまで強行に公約を守ろうとした首相がいただろうか。公約で、これをすると言っておいて実行する小泉首相のやり方を見ていると、小泉首相はプロの政治家だなあという印象を持ってしまう。

昔の政治家のやり方で、とくに記憶しているのは、消費税を導入したときの惨状である。当事は高校生で、政治だの経済だのがどうなっているのか、よくわからなかったし、なんといっても社会の成績は最低だったからますますよくわからなかったのだが、結局、ちょっと考えれば誰の目にも間接税でも導入しないとこの先やっていけないことは明らかだったらしい。だったら、政治家としては、間接税が必要だということを訴えて国民を説得して正々堂々と導入すれば良かったものを、大型間接税は導入しないとか言っておいてあとから小型だとか中型だとか言い訳をつけたり、見苦しいことこのうえなかった。この点、小泉はもとから郵政改革を断行すると主張していて、なぜそれが必要なのかも何度も説明してきたし、そして、衆議院解散の勝負（勝算あってのことだと思うけど）に出てまでも、なんとしてもそれを通そうとしている。

また、衆議院解散に際しての作戦もうまい。郵政改革に反対した議員は利権にしがみつこうとしている悪徳政治家という図式をうまく作り出してしまったように見える。野党にしてみると、郵政改革反対と言ったら、なんで反対なのか理由を見つけあぐねているように見えるし、「郵政解散」とここまで叫んで解散されると、どうやって論点を逸らそうとしたって難しいのではないだろうか。

というようなことを考えると、僕は小泉首相というのは、最近なかなか出てこなかったようなプロの政治家という印象を持ってしまう。郵政民営化が果たしてそんなに簡単な理屈でうまくいくのかはわからないけれど、（というより、多分、こういうのは必ず紆余曲折を経るだろうけど）小泉だったらとりあえず政権を任せても大丈夫、任期が切れるまであと一年首相をやってもらいたいと思ってしまう。

内政面だけでなく、（結果を見て初めて気がついてばかりだったけど）、外交面でも小泉の手腕が光ったことが多かったように思う。

というわけで、郵政改革賛成派議員に投票したいんだけど、日本領事館からのE-Mailによると、外国在住の場合は、在外選挙人登録が必要です、とのことだったのだが、どうやって在外選挙人登録できるのか書いてなかったな。どうすりゃできたんだろう？僕はもう手遅れになってしまったので、誰か選挙行かないつもりだった人か、誰に入れるか決めてない人、よかったら、僕の分郵政改革賛成派議員に投票してきてください。

明日からカンファレンスでSan Diego。

2005/08/10

勝訴!

と、言っても、例の自転車の一件ではなく、駐車違反の切符である。僕は普段、車をPittsburghのアパートの裏の路地か、まわりの路上に停めている。日本では、路上駐車は原則違法だと思うが、アメリカでは普通である。アパートの裏の路地には、「Park On This Side(こっちがわに駐車)」という標識が出ている。

その同じ場所をずっと3年ぐらい利用していた。ところが、6月の中旬、突然障害者用駐車スペースの標識が設置された。しかも、その標識が高すぎる位置にあった。さらに悪いことに、脇の土手に生えている木や草が標識の3分の2を覆い隠していた。もっと悪いことに、本来駐車禁止の場所は道路脇を黄色くマークすることになっているのだが、それもなかった。もっとひどいのが、いったん知らずに駐車してしまうと、車を降りて回りをきょろきょろ見回したとしても、たまたま頭上を見上げなければ目に入らないほど高い位置に標識はあった。しかも、頭上を仮に見上げたとしても、設置してある角度が悪くて、その位置からではただの鉄板にしか見えない。さらに、その路地は午後になるとアパートの影で薄暗くなる。僕が駐車した木曜日は、ちょうど雷雲が通過中で（ワイパーを動かしていた記憶がある）さらに暗かった。アパートの路地は、駐車してある車に乗るために道から出てくる人もいて、歩道側に注意を向けなければならない。その状態で、窓に水滴がついていたのでは、絶対に標識に気づくわけがない。しかも、同じ場所は少なくとも過去3年間にわたって駐車可能箇所だったのだから。

その場所に僕が知らずに車を駐車したのが6月下旬の木曜日の夕方。金曜日は車を動かさなかった。土曜日に車を使おうと思ってその場所に来てびっくり。駐車違反の切符が二枚窓に貼ってある。僕が最初にしたのは、その切符を発行した警察署に行って、そんな標識は無い、と主張したことだった。が、警察署で、たしかに標識があると言われて、とりあえず帰ってきた。そして、初めて木の葉に隠された標識を発見したのである。

障害者用駐車スペースに車を停めると、罰金が大きい。二日分で$500弱の請求だった。しかし、見えない位置に標識を出しておいて、そんな罰金を請求するとは、とても受け入れることはできない。交通裁判所に無罪を申し立てた。そして、7月の下旬、8月10日に裁判所に出頭するようにとの通知があった。

写真を撮りまくって、Power Pointで資料を準備した。主張する点としては、

• 標識が高すぎて、しかもあまりにも左にあるので、気の葉や草にさえぎられて標識の上3分の2が見えない。まして、歩行者に気を配っているとますます標識には気づきにくい。
• 路地は午後になると、アパートの影に入って薄暗くてさらに標識が見づらい。しかも、当日は雷雲が通過中だった。
• 道路わきを黄色に塗っていなくて、しかも、駐車位置から標識が見えない。
• 仮に駐車して、アパートの入り口からリモコンでロックをかけたとしても、その位置からは標識はほとんど視線と平行になっていて、事実上見えない。
• 標識が見えかったのだから、こちらに非は無い。

という点である。

今日の9時半に裁判所に出頭するようにとのことだったので、時間より少し早く行った。裁判所の入り口では、3階に行くように言われたのだが、1階に窓口でcheck inするようにという掲示があったので、窓口に行ったところ、法廷の入り口の机でcheck inするように言われた。そこで、法廷入り口前の机でcheck inしようとしたところ、交通裁判は2階に行くように言われたので、2階に行った。そして、2階の法廷前の窓口でチェックインした。法廷の中で待つように言われたので、法廷に入って待つ。

交通法廷なので、交通違反の人が皆来るらしく、たくさん人が待っている。同じ法廷で壁で仕切られるわけでもなく、判事が次々に言い分を聞いて判決を出している。なので、声が聞こえてくるのだが、信号無視とか明らかに裁判で勝てそうにないようなことで無罪を主張する人がいるらしく、そういう人はほとんど話を聞かずに有罪にしていたようだった。

待つこと一時間。僕の順番が回ってきた。Power Pointをプリントアウトした資料と、それぞれのポイントを主張するための写真がある。学会発表と要領は同じだ。「自分は世界一のプレゼンターである」と、学会発表前と同じ自己暗示。そして、判事の前に行く。最初に、判事の横にいる警察官が容疑を読み上げた。そして、判事が僕に「How do you plead?」と聞いた。「I plead not guilty because the sign was posted way too high, and too left, and hidden by tree leaves.」同じ部屋にいた妻によると、判事の前で裁判を受けている人達の中で、僕が一番はっきり通る声で堂々と話していたらしい。

最初の一言を発してしまえば、あとは勢いに乗ってポイントを主張できる。学会発表でもそうである。違いは、プロジェクターとレーザーポインタではなく、撮ってきた写真とパワーポイントのプリントアウトを指差しながらプレゼンテーションするぐらいである。

事前に主張しようと思っていたポイントをほぼ一通り主張し終えたところで、判事からひとつだけ質問を受けた。判事は、「なぜ木曜に切符を切られたのに、金曜日も同じところに停めたの？」と言った。「木曜日に車を停めて、金曜は車を動かさなかった。車を使うのは週に1〜2度なので。」と応えた。本当のことである。正直に答えた。

判事は、最後に「じゃあ、今はその標識があることを知っているわけだから、次から停めないように」と言って、法廷の外の窓口に行くように言った。その場で判決を言ってくれるのかと思った僕はがっかりした。窓口というのは、罰金を払うところなので、無罪にならなかったのかと思った。

しかし、窓口で告げられたのは、「判事はすべての容疑を取り消したので、とくに既に払ってしまった罰金などがなければ帰ってもいいよ。」とのことだった。裁判所に行ったのはこれが初めてだったのだが、初勝訴になった。

まあ、たかが駐禁だけど。もうPittsburghに住んで8年目になるけれど、どうしても、英語ネイティブの人と同じようには話せない。それだけに、英語で何かうまくできると今でも嬉しい。学会発表のときもそうだし、今回も判事に英語でこちらの主張を話して認めてもらえたというのは、嬉しかった。

ちなみに、例の自転車の一件は、いまだ弁護士さんが悪徳保険屋と交渉中。

<- 歩行者に注意すべきか？3分の2隠れた障害者用駐車スペースの標識を探すべきか？(クリックすると拡大)

2005/08/05

アメリカ在住だが、日本のニュースは、http://www.asahi.comとかhttp://www.yomiuri.co.jpとかで見ている。

今日は、両方に「教員免許を更新制に」という記事が出ていた。教員の不祥事とかもあったし、綱紀粛正を計ろうというつもりだろうけど、僕に言わせると単純過ぎる。第一、教員の適正なんて、誰が判定するんだろう？できるんだろうか？

僕だったら、綱紀粛正の逆で、教員の待遇を大幅アップする。給料倍増とか。それで、優秀な人材が競争で教員になりたがるような仕組みを作ると、自動的に不祥事を起こすような教員は淘汰される。教員の適正なんて計れるわけないんだから、教員という仕事を魅力的なものにして、競争原理を導入した方がずっと頭がいいような気がするんだけどな。

2005/06/18

昨日まで、ACM Symposium of Solid and Physical Modelingという学会に出席するために一週間ボストンに行っていた。この学会で発表した論文は、List of Publicationsに出したので、興味のある人は参照していただきたい。また、非常に名誉なことに、学会誌の表紙絵に僕の論文の絵が採用された。まさか、僕の絵だけとは思っていなくて、いくつかの論文の絵を表紙にプリントするのかと思ったら、なんと、僕の絵が2枚、でかでかと論文誌の表紙を飾っていた。ひさしぶりのヒットだった。

←クリックすると拡大

ボストンに滞在したのはこれで3度目だった。ボストンに行ったときは、必ずWhale Watchingに行く。というわけで、今回もWhale Watching Tourに行ってきた。下の写真はそのときの写真。(クリックすると拡大)

偏光フィルタを使うと、水面の反射を抑えることができていい、という話を聞いたので、前回それを試したけどあまりうまくいかなかった。どっちから鯨が出現するかわからないし、水面に出ているのはほんの数秒なので、その方向にカメラを向けて偏光フィルタをまわしているうちに鯨がもぐってしまう。というわけで、今回はただのUVフィルタで撮ったのだが、それなりに良かったのではないだろうか。飛行機の写真を撮るときも、偏光フィルタを一時期使っていて、たしかに空の色が深い青になるのだが、ただでさえ望遠レンズで暗いのにシャッタースピードが限られてしまうので、最近またUVフィルタに戻している。

ちなみに、帰りの飛行機はボストン->デトロイト->ピッツバーグの予定だったのだが、ボストンの空港に行ってみたら、ボストン->デトロイトが遅れでピッツバーグ行きに乗り継ぎができなくなったとのことで、別のエアラインの直行便に変更してくれた。直行便だけにもともとの予定よりも早くピッツバーグに到着してしまった。飛行機が遅れたおかげで早く着いたというのも珍しい。コンコルドが現役だったころは、British Airwaysが乗客をコンコルドに振り替えてかえって早く着くということがあったらしいけど。

2005/05/24

エアロック飛行再開決定！

日本にいる友達からとてもいい知らせがあった。エアロック・アクロバットチームが飛行を再開するとのことである。ロック岩崎さんの飛行は、日本にいたころ何度も拝見した。日本のアクロバットチームの先駆けとして活躍したロック岩崎さん死亡のニュースはとても悲しい知らせだった。しかし、ロック岩崎さんの遺志を継いでなんとか飛行を再開してほしいと思っていた。飛行再開のニュースは、ひとつの明るい報せだった。

今年は、ロック岩崎さん事故死の前から、つらい事故が続いた。4月14日、新潟救難隊MU-2墜落事故では、亡くなった乗員のうちの一人の年齢が32歳とのことだった。高校の同期の友達が、救難隊でUH-60Jを操縦しているのだが、年齢が同じなので、ひょっとして、彼の知り合いではないかと思ったのだが、その後連絡があり、彼と同期（多分航空学生同期）だったとのことだった。

僕自身、中学・高校と同期生だった友達を1998年のF-4EJの事故で亡くしている。その友達と、最後に交わした言葉というのが、僕が二日酔いでへろへろになっていたときにかかってきた電話で、しどろもどろな会話だった。それが今でも心残りになっている。その前の年、三沢基地航空祭でばったり出会って、そのとき初めて彼が悲願を達成して戦闘機パイロットになったことを知った。そのときは、「事故るなよ！」と言って別れたのだが、その後一年もしないうちに事故死するとは。それがトラウマになっていて、今でもパイロットの知り合いに「事故るなよ！」と怖くて言えない。新潟のMU-2の事故で亡くなったのは直接の知り合いではないのだが、あのときの記憶が甦った。

そして、4月21日、ロック岩崎さん、アクロバット飛行の訓練中に墜落の報であった。これまで、何度もロック岩崎さんの飛行を拝見して、厚木基地エアショーで飛行されたときは、駐機している場所のすぐ目の前に陣取って飛行前のイメージトレーニングからずっと見ていたこともあった。ひとりのファンとして、ロック岩崎さん事故死は、大きなショックだった。

日本には商業ベースのアクロバットチームが無かった。日本の航空技術がアメリカ、ヨーロッパに比べてこれほど遅れを取っている原因のひとつは、空が身近なもので無いという点なのではないか。たしかに、第2次世界大戦後、アメリカは日本での航空技術の研究を禁止した。しかし、その影響はもう無くなってもいい時期ではないだろうか。アメリカには、商業ベースのアクロバットチームがたくさんある。航空ショーで、軍用機のスピード感とパワーにあふれる展示飛行は、小さい子供は怖がってしまうことがあるのだが、民間のプロペラ複葉機のアクロバット飛行はどんな子供も目を丸くして見ている。そして、その感動の体験によって、将来航空分野に進もうと決める子供たちがたくさんいて、それがアメリカの航空技術を支えているのではないだろうか。

たかがアクロバット、と言ってしまえばそれまでなのである。 たしかに、プロペラの複葉機がF-15やF-18といったジェット戦闘機の横に置いてあると、古臭く見えるかもしれない。しかし、現実問題として、「たかが」と思うことが、結果的に 歴史に大きな影響を与えている事例は数え切れないほどあるのである。ロック岩崎さんの挑戦は、将来振り返ってみると、実は日本の航空宇宙産業に重大な影響を及ぼしていたということに気づくかもしれない。それだけに、エアロック・アクロバットチームがロック岩崎さんの遺志を継ぎ、飛行を再開するというニュースは悲しい事故のニュースが続いた中で、ひとつの明るいニュースだった。アメリカに住んでいるだけに、なかなか飛行を拝見することはできないけれど、遠くから応援したいと思う。

2005/05/09

International Meshing Roundtable (http://www.imr.sandia.gov)に投稿した論文が通った。発表しに秋にSan Diegoに行く。査読が3本帰ってき て、そのうちの2本は、7段階評価の5と6。よほど良く書けていて、カンファレンスの最優秀論文賞候補レベルでないと最高評価はつかないことを考えると、5と6というのはかなりいい評価である。ところが、もう一本の査読が1をつけてきた。内容は、非常に攻撃的な書き方で、無責任な査読だった。だいいち、この論文の最大の悪い点は、シンプル過ぎる点である、という、わけのわからない理由を書いていた。エンジニアリングのセンスのある人ならば、同じだけ効果的な方法であれば、シンプルな方が優れていることは容易にわかる。シンプルであることが悪い、という書き方はまったくナンセンスである。ついでに書くと、この論文に書いた内容は、従来のどの方法でも解けない問題へのアプローチなので、他に同様の効果的な方法は存在しない。だから、これほどシンプルな方法でこの問題を解いたことは良い点であっても悪い点と言われる筋合いは無いのである。おそらく、この査読をした研究者は同様の研究をしていて、先を越されることを防止する意図があったのであろう。あるいは、単に日ごろからライバル関係にある誰かが僕の論文が通ることを快く思わなかっただけかもしれない。しかし、論文を落とすという目的は(彼には残念ながら)失敗に終わった。このような小ざかしい手でライバルの論文を落とそうとする暇に、まともな研究をすればよさそうなものだ。

週末、Clevelandまでセスナ210で飛んできた。今まで操縦した中で一番複雑な飛行機で、さすがに教官にかなり手伝ってもらわないと操縦できなかった。カウルフラップのレバーが硬くて、一番下まで下げたつもりだっがのが下がってなかったり、着陸の降下に向けて、スロットルを絞ったらマニフォールドプレッシャーがグリーンアークから大きく下になってしまって、「これっていいんだっけ？」と不安になってみたり(短時間なら良かったらしい)。近いうちに My Flight のセクションにアップロードする予定。

秋のバージョンアップに向けてYSFLIGHTをいろいろいじっている。4月のバージョンアップでもまたまた実現できなかった、エアレース機能を追加したいのだが、Scenery Editorでうまいことおもしろいコースを作るのが難しいので、まずはScenery Editorの機能強化から始めなければならない。

そのScenery Editorは、エアレースのコースを作る機能はまだ手をつけていないが、とりあえず、地図にグラデーションをかけることができるようにしてみた。この機能を使うと、次のような効果を出すことができる。

旧

新

これは、OpenGLの GL_QUAD_STRIP というプリミティブを使ってグラデーションのかかった四角形の連続を描くことで実現することにした。Non-OpenGLでは、グラデーションはかからないが、これによってそれほどパフォーマンスが低下することは無い（はず）。

考えてみたら、現在地図上に描くことができるプリミティブのタイプは、内部的にはポリゴンか線だけである。OpenGL版を高速化することを考えると、同じ色の四辺形を連続して描く場合（滑走路のセンターラインとか）は、 それ専用のプリミティブにしてGL_QUADSを使って描いた方が圧倒的に速くなる。その仕組みを作れば、すでに作ってしまったScenery内でセンターラインなどを自動的に新しい 効率的なプリミティブに変換することもできる。また、道路(Thick Line)なども、GL_QUAD_STRIPで描くように書き換えればぜんぜん効率が良くなる。これ気づいたときは、今までなんと頭の悪いことをしていたのだろう、と、思ってしまったが、もともとOpenGLに最適化したデータ構造ではなかったので、たまにこういうことがある。

2005/05/05

日本ではゴールデンウィークのようだが、ここはアメリカなので普通の日である。

例の自転車の件はまだ解決していない。とにかく、弁護士さんが話してくれている間はとりあえず待つ。裁判に出るとしたらどうやって戦おうか、多分、友達ふたり（どっちも機械工学博士）に手伝ってもらおうと思っている。別に自分で事故の分析をしてもいいのだが、裁判の結果によって利益を受けることのない友達が僕の分析に同意を与えてくれれば少しはこちらに有利になるかもしれない。

ところで、最近MFC (Microsoft Foundation Class) を使ってプログラムを書いている。そんなに大きなプログラムにするつもりは無いが、営業用(?)に少し見栄えのいいプログラムにする必要があるので、MFCを使っている。

はっきり言って、MFCプログラミングは忍耐の勝負である。Win32APIを直接使っていたころと違って、MFCはいろいろ余計なことをする。初めてCDialogBarを使ってみたのだが、出てきたダイアログ上のボタンが全部disableされている。まずはボタンをenableしないと先に進まないと思って http://msdn.microsoft.com を中心に調べる。イベントハンドラを割り当てないとMFCが勝手にボタンをdisableすることがわかるまで半日。まずボタンをenableしないと先に進まないのではなくて、先に進まないとボタンがenableされないの間違いであった。なので、CDialogBarを貼り付けるCMainFrameにイベントハンドラを割り当てようと思ったのだが、Class WizardでボタンのIDが出てこない。さらに数時間を無駄にして、やっと、リソースエディタ上でダイアログをダブルクリックしてClass Wizardを起動しないと、ボタンのイベントハンドラをCMainFrameに設定することができないということがわかった。(ViewメニューからClass Wizardを起動するのだと、ボタンのIDが出てこない。ひどいデザインだ。）

昔Visual C++が4.2だったころ、MFCの使い方の本を書いたが、MFCとの付き合いはそのぐらいで、その後ずっとWin32APIを直接たたくプログラミングをしていた。理由は、その方が、コアになる部分とアプリケーションの部分の切り分けが簡単だったからである。MFCは見栄えのいい、巨大なプログラムを書くには適しているだろうと思う。が、研究室で書くようなプログラム、とくに、新しい技術を試すために何本もプログラムを試作しなくてはならないような用途には向いていない。

プログラムを書くときは、まずプログラムの土台になるコアの部分を作る。そして、アプリケーションごとの目的を実現するコードをそのコアの上に継ぎ足して書く。例えば、後でコアの部分だけ改良した場合、コアの部分をそっくり取り替えれば、そのコアを利用しているすべてのプログラムが自動的に改良されるように作っておくのが理想的である。

ところが、MFCだとそれはできない。まず、App Wizardを使ってMFCアプリケーションフレームワークを作る。僕の場合3次元グラフィックスが表示できないと用が足りないので、OpenGLの初期化、視点操作などの機能を追加して、それがコアになる。問題は、MFCのイベントルーティングである。MFCのClass WizardはイベントルーティングテーブルをアプリケーションフレームワークのMainFrm.cpp, ChildView.cppの中に書き込む。これは、僕の使う土台の場合、視点操作ダイアログのイベントハンドリング情報などがここに書き込まれる。

コアができあがったあとで、そこにアプリケーションごとの機能を追加していくと、同じイベントルーティングテーブルにそのアプリケーションごとの機能に必要なイベントハンドリング情報が書き込まれる。これが良くない。あとでコアだけ取り替えようとすると、手作業で、イベントルーティングテーブルの一部を切り出して、新しいコアに間違えないように貼り付けないといけない。単にリンクするライブラリを取り替えれば済むように作ることができない。要するに、Class Wizardがコアとアプリケーションをまぜこぜにしてしまうのが悪いのである。

いいプログラムを書くポイントは、いかにモジュール間の独立性を保つかのの勝負と言っても言いすぎではない。ゼロから自分の手で書き上げたプログラムならば、どこでどのようにコアとアプリケーションの境目をつけるか決めることができるが、MFCのように肥大化して下手に自動化されていると、それができないのが困る。

というわけで、僕はMFCにあまりいい印象を持っていない。仕事で使えと言われれば使うけど、なるべく避けたい。Microsoftと心中する覚悟を決めればもっと突っ込んでMFCプログラミングを勉強してもいいのだろうけど、Microsoftの栄華がこの先もずっと続くかどうかわかったものではないし。（かといって、僕はLinuxがそんなに好きなわけでもない。Linuxは使うけど、深入りしたくない。それどころかFSFかMicrosoftかどっちかに組しろと言われたら迷わずMicrosoftに組する。誰か、ぼちぼちまったく新しいシステムでも作ってくれないもんかね。その話は機会があったら書くつもり。)まあ、けど、仕事だから仕方ない。なるべく小さくまとめて見栄えのいいメッシュジェネレータを作ってそれで終わりにするつもり。

2005/04/15

最近、とある事情で友達の魚を預かっている。主に熱帯魚なのだが、その中になまずが三匹いる。大きさ的にあまりなまずっぽくないのだが、間違いなくcatfishとのことなので、なまずであることはまず間違いない。他にも種類はいるのだが、なまずが一番おもしろい。普段水底でじっとしてなにか瞑想しているようである。実際は次の餌について瞑想している程度なんだろうけど。

大きいのと小さいのとその中間ぐらいの大きさのがいて、小さいのは右目が無いので、政宗と名づけた。中ぐらいのやつは、「中なま」と名づけたので、大きいのは必然的に「大なま」に決定した。友達のなまずだけど勝手に命名。

ぼちぼちピッツバーグも初夏の陽気になってきた。中ジョッキの生ビールが飲みたい、となまずを見ながら思う季節になってきた。

「大なま」

「中なま」と「政宗」

2005/03/29

例の自転車事故について、先々週、もうひとりの弁護士さんと会って話をしてきた。彼は、友達が紹介してくれた弁護士さんで、その人がとりあえず、保険会社の皮をかぶった暴力組織と直接話をしてくれることになった。勝てる見込みがあるということかな？

しかし、悪の借金取りは、ふたたび無礼な手紙を送りつけてきた。言っていることはこれまでと同じで、僕が駐車車両に近すぎるところを通過しようとしたのが事故原因であって、僕が悪いから金を払えと言っている。それで、例の保険金詐欺師の女が車のダメージと主張する写真のコピーも送ってきた。見ると、主なダメージはドアの内側で、ちょうどタイヤの位置、それとシフトレバーがあったあたりにひっかき傷がついている。たしかに、こちらの自転車のダメージと一致する。さらに、この写真は、その保険金詐欺師が言う、ドアを少し開けただけという主張が嘘であることがあらためて示している。ドアをちょっと開けただけなら、なんでドアの内側に自転車の車輪が突入できるというんだろう？少なくとも自転車の幅の半分以上はドアが開いていたことになる。さらに、シフトレバーの高さぐらいのドアの後ろ端に切り傷がついている。やはり、思ったとおり、シフトレバーがそのへんに激突したのだろう。多分、僕の思った通り60度程度はドアが開いていたのだろう。そして、僕はそのドアの先端付近に激突した。そうでなければ、前輪と右シフトレバーが同時にドアの内側に激突することはできない。こんなことは、保険会社も承知のはずだ。要するに保険会社の皮をかぶった暴力組織なんだな。やっぱり。

最近、頻繁にその暴力組織の広告を見るようになった。きっと事故の被害者から巻き上げた金を使って広告費に充てているのだろう。

一応、メールでその弁護士さんに報告して、今その返事を待っている。

2005/03/24

今週は、うちのボスがいないので、水曜に休みを取ってボウリングしてきた。アパートのすぐ裏のボウリング場なのだが、水曜日の昼から3時まで$10で投げ放題である。前回行ったときは、15ゲーム連投してきたのだが、昨日は8ゲーム目の途中で手のひらの皮が半径3mm程度むけてしまったので、せっかく休みにしたのに残念ながら8ゲームでやめておいた。

ちなみに、僕はボウリングが好きである。基本的に毎週やっている。スコアは人より少し高いぐらいで、だいたいアベレージで150弱である。もう長いことやっているのだが、いまいち150アベレージで落ち着いてしまってそれよりうまくならなかったのだが、最近ボールを新調してから、ようやくプロボウラーみたいなフックがかかるようになってきた。（ちなみに、10年間使ってきたボウリングシューズも穴が開いたので、これも新調した。）けど、まだスピンが甘いらしく、スピードをつけるとどうもうまく曲がらず、曲がる前にピンに届いてしまう。まあ、それはそれでいいとして、速いボールと遅いボールを投げ分ける練習を最近している。そのうちアベレージの上がるだろう。また、夏場、草ソフトボールリーグが始まるとボウリングしていなくて、冬の練習の成果を一通り忘れて、次の冬に最初からやりなおし、というのがよくないと思ったので、今年は夏の間も投げようと思っている。

今朝メールをチェックしたところ、今度6月に研究発表の予定のカンファレンスのChairの人からメールが入っていた。Copyright Transfer Formというのを送れとのことだった。学会によって、このCopyright Transfer Formを律儀に要求してくるところと、その辺いい加減なところがある。が、今度6月発表に行くのは、ACM Solid and Physical Modelingという学会で、割といい学会なので、そのへんしっかりしている。けど、僕はうっかりそのフォームを送るのを忘れていたので、あわててFAXで送った。

が、その今朝届いたメール、もうひとつ気になることが書いてあった。論文の最終版をPaper Publication Directorなる人に送るように、とのことであった。はて、最終版はとっくの昔に送ったはずだけど？？？と、思って、今朝の前にConferenceから届いたメールを開いてみたのだが、、、6日前に届いたメールに、たしかに最終版をPaper Publication Directorに送るようにという指示があって、そこに、最終版の体裁の指定が書いてあった。実はこのメール、僕は単に最終版を受け取りましたという確認のメールだと思ってよく読んでいなかったのであった。（だって、Subjectにもconfirmationと書いてあるし。）

しかし、そこに指定してある論文の体裁が、最初にあった体裁の指定と違うのである。ただの確認だと思い込んで読まなかったのは僕の責任だが、いくらなんでも、6日前にいきなり別の体裁に直せと言うのはあんまりだ、と、思ったので、とりあえず最初に指定されたとおりの体裁で書いてあるけれど、あまりに急だったので新たに指定されたような体裁にはなっていないので、問題があるようだったら教えてくれ、と注釈をつけて、論文の最終版を送り出した。

後になって、これでもいいけど、あと2〜3日なら待てるから、体裁を変えて送りなおすならそのようにするようにとのメールがあったので、とりあえず一安心。

YSFLIGHTサーバーは、依然一度もクラッシュせずに動いている。ついさっき、実行ファイルを入れ替えたので、次にログオンするときは、Version Conflictのウォーニングが出るが、とりあえずログオンに支障は無いはず。サーバーが調子よく動いているので、Pre-Release Testをまもなくはじめようと思う。4月中旬には正式版にできるのではないだろうか。

今回も、要望すべてに応えることはできないけれど、少しずつ対応していっているので、今後のバージョンに期待していただければと思う。

2005/03/21

YSFLIGHTのサーバーテストを開始して二日半、サーバーがクラッシュするところを見つけてなんとかしようと思っているのだが、今のところなにごともなく動いてしまっている(^_^;)ということは、サーバークラッシュ問題は、やはり発射した武器が命中する前に飛行機をクリーンアップされてしまったことが原因だったのだろうか？いくつかそうではなさそうなレポートもあったのだが、それは他のバグと共に（他の箇所を修正してしまったときに）去ってしまったのだろうか？とりあえず、少なくともあと一週間ぐらいはテストを続けようと思っている。

ところで、このネタはかなり受けがいいので、From Authorに出そうかということになったのでちょっと紹介。これは、3年だか4年ぐらい前に学会 International Meshing Roundtable (アメリカ)に行ったときのことである。その日の午後の最初のセッションはパラレルセッションで、複数の発表が同時進行していた。それで、僕が見たいセッションは、Ballroom 2Bという部屋だった。で、そのBallroomがあるフロアに行ったのだが、なぜか部屋に番号が書いていなかった。そこでとっさに、僕は部屋のとこに立ってた人に聞いてみた。

Is this room 2B or not 2B?

わかる人にはわかったかな？わからなかった人には、ごめんなさい(^_^;)僕の隣にいた友達には非常に受けたけど。というわけで、このネタがわかる人は、次からアメリカの学会に行って、自分が見たいセッションがRoom 2Bだったときは、誰かつかまえて↑のように聞いてみよう。

2005/03/08

昨日、知り合いの人が紹介してくれた弁護士さんと会ってきた。親切なことに、問題の借金取り(Collection Agencyと言う)に電話してくれて、僕には法的に責任が無いからこれ以上僕に対してコンタクトしないように念押ししてくれた。彼が言うには、その借金取りは、悪の保険会社から委託を受けて、もしも指定の金額を回収できたときは、その一部を受け取るという契約で仕事をしているらしい。次元としてはオレオレ詐欺と同じである。オレオレ詐欺団が公式な会社として成り立っているとは、ひどい話である。

それで、とりあえず、僕が攻撃を受ける心配はまずなくなったとのことだが、自転車の修理代を回収しようと思ったら、裁判に持ち込むしかないとのことだった。また、裁判官（この金額の場合は判事）は中立である建前だが、やはり日本人であるということで、アメリカ人に好意的な判決を出す危険はやはり無いとは言い切れないとのことだった。なので、アメリカ人の友達を一人連れて行くといいとのことだった。

裁判になって、全面勝利したとしても回収できるのは$1,000程度。裁判にかかる労力と比べると小さい金額である。が、しかし、ここまでひどいことをされては黙って泣き寝入りするのはいくらなんでも悔しい。来週の水曜日、もうひとりの弁護士さんと会って話を聞くので（親切にも現場横のStarbucksで落ち合って、現場を見てくれるとのことだった）、その情報も踏まえて次にどうするか結論を出そうと思う。

先週末から、YSFLIGHTのテスト版の公開を開始したが、概ね好意的なメールをいただいている。何通か、すでに何年もYSFLIGHTを使ってくれているというメールもあって、とても嬉しかった。また、いつもテスト版を出すたびに、即座にテスト報告をいただく方にもとても感謝している。とりあえず、これまでにいただいたバグ報告などに対応して、数日中に次のテスト版をリリースを予定している。（計器パネルで東西を逆にしてたのはちょっとわれながら間抜けだったが、内部的には方位が左回りがプラスになってるもんで、たまに間違える(^_^;))

ひとつだけ、更新情報を出そうと思う。（気まぐれ）。既に何人かのユーザの方からご指摘を受けている点なのだが、半透明ポリゴンがのぞき穴を作ってしまうことがある。これを完全に無くすには、かなりの計算力を必要とするのだが、減らすことは割と簡単にできる。半透明ポリゴンを、透明じゃないポリゴンをすべて描画した後で描画すればいい。だが、描画順序を 考慮して描画するのは、かなりの計算力までは必要にしないが、ちょっとだけ多くの計算力を必要とする。なので、新しいオプションを追加することにした。下の絵のとおり、新しいオプションをオンにすると、半透明ポリゴンをまとめて最後に描画するので、ゼロ戦のプロペラによるのぞき穴が出ないが、オプションがオフだと発生している）

<- 新オプションオン

<- 新オプションオフ

これからもYSFLIGHTをよろしくお願いします。

2005/02/19

相対性理論の話はまだ考えている。というか、まじめに教科書買ってきて頭から読めばいいんだよな。

ところで、去年の10月の自転車事故はまだ尾を引いている。もともと、うそをついたのは、後方の注意を怠ってドアを開けた運転手の方であって、僕に対してだけではなく、保険会社にもうそをついた。この時点で、この運転手は保険金詐欺の犯罪者である。それを許すか許さないかは保険会社の問題だが、とにかく、僕は誠実に保険会社の調査に協力した。しかし、保険会社は保険金詐欺に加担することを選んだ。

何が起きたかは簡単で、運転手が後方を良く確認せずにドアを開けたので、自転車の僕は回避する余裕がなくドアに激突したのである。

ところが、その運転手の主張はこうである。ドアは衝突の前数秒間開いていて、ドアはほんの少しだけ開けただけであって、僕が車にあまりにも近くを通ろうとしたそうである。つまり、僕が数秒間開いていたドアに対して回避捜査を取らずにドアに激突したというのである。僕が目をつぶって運転していたとでも言うのだろうか？どちらが信用に値するか、少し考えればわかりそうなものである。

さらに、自転車のダメージを見れば、その主張が誤りであることは一目瞭然なのである。まず、フォークの曲がり方を見れば、ドアは少なくとも自転車の幅の半分は開いていたことがわかる。さらに、右シフトレバーがドア（おそらく窓の部分）に激突してめくれあがるように壊れていることを考えると、自転車は車からある程度の距離を取っていて、ドアも多分45度から60度開いていたのではいと説明がつかない。が、保険会社は自転車を見ようとしなかった。つまり、保険会社は悪に加担したのである。

ところが、保険会社は、その運転手の嘘をすべて採用して、僕の報告をすべて無視して、事故の全責任は僕にあるという結論を出した。そして、どういう面の皮をしているのかは知らないが、借金取りを雇って、僕にたいして$1500を支払うようにという請求書を送りつけてきた。

当然払うつもりはない。どうも、裁判所に行かざるを得ないような雲行きになっている。とにかく、今は知っている限りの有人、知人に助けを求めている。少なくとも、裁判に持ち込むならば十分に準備をしてからにしなくては。相手は善良な市民に罪をなすりつけ、保険金詐欺の肩を持つ悪の組織である。

しかし、公平な裁判を受けることができるのだろうか？最近のアメリカ国内のムードは明らかに移民に対して不利である。訴えるならば保険会社と運転手二人を相手取ることになるが、相手は嘘をついて恥ともなんとも思わない悪人である。証拠を捏造したならば誰かそれを捜査してくれるのだろうか？

とにかく、戦う準備をしなくてはならない。

2005/02/07

Pittsburghは2〜3日前から妙にあったかい。その前が異常に寒かったので、その反動のようなあったかさである。

昨日、嫁さんと一緒に映画「The Aviator」を見た。途中、ヒューズ社とTWA社が倒産しそうになったりするが、どっちも倒産していないので、とりあえずbad endingではなさそうだと思って安心して見れる映画だった。また、Discovery Wings Channel (Military Channelになっちゃったけど)で見たような機体が出てきておもしろかった。

ところで、最近、研究の一環で、ポリゴンモデルの曲率の概算をやっている。このテーマはいろんな人がやっているテーマだが、ほとんどの方法は、大きさが一様でそれなりに品質のいい三角形メッシュ、あるいは四角形メッシュを対象にしている。そうでない方法も、角付近の曲率があまりよく出ない。が、僕が必要なのは、一般的なポリゴンモデルから質のいい三角形、四角形メッシュを作るための曲率の概算なので、一般にあるような方法はあまり有効ではない。鶏と卵のようなもので、質のいいメッシュを作るにはいい曲率の概算方法が必要で、曲率をうまく概算するには、質のいいメッシュが必要だった。というわけで、この連鎖を断ち切るには、質の悪いポリゴンモデルでもうまく曲率を計算できる方法が必要だった。というわけで、新しい曲率概算テクニックを開発して、かなりうまく動くようになった。近いうちに論文に書く。

その曲率概算テクニックはそういうわけでうまく動いているのだが、それを考えているうちに、相対性理論で、光が重力で曲げられることの説明でよく聞く、空間の曲率というもののイメージがなんとなくわかってきたような気がした。相対性理論の説明で、空間を2次元のゴム板に見立てて、重力ばある箇所で、ゴム板が大きくへこんでいる図をよく見るが、あの図の意味するところを前から考えていて、でもうまいこと理解できずにいた。以前は、座標軸が曲がったような図をイメージしていたのだが、その説明だと、光がちょっと曲がるということは無くて、光がブラックホールに入って出てこなくなるか、まっすぐ進むかどっちかしかありえないので、やっぱり違うような気がしていた。が、上記の曲率概算方法をやってるうちに、座標軸はまっすぐのままで、空間の曲率で光が曲がるというのがなんとなくわかるような気がしてきた。が、僕のこのイメージでは、仮に負の重力場が（物を遠くに押し戻そうとするような重力場）が存在したとすると、それでも光は重力に引き寄せられるように曲がっていってしまう計算になるので、やっぱり違うのかもしれない。けど、そもそも負の重力場なんてこの世に存在しないから、実はそんなことは心配しなくてもよくて、この解釈でも正しいのかもしれない。そのうち可視化プログラムを書いて、理論物理やってる学生をつかまえてこの解釈が正しいかどうか聞いてみるつもりでいる。本当は、相対性理論の教科書をまじめに勉強すればいいんだろうけど、幾何の知識でなんとか理解しようとするから混乱するんだろうな(^_^;)

2005/01/15

1,000,000th Visitor!

ついに、www.ysflight.comのヒットカウントが100万カウントに届いた。同じ人が何度も訪れてくれるので、100万人ということではないと言っても、相当な数の人がこのページを見てくれたのは間違いないと思う。最初は、ASCIIから出版した「3D Graphics開発キットBlue Impulse」のサポート用に開設したページであった。アドレスも、http://tristar.sfc.keio.ac.jp/~ys11とかいうアドレスだったが、今はもうこのアドレスは存在しない。カウンタを開始したのは、よく覚えていないのだが、1998年9月5日とあるから、Pittsburghに引っ越してからだったようだ。慶應大の博士課程を中退してCarnegie Mellonに来てしまったので、いつまでもsfc.keio.ac.jpドメインのアカウントを使いつづけるわけにもいかないと思って、当時Nifty-ServeのMember's Homepageに移転したのを機にカウンタを0から再開したんだったような気がする。あのころは、機械工学科に移って、博士候補試験の勉強で必死の時期で、プログラムを書いたり、Webページを更新したりするのは、現実逃避だった。今は、その現実逃避の一環で書いていたYSFLIGHTがメインコンテンツになり、Nifty-Serveは@Niftyになり、URLもwww.ysflight.comになった。

このページには、日本を含め少なくとも29カ国の人が訪れたようである。英語と日本語と両方維持するのは手間が2倍かかるのだが、その意義はあったと思う。なんといっても、自分が作ったプログラムがそれほど多くの国で多くの人に使ってもらっているというのがおもしろい。一個人が趣味でやっているWeb siteとしては大成功と言っていいのではないだろうか。

これまでの応援ありがとうございました。これからも、このWeb siteを楽しいものにしていこうと思っているので、これからもよろしくお願いします。

2005/01/12

昨日、YSFLIGHTで爆弾槽のドアを開閉できるようにしてみた。依然、エアレース機能を追加しようとしながら時間がとれずにいるけれど、YSFLIGHTの開発を維持できているのは、絶対仕事の時間を犠牲にしなかったからであって、ここ数ヶ月忙しくてYSFLIGHTに割く時間が無かったのは仕方がなかったことである。とりあえず次のリリース（春のうちになんとか）までにどこまでできるかやれるとこまでやってみる。ちなみに、また追加のスクリーンショットを近々tech support pageに出そうと思っている。

ところで、このページを見ている人の大半は、僕が人生の大半の時間をYSFLIGHTの開発に充てていると思っているのではないかと思うのだが、実のところ、仕事で書いているコードの分量はその10倍ぐらいになっていると思う。その仕事の方で書いてたプログラムを、昨日Linuxでコンパイルする必要が出た。同じコードをかなり前のバージョンだが一度Linuxでコンパイルしたことがあったので、そう面倒なことも発生せずにコンパイルできるだろう、と、思ってやってみたら、山のようにエラーが出た。どうも、僕のtemplate classの書き方をg++が気に入らないようである。そこで、その予想が正しいかどうか、短いテストプログラムを書いて実験してみた。

#include <stdio.h>

template <class T>
class A
{
    public:
    T test;
};

template <class T>
class B : public A <T>
{
public:
    void Set(const T &x);
    const T &Get(void);
};

template <class T>
void B <T>::Set(const T &x)
{
    test=x;
}

template <class T>
const T &B <T>::Get(void)
{
    return test;
}

int main(void)
{
    B <int> b;
    b.Set(12345);
    printf("%d\n",b.Get());
    return 0;
}

このプログラムは、旧バージョンのg++ (3.2)で、何も問題なくコンパイルできるし、とくに解釈が曖昧になるような点もない。ところが、このプログラムを新バージョンのg++ (3.4)でコンパイルしようと思ったら、次のように修正する必要があった。

#include <stdio.h>

template <class T>
class A
{
    public:
    T test;
};

template <class T>
class B : public A <T>
{
public:
    void Set(const T &x);
    const T &Get(void);
};

template <class T>
void B <T>::Set(const T &x)
{
    A <T>::test=x;
}

template <class T>
const T &B <T>::Get(void)
{
    return A <T>::test;
}

int main(void)
{
    B <int> b;
    b.Set(12345);
    printf("%d\n",b.Get());
    return 0;
}

コンパイラに責任を転嫁するのは、プログラマーとしては、最後までやってはならないことであるが、この場合は、さすがにこの変更は、意図的に新バージョンのg++に加えられたものではないような気がした。どっちかというとバグのように思えた。が、後になって、実はこの変更は意図的なもので、(http://www.gnu.org/software/gcc/gcc-3.4/changes.html) テンプレート使用時の曖昧さを無くすためのものとあった。これは、悪い修正である。上記のプログラムのように、曖昧さがまったくない場合、コンパイラはそのプログラムをコンパイルできてしかるべきだと思う。新バージョンのg++で無くしようとしたような曖昧さというのは、コンパイラが検出できるものだかが、曖昧さがある場合のみエラーなにウォーニング（ワーニングと読んでいた人は今日からウォーニングと読むようにしよう）を出せばいい。多分C++の仕様を決定している人や、g++の開発に従事している人は優秀な人が多いのだろうと思うのだが、あまりにもたくさんの優秀な人が集まると、おかしな結論に達する場合があるといういい例だと思う。と、愚痴っても仕方ないのだが、このg++の最新版に加えられたおかしな変更に対応するために不必要なtype specifierをコードの各所に追加するために、昨日は貴重な数時間を無駄にしてしまった。（数時間で済んでよかったけど）