FGALDC 15
/RE:14180 RE:バグは完璧に取れない

　こんにちは、Emmettさん

バグのないことの証明はできない、なんてよく言われますけれどね。


》》訳ですよね？そのアルゴリズムを理論として公表することによって、間違いがあ
》》るかどうかチェックすることができるのではないでしょうか。
》　なかなかそう行かない場合が多いでしょう。理論的には合っていても、ケアレス
》  でしょーもないバグが入り込むことは、いかにプロでも避け難いと思います。早

まず、仕様にバグがあるかどうか、と言う検討があります。
学術的なものであれば、理論に間違いがないか、ということも必要でしょう。
#14099 でのお話での、全く新しいものを発見した、ということを言っても、こ
の段階でチェックできるのではないか、と言うのが私の意見だったりします。

逆に、実験科学と言う観点で、実験の代わりにシミュレーションを行い、それら
の結果から一つの理論を導き出すと言うのであれば、たしかにバグの発見は困難
だし、「一見本当らしいけれど意図的に自分の好みの結果」を出すようなプログ
ラムを作ることも可能でしょう。
でも、他者は検証をしなければ、肯定も批判もできないような気がします。
＃って言うか、それをしない人を科学者とは呼びたくないような。

つまり、シミュレーションが先にあったとしても、理論が発表された時点で、そ
れに基づいて別の人が別の場所で別のプログラムを作り実行させることにより、
結果の検証ができると思います。


実はこのあたり、苦い思い出があって、少々過敏になっています。
以下、ちょっと昔話をさせていただきます。

大学の卒業論文だったのですが、あまり使われていない数値解析の手法の、電磁
界への適用の検証のようなことをやっていました。私は数学はからっきしだめだ
ったので、共同研究者の解いてきた偏微分方程式をプログラム化することを担当
していました。マクスウェルの方程式とかなんとかいうやつです。
ところがプログラムを実行すると、結果が収束しないことがある。結果が収束す
るときには、ほぼ理論値と誤差程度の違いしかなかったので、うまくいったやつ
だけを使ってとりあえずは論文を書き始めました。
ただ、理論的には必ず収束しなければいけないわけで、論文があらかた書き上が
ってからプログラムの精査をしました。そうしたら、大きなやつが１匹いました
ね、バグ様が。何と、誤差の補正項の符号のプラスとマイナスの間違い。

発見できたのは、卒論の締切１週間前。
それからの１週間、計算のやり直しでおおわらわでした。
論文の方があらかたできていたのがせめてもの救いでしょうか。


》  い話が、 ＶＺで言えば (n)?{ ... } を (n){ ... } と書いてしまう類のミスの
》  場合、相当注意して探してもなかなか気がつかないこともあります。これだけの
》  ために数時間を無駄にしたことが、今までに何度あったか (^^;

私の場合、境界条件なんかでいつも悩んでいます。
たとえば、比較の部分で (r<=5) とかっていう場合、等号は必要なのか不要なの
か、と言うようなことです。解決策は大抵の場合、実行させて結果を見る、とい
うことだったりします。


》　ましてや、僕のマクロなんか数百行ですけど、プロのプログラムは数十万〜百万
》  行なんて珍しくないですからね。いかに可読性を高めても、チェックするには莫
》  大な時間がかかるでしょうね。

だから、モジュール化して一度にチェックする範囲を小さくするとか、いろいろ
なワザが開発されてくるのでしょう。
この辺、多分ソフトウェア工学の話だと思います。
私には縁のない世界だと思っております。
                                                           としき