日付：2000/1/3
SETI@Support-part15(Ver0.72)さて、メーリングリストにはなばなしく「Ver0.7をリリースしました」とアナウンスした直後に私は自分の間抜けなバグに気がついた。今回のバージョンアップで、ウィンドウは最大３っつひらくことになった。そして私はいつもそれらのウィンドウを一定の配置において使っている。
ふたつの間はSETI@Supportを立ち上げるたびにウィンドウを開いていたが、どうもこれは面倒だ。というわけで開いていたウィンドウは記録して於いて自動的に開くようにしたのである。
さて、これはうまくうごくように思われたが、不思議なことに新しく付加したGaussian Distributionのテーブルはうまく動くこともあるし、そうでないこともある。うまくうごくときはいいのだが、そうでないと左上の隅に移動してしまう。となるとここはメインのウィンドウがある位置なので重なってしまい、観にくいことかぎりがない。
あれこれやってみたがどうも原因がつかめない。まあいいや、と思ってリリースしたら、その直後に自分がいかに馬鹿なことをやっていたかに気がついた。かくのごとく何かおかしな点があったら見過ごす、というのはあまり賢明なことではない。それには（大抵の場合）れっきとした原因があるのだ。
さて、そうしてVer0.701をリリースしたあと、私は妙な考えに（またしても）とりつかれた。SETI@Supportのダウンロードページには以下のような注記がつけられている
「表示内容は本家本元の解析プログラムにだいたい合わせてあるつもりです。。（従ってwork_unit.txtとかstate.txtにはあるのだけど、表示を省いてある内容も多々あります）」
この文章だけ読むと、あたかもデータはすべて記録しているが、表示だけを省いているように読める。しかし実は表示していないデータは記録していないのである。
当初このプログラムを作った時は「意味がわからないものは記録も表示もしなくていいや」と軽く考えていた。しかしながら私の頭にふと疑念がよぎったのである。SkyMap上に解析済みのマークであるとか解析中のマークであるとかを表示しているが、これらの本当の大きさはどれくらいなのであろうか、と。今の表示は画面上のピクセル数で指定をしているから、視野角をかえても大きさは変化しない。しかし本来であれば視野角を狭くすれば、観測している範囲の表示は大きくなるはずだ。
ではどうすればいいか？SETI@homeが使っているデータの中には、解析しているデータの始点の位置とともに終点の位置もある。実は最初にこのプログラムを作りはじめたときに
「おお。位置データが二つあるぞ」
と思った物だが、まあ始点だけ記録すればいいや、と終点の方は忘れていたのである。
さて、それから月日は流れて幾星霜。SETI@homeのWeb Siteであるプログラムが公開された。これはDistant Sunという星図の表示プログラムらしいのだが、SETI@home用に特別に改訂されたバージョンがダウンロードできるようになったのである。さっそく落としてつかってみると「あんたが解析しているデータの位置はここだよ」と表示される。そしてその「位置」というのは直線なのである。
なるほど。やっぱりあの始点と終点には意味があったわけね。。。と思ってから数ヶ月私はまたその考えを頭の隅においやっていた。
ところがなんのきっかけかわからないが、再びそのアイディアが頭に飛来したのである。世の中にあまた存在しているSETI@home用の解析支援ツールでは、ワークユニットの位置は始点だけで表示している物がほとんどだ。（I4WUのように表示はしていないが、ちゃんと記録しているものもあるが）これにはちゃんと理由がある。他のツールの作者が皆私のように
「よし。観なかったことにしよう」
とわりきったわけではない。他のツールは私が知っている限り一つのものを除いてSETI@homeのサイトにあるSkyMapの上にデータの位置をプロットしているからだ。あのSkyMapの上に始点と終点をちゃんとプロットしてもほとんど単一の点のようにしか見えない。
しかしながら、Ver0.5からSETI@Supportに付加した機能を使えば、そうした問題はなくなる。視野角は或範囲で自由に変更できるから、拡大すればちゃんと始点と終点を結ぶ直線が見えるはずだ。
さて、その考えにとりつかれること数日。私はしょこしょことプログラムを改修しはじめた。理論的には取得するデータの項目を増やすのは簡単なはずだった。げんにVer0.6でGaussianのパターンデータを追加したときは（後でアゴがはずれるようなバグが発見されたとはいえ）簡単にできたではないか。
ところがこれは恥をさらすようなことだが、この改修が自分が思ったよりは時間がかかったことをここに書かなくてはならない。理由は簡単だ。SETI@Supportで解析したデータのなかで要になるもの、つまり「これだけは必ず存在していること」というデータはワークユニットの名前（たぶんこれは一意につけられているのではないかと思うから、本当に考えればこれが要になるべきだ）ではない。始点の位置情報である。最初このプログラムを作り始めたときは
「SKyMap上にプロットすることが重要。だから位置データがなければデータじゃない」
と思いこんでいたのである。
さて、この勝手な思いこみに起因する問題というのは、幸いなことに今まで発覚しなかった。ところが終点のデータを始点のデータと同じ扱いで追加したとたんにあちこちでプログラムがクラッシュし始めたのだ。始点のデータは必ず存在していたからNull（空だと思ってほしい）になることがなかったが、終点のデータは今まで記録していなかったからNullであることのほうが多いのだ。しかしそれを考えていないとプログラムはコンソールに
"Null Exception Occured"
という無情なメッセージをだして止まってしまうのである。
自分の愚かさを呪いながら（このプログラムを作り始めてからこの呪いの言葉を吐いたのは何度目だろう）格闘すること数日、ようやくなんとかプログラムは動き始めた。とはいっても終点を記録できるのはこれから新しく解析するデータだから、しばらく解析を進めないとデバッグすら容易にはできない。
そんなことをやりながら、ふと考えた。いま使い道が思いつかないデータであっても、そろそろ記録だけはしておくほうがいいのではないか、と。近い将来使い道に思い当たるかもしれないではないか。今は書き方がわからないGaussianのカーブもいつの日か描けるようになるかもしれない。しかしそこからデータの記録を追加したのではまた今と同じ様な「しばらく解析しないとデバッグも出来ない」状態に陥ってしまうわけである。
そう思うと今度はとりあえず意味がありそうな（と推測がつく）データをかたっぱしから記録するように変更しはじめた。従ってVer0.72からss_current_data.txtやss_past_data.txtの中身をみる奇特な人がいれば「なんだか項目が増えているな」と気がつくはずである。これらの余分な項目が役立てられる日がくるのかこないのかは、（その本質がなんであれ）時間だけが教えてくれる。
さて、本来であればこの時点で「よし。今度は機能追加をだいぶしたからちょっと番号をあげてVer0.72でリリースだ」となるはずである。ところがそうは簡単に話は進まなかった。
今回始点と終点を結ぶ線の表示を追加した。この線というのは、データで観ているだけではわからないが結構方向があれこれだったり、長さがあれこれだったりするのである。面白い、と言うべきなのかもしれないが、私としてはプログラムに自信がないので「ひょっとしたらまた何か馬鹿な事をやっているのかもしれない」と不安になり、あれこれ試してみることになる。
そうやって視野角を狭くしたり広くしたり、あっちのモードで表示したり、こっちのモードで表示したりをやっていると、今まで
「観なかったことにしよう」
と絨毯の下に隠していた問題があれこれ目につき出すのである。
実はVer0.6シリーズを作っているときからあれこれ気になりだしはしていたのである。主な問題は二つあった。
一つは所謂クリッピングである。なんのことかと言うと、描画している範囲からはみ出した直線をどうやって表示しましょう？というやつである。Ver0.5を作っているときは「とにかく表示ができればよい」とこの問題に対しては実に妙な方法で対処した。直線のどちらかの端の点が画面からはみ出していればその直線は表示しないことにしたのである。
確かにこの方法は簡単だし、はみだして直線を表示することもない。しかしながらこの方法では画像を拡大していったときに直線を消しすぎることになる。たとえば長い直線の一部に表示領域がひっかかっていた場合でもこの方法では表示されない。星座の線くらいだったらまあ我慢できないこともないのだが、肝心な観測領域も同じ理屈であまり解像度をあげると表示されなくなってしまう。これではなんのために機能を追加したのかわからなくなってしまう。
もう一つはかなりやっかいな問題だ。これは２Ｄ表示では左右の端が（場合によってだが）画面上では離れていても実は繋がっていることに起因する。たとえば短い直線を定義していたとして、その間に左右の端のつなぎ目がきたとしよう。この場合、直線の両方の端は画面の右と左に泣き別れることになる。そしてその間を素直につないでしまうと短いはずの直線が、画面の右から左まで達する大変長い直線になってしまうのである。
何故この問題がやっかいか？そもそも直線というのは二つの点を結ぶ線だから、データとしては二つの点の座標を持っている。しかしながらこれは円筒に点を打ったとき考えればよいのだが、２点を結ぶ直線というのは果たしてその２点を通る楕円（または正円）のうちどの部分をさしていうのか？という問題である。たとえば「これは短い直線だ」としてデータを入力したつもりでもプログラムの側からみればそれを「長い直線」と区別する方法がない。
さて、この問題にはVer0.5のときにつきあたっていた。座標軸を示すだけの短い十字が、視点の置き方によってはいきなり画面を横切る直線にばけてしまうからだ。そこで私は複雑怪奇な関数をつくりあげた。そしてまず最初にやったことは、この関数をすべての場合に適応することだった。それによりおこったことは、こうした「直線の長短混同」の問題がおきないはずの描画モードでもこのチェックをいれたがために描画速度が低下する、という問題だった。
Ver0.6シリーズの最中にこの問題には気がついた。そこで本来の目的どおり２Ｄ描画の時だけに適応するようにしたのである。しかし問題はもう一つあった。本来視点と１８０度反対の線を直線が横切っていなければこの問題はおきないはずである。しかし何故かしらないが私がつくりあげた複雑怪奇な関数は、視点と同じ経度座標を横切る直線はかたっぱしから「これは表示できませーん」とはねていたのである。起こることは「だいたい星座の形はちゃんとしてるんだけど、なんだか真ん中のへんで変だな。。」という状況である。
さて、私は新しく追加したデータをちゃんと表示したい、という現実の欲求と、それまでいいかげんにやっていた表示をそろそろちゃんとしたい、という良心の（私にも少しではあるが、そうしたものが存在しているのだ）叫びによってあれこれやりはじめた。
まず２番目の「直線の長短混同」の問題だが、本来はもっとスマートな方法があるのかもしれない。しかし私はここで大胆な仮定を導入したのである。曰く「直線というのは経度方向に１８０度以上にわたってひかれることはない」というやつである。この仮定を導入すると１８０度以上の線をひくのは、どこかおかしい。線を引くとすればそれは１８０度以下になる方向だ、という方針が得られる。そう考えて自分がつくった「直線の長短判断ルーチン」を観てみると、これは何をしているのかさっぱりわからない。今までも何度か遭遇したことだが、仮にうまく動いているように見えても、自分が何をしているかさっぱりわからない関数というのは破棄して一からつくりなおしたほうがましだ。そう思ってあれこれ作ってみるともともとあった関数の半分くらいの大きさでなおかつちゃんと動く（と少なくとも私は今のところ思っている）関数ができあがった。そのうち本当に１８０度以上にわたる線をひきたくなることがあるかもしれないが、まあそれはそれ。これで問題の一つは解決だ。
さて、もう一つのほうのクリッピングはなかなか一筋縄ではいかなかった。JavaのAPIを調べてみるとちゃんとsetClipなる関数が存在している。それをみつけた私は大変ご機嫌になった。なんだ。これをちゃんと設定すれば万事OKではないか。ところがそう思って動かしてみるとどうも時々妙なところで妙な直線が表示されるのである。
最初は前述した「直線の長短混同」の問題かと思ったが、どうもそうでもなさそうだ。信じられないほどあさっての方向に直線を描画しようとしていて、それがちょっと変な形で画面上にひっかかっているような様子である。となると理由はわからないが、私が愛し始めていたsetClip関数は私が期待したような動作をしていないことになる。
そのうちもっと深刻な問題にぶつかった。Macintosh上では問題ないのだが、WIndows-NT上で画面描画モードをVector-2D,Vector-3DからVector-Sphereに切り替えたときのことである。いきなりプログラムの動きがとまった。ただSETI@Supportが凍り付いただけではなく、パソコン全体の動きが亀のように遅くなった。なんだこれは？としばらくばたばたしたあげく、判明したのはJavaがCPU時間をほとんど占有してしまっている、という事実だった。強引にタスクを終了させてみたが、原因はわからない。今のは観なかったことにしようと思って再度リブートして同じ操作を行ってみたが起こることは前と同一である。となれば何かがおかしい。
この問題の原因はおそらくまたもやsetClipが働いていないところにあった。細かい説明ははぶくが、他の描画モードからVector-Sphereに移動するとき、とてつもない座標値をもつ直線を引こうとするのである。私が期待していたのは、どんな数値がはいっていてもsetClipの神様がなんとかしてくれることであったのだが、実際には彼（もしくは彼女）はそこまでの処理をしてくれず、律儀にとんでもない長い直線を引こうとして、それを書くべきとんでもない巨大な紙（実際にはメモリだが）を用意しようと、しゃかりきになってCPUを酷使していたのではないか。
しょうがないから自分でクリッピングをしてくれるルーチンを追加した。（とはいってもインターネットでみつけた関数を参考にしたのだが）これを入れると若干描画が遅くなった気がする。しかしとりあえず星座の一部を拡大してもちゃんとしかるべき範囲までは表示してくれるようになったのは確かだ。。。。などとまとめて書くとあたかも一直線に問題解決に進んだようだが、実際にはそれほど話は美しく進んでいない。一旦setClipの神様におすがりし、次に自分で関数をつくり、その後「setClipの神様にとなえる呪文が間違っていたかあ」と思い自分がつくった関数をお払い箱にし、それでも問題が残っている事に気がつき、再度setClipの神様を見放し、、といった状態である。
さて、これを書いている時点ではまだVer0.72は公開されていない。たった0.19バージョン番号をあげるだけなのにもう数週間にもわたって試験と改修を繰り返している。ここで今までないがしろにしてきた問題に立ち向かい、かつデータ取得項目を増やしておくことは今後のバージョンアップのベースになってくれるといいのだが、、さて次は何をしようか。。
などと考えている間に私はまた恐ろしい考えにとりつかれた。
元はといえば、
「ちゃんとデータの位置が表示されているか確かめてみよう」
と思い、Distant Sunというプログラムを立ち上げたのがきっかけである。これは本来シェアウェアか何かなのだが、SETI@home用の特別バージョンが公開されていて、誰もが使うことができる。そしてこのプログラムでは（0.72のずっと前から）ちゃんとStartとEndのデータを反映したデータの位置が表示されるのである。
さて、最初はWIndowsバージョンだけが公開されていたが、久しぶりに覗いて観るとMacintoshバージョンも公開されており、おまけにMacintosh版はCient Ver2.X対応となっている。となれば公開した後にへそを噛むような思いをするよりは、公開前にこのプログラムと表示の一致性を確認しておいても損にはなるまい。
そうおもって立ち上げてみると、妙なことに気がついた。正確に言えば妙なことではなく、私も薄々は気がついていたことだったのだが、Distant Sunでは私がしていたようにStartとEndのポイントを線で結ぶだけではなく、ちゃんと一定の幅をもった範囲として表示していたのである。
うげげげ。やはりこのように表示するべきであったか。。とかなんとか思いながらこれまた一時は
「みなかったことにしよう」
と思ったが、なかなかそうもいかないようである。この「幅」が実に狭くて「直線でもいいや」と思えればいいのだが、そういうわけにもいかない。
となると結局またリリースを延期して直線ではなく四角で表示できるように改修である。これまたデータの追加になるので、また「直前のデータ書き換え」のようなことがおこらないようにあれやこれやと試験もしなくてはならない。最初はこの「幅」をいくつにしたらよいかでだいぶ悩んだ。SETI@homeのWeb Siteには「ビーム幅は０．１度」なる記述があるのだが、そもそもビーム幅の定義からしてよくわからない。中心から左右にはかった角度なのか、それともトータルの角度なのか。
そのうちDistant Sunと同じでいいや、と思い画面上でだいたい同じになるようにしてある角度を設定した。ところがビーム幅の定義が判明してみると、どうやら０．１度というのはDistant Sunで表示されているものの半分しか幅がないのである。どうしたものかとずいぶん迷ったが素直に０．１度で表示することとした。
さて、デバッグもかねてこの状態でしばらく動かしてみると、送られてくる解析データというのは思ったよりもその始点と終点の距離がばらばらであることに気がつく。数値上始点と終点の距離が同じものもあれば、数度にわたっているものもある。今まであれこれみたところでは、普通の解像度ではっきり直線と認識できるほど始点と終点が離れている物はどうやら「空ガウシアン」、つまりガウシアンが見つからないことが多いようだ（というか今のところはすべてそうだ）
SETI@homeのWeb Siteの記述を見る限りでは、アンテナが位置を変えるときのデータでは所詮ガウシアンは見つからない、と書いてある。そうであればそうしたデータは最初から送らなければよいと思うのだが、そうも行かないのだろう。
さて、自分で作った機能を使いデータを表示させてみると、自分が今までに解析したデータの範囲が以下に狭い物であるかわかる。今のところ面白い信号がみつかったという話も聞こえてこないし。そろそろ１周年を迎えるこのプロジェクトは今後どのような経過をたどるのだろうか。
注釈