「科学者は研究に使っているコードを公開すべき?」記事へのコメント

公開したくないなぁ

[Anonymous Coward]

基本的に自分とその周辺しか使わないし、たとえメモリリークなんかのバグがあってもアウトプットが正しければ良いので、やっつけ仕事、コピペ継ぎ接ぎのかたまりです。
議論で公開しろと言われれば、しますけどね…
公開するならもう少し綺麗なコードにしたいし、その時間があるなら別のことをしたいというのが本音。

一応、プログラムが正しい結果を出すことはチェックしている…つもりなんですが…
学生さんに渡したプログラムに、卒論提出直前にとんでもないミスが見つかったことがあります。

Re:公開したくないなぁ

[Anonymous Coward]

しばらく前の IEEE Computer Magazine に載っていた記事の受け売りです．職場に置いてあるので，何号の何ページなのかが確認できませんが．

普通の文脈で言うソフトウェアの品質には，クラッシュせず安定して動作すること，ユーザインタフェースが一貫していること，保守しやすいことなどがあります．これらは，一般的なユーザが使用する際に戸惑わないことや，ユーザの新しい要求に応えるためにソフトウェアを変更しやすいことなどを表わす基準です．

一方，計算結果を人間が読み，何らかの判断を下すためのアプリケーションには，「計算結果が間違っていないこと(*1)」が最も強く要求されます．次に重要なのは，「必要な時までに計算結果が得られること」です．記事では，気象予報や経営判断などが例として挙げられていたと記憶しています．このようなアプリケーションを使うのは慣れている人間ですから，ユーザインタフェースが使い難いことや，クラッシュすることは大きな問題になりません．また，アプリケーションがクラッシュして計算結果が得られなかったとしても，間違った計算結果が出力されるよりは良いという判断がなされます．
(*1) 誤差が既定内に収まっていることを含む

もちろん，2種類の品質基準には正の相関があるでしょう． しかし，前者の品質が改善されるように開発プロセスを最適化しても，後者の品質が改善されるとは限りません．

おっしゃっているように，メモリリークのような計算結果に影響しない欠陥は，後者の品質に影響を与えません． ですから，あえてメモリを回収するコードを記述しないという判断は，場合によっては正解ということになるでしょう． なぜならば，複雑なデータ構造に使用したメモリを安全に回収するコードを書くのは難しいので開発時間がかかりますし，他の欠陥を埋め込んでしまう可能性もあるからです． また，回収の仕方によってはプログラムの実行時間に大きな影響を与えてしまいます．

Re:公開したくないなぁ

[Porch (20045)]

＞メモリリークのような計算結果に影響しない欠陥
　この辺りがすでに間違った認識なんじゃないかな。

　メモリリークしている領域に、他からアクセスしていないという確証が得られるまで、メモリリークしないように作るべきだと思います。
＃メモリを確保したら、次行は解放する処理を書きましょう。
＃確保した領域への処理はその間に書けば良いのです（プログラムにもよりますが・・・）
＃並列処理を行う場合は排他処理を適度に入れましょう

　たまたまうまく動いているように見えるだけで、実はとんでもない間違いが混入している可能性はできるだけ排除すべきだと思いますが、研究者は計算が間違っていても気にしない人が多いようですね。

Re:

[Anonymous Coward]

アクセスしてるならリークじゃないでしょ
プログラムの検証と計算の検証を混同しちゃいけない。

計算結果が正しいかどうかの評価はプログラミングにミスがあるかどうかに関係なく行うべきだし、
またその計算が正しかったとしても、それがプログラミングにミスが無かったことを意味するわけではない。

Re:

[Anonymous Coward]

> 実はとんでもない間違いが混入している可能性はできるだけ排除すべき

「できるだけ排除すべき」なのは，その通りです．問題は「できるだけ」の部分です．
有限の労力で全ての欠陥を取り除くことは出来ません．
ですから，アプリケーションの種類によって，優先して取り除くべき欠陥が異なるのです．

これは，先に例として挙げた判断用のアプリケーションに限った話ではありません．
例えば，銀行の基幹システムと，自動車の制御システムでは，問題となる欠陥が異なります．
銀行の基幹システムではデータを失なったり壊したりしないことが最優先であり，自動車の制御システムでは安全性が最

Re:

[Anonymous Coward]

開放してればSegmantation Faultかなんかのエラーで一発で検知できるよね。
少なくとも誤った結果を正当なものと誤解するリスクは回避できる。

Re:

[Anonymous Coward]

必ずしもSegmentation Faultが出るとは限らないでしょう。
「少なくとも誤った結果を正当なものと誤解するリスク」はどうやっても出ますし、それを回避するには結果を慎重にチェックするしかないのです。
メモリを解放すること自体にリスクがある以上、どちらが正しいとは言い切れません。

Re:

[Anonymous Coward]

メモリを開放することによるリスクって何でしょ？
たまたまうまくいっていた計算がうまくいかなくなること？

Re:

[Anonymous Coward]

あなたは、グラフの任意のノードを、 dangling pointer を発生させず、時間と空間のオーバーヘッド無しに回収できるのですか?
# もしそうなら、今すぐ Microsoft か Sun に行って、言い値で雇ってもらってください。

Re:

[Anonymous Coward]

プログラム終了時まで gc が起動しないだけだ。

gcのある言語で書いてると思えば、目くじらたてるほどのこともない。