科学者は研究に使っているコードを公開すべき? 148
ストーリー by soara
論文妥当性の検証にコード査読も必要か 部門より
論文妥当性の検証にコード査読も必要か 部門より
あるAnonymous Coward 曰く、
科学者はその研究で使っているプログラムのコードを公開すべきであるとの主張が英Guardian誌で取り上げられている(本家/.より)。
このコラムで Open Universityの Darrel Ince教授は特に最近の気候科学分野での論争に言及しながら、コードが公開できる状態にあるのにそれをしぶる研究者は科学者と見なされるべきではないとまで述べている。
教授曰く「科学分野で使われているソフトウエアを憂慮すべき証拠は十分にある」とのこと。ソフトウエアテストの国際的な専門家であるケント大学の Les Hatton教授が何百万行に及ぶ科学分野のソフトウエアコードを分析したところ、多くの矛盾点が検出されたとのこと。例えばプログラム内のモジュール間インターフェイスでは、Fortranで書かれたプログラムにおいてはインターフェイス 7つあたり 1件の割合で矛盾点が見つかったとのこと。Cで書かれたプログラムでは 37インターフェイスあたり 1件の問題が発見されたという。たった一つのエラーがその立証力を無くさせるのに十分であると考えると、非常に憂慮すべき事態であると教授は指摘しているそうだ。
クライメートゲート事件 (スコア:4, 興味深い)
クライメートゲート事件ですね。
> １月１８日、英国のイーストアングリア大学にある「気候研究所」（ＣＲＵ）のサーバーがハッキングされ、
> １０００通以上の電子メールや、プログラムのスクリプトなど電子文書類が、
> 何者かによってネット上に公開された。その公開されたメールやデータを分析することにより、
> ＣＲＵなどの研究者たちが、温暖化人為説を根拠づけるため、
> さまざまな歪曲や論敵つぶしを展開してきたことが明らかになりつつある。
> 今回、ネット上で暴露されたＣＲＵの文書は、約１０００通のメール以外に、
> 多くのコンピュータープログラム（フォートランやＩＤＬなどのソースコード）のスクリプトが含まれている。
> yrloc=[1400,findgen(19)*5.+1904]
> valadj=[0.,0.,0.,0.,0.,-0.1,-0.25,-0.3,0.,-0.1,0.3,0.8,1.2,1.7,2.5,2.6,2.6,2.6,2.6,2.6]*0.75 ; fudge factor
> という２行がある。
> これは「誤差」（fudge factor）と注釈がつけられているが、
> 処理の内容は、１９０４年から９４年（データの最終年）までを５年区切りにして、
> その２０個の各年の温度変化に対し、個別に数字（温度）を加算し、
> 現在に近づくほど加算値を大きくしている。
> つまり、現在に近づくほど気温が上がったように、結果を歪曲している。
地球温暖化めぐる歪曲と暗闘（１） [tanakanews.com]
Re:クライメートゲート事件 (スコア:3, 参考になる)
ソースの中から 2行だけ抜き出して何かわかったような気になるのは、やめたほうがいいと思いますよ。
http://www.jgc.org/blog/2009/11/very-artificial-correction-flap-looks.html [jgc.org] で、そのコードを調べた結果が解説されているので、それを読んでからにしてはいかがですか。年輪から推定される温度と実際の温度が昔はあっていたのに最近になってずれている現象について述べた論文で、どれだけずれているかを示すために使われたコードで、気温を歪曲するのに使われたものではないというのが結論です。
Re:クライメートゲート事件 (スコア:1, 興味深い)
当の本人達やその周りは
>たった一つのエラーがその立証力を無くさせるのに十分である
とは考えてないんですけどね。大筋には問題無いとか堂々とほざいているわけで。
藤村新一よろしくあんなことやったにも関わらず研究者そのものの生命が断たれていないって不思議！
fudge (スコア:1)
Re:クライメートゲート事件 (スコア:1, オフトピック)
> ＣＲＵなどの研究者たちが、温暖「擬人化」説を根拠づけるため、
に見えてしまった。
オフトピになるけど「温暖化」っていい事のように聞こえるよね。すみやすい環境が増えるだけじゃん、って。
「温暖」の持つイメージってそういう方向だと思う。
そういう言葉を意図的に選ぶことで真剣みを削いで商業化しやすくしているんじゃないかと。
「熱帯化」だともうちょっと危機感があるような気がしない?
四色問題はあまり良い例ではない (スコア:3, すばらしい洞察)
元のコラムではプログラムを公開して成功した例としてApelとHakenによる四色予想の証明をあげているけど、良い例ではないでしょう。あの論文の本文でアルゴリズムの詳細は解説されているし、ジャーナルの付録としてマイクロフィルムがついていてそこにデータは全部入っていたから、たとえ原プログラムを公開しなくても、独立した実装による追試が可能な状態でした。むしろ、原プログラムを参照しない独立した実装で追試を行ったほうが、原プログラムを検証するよりも強い支持を得られますよね。
例の一つを例になっていないよと言っているだけで、元の主張全体を否定するものではありません。念のため。
Re:四色問題はあまり良い例ではない (スコア:2, 興味深い)
の両方なんだけど、検証には2だけ必要で1は不要であることにご注意ください。 1のプログラムはヒューリスティックの塊になって書くのは大変で、だからApelとHakenは試行錯誤を繰り返したのだけど、それが終わった後で2だけを再現するだけなら、実はそんなに難しくありません。当時の状況としては、プログラムを書いたとしてそれを動かすことの出来る環境を手に入れるところで、一部の恵まれた人以外は苦労するでしょうけど。
公開するべき場合とそうでない場合をまず分けよう (スコア:3, すばらしい洞察)
なにがそれを分ける基準かというと，コードを公開しないと信じて
もらえないかどうか，そしてそこまでして信じてもらいたいかどう
かだと思う．
30年後の地球の気温のように，誰にも答の分からない問題を予測し
た場合，予測に用いたコードが正しいかどうかは見てみないと分か
らないだろう．そして，それが各国の政策にまで影響が及ぶとなれ
ば，なおさら公開の必要ありと考える．
一方，シミュレーションの結果新しい現象が予言され，それが実験
で確認された場合などは，シミュレーションコードそのものがその
研究者の武器なのだから，オリジナリティを維持するために公開し
たくないだろうし，コードが正しいかどうかは「余計なお世話」だ
ろう．
研究が公費で行われたなら全てを公開するべきだという考えはちょ
っと極端に走りすぎという印象．一方で研究は競争でもあるわけだ
から，相手に手の内を晒したくないことは多くある．
実際にあった話 (スコア:2)
学生時代に、同じような内容の研究を2名でやった（うち1名私）。もう1人の方は、プログラミングも初心者。で出た結果は、そいつの方がよかった。
研究室（というか担当教員は）そいつの方のコードを正しいと採用しました。5回中3回、Segmentation Faultで止まるのにね・・・期限直前にバグだと騒ぎだし3年間の締めくくりが、大変なことになってた。
それこそ、世界レベルで検証を行うような、トップレベルの研究内容じゃない限り、プログラムの質ってこんなもん。
-- gonta --
"May Macintosh be with you"
とある技術について研究していた時 (スコア:2, 興味深い)
詳しい内容を書くのはあれなのですが、特許になっていたとあるアルゴリズムを追試して応用をしてみようと思ったわけです。
特許の内容そのものはかなりしっかり書かれてまして、それを仕様書としてソフトウェアに落とすのは楽でした。
それは、通常では検知できない部分にあれこれして品質を上げるというものでして、すでに複数の有名企業に採用されているようなものだったのですが、少し条件を変えてあれこれしている部分を検知できるようにしますと…
品質を上げたとされる場面でも実際にそうだったかどうか疑われるようなものでした。そのようなわけでその特許を採用するのを見送りました。
このようなときに元ソースを入手できたらこちらで作ったものとの差異を比べてより正確に評価できたんでしょうが、出力が同等だったとしたら…効果を信じ込ませて売り込んだだけのオカルト技術だったのかもなと思ってしまいます。
アルゴリズムのみ公開されている場面では、出力の同一性と評価環境の評価がそろわないと信用できないですね。出力だけで一目瞭然というものならともかく。
Re:とある技術について研究していた時 (スコア:2, すばらしい洞察)
特許法には
と定められていますから、明細書の内容を読んでアルゴリズムを理解し、実装できたというのは特許の趣旨に十分沿っていますよね。
特許が製品の品質や性能を保証するようなものだと思っている方が期待しすぎなのではないかと。
コード公開を成果に数えてくれるならねｗ (スコア:2, 興味深い)
まだ発表できてない研究に関するコードが山ほどあるんで
公開コードが成果実績に数えられるなら喜んで出すよ！ｗ
知的クラスター創生事業での経験だが
採用面接や部内のミーティングでは開発しろ、事業化だとうるさくと言うくせに
採用時にも給与にも開発成果についてなんら配慮してくれるわけじゃない。
事業化をエサに企業から研究予算を取れと
公共部門の研究費がグイグイ絞られてる昨今、
企業へもっていってデモするわけだが
「（商品に比べて）完成度が低い」とダメだしされる。
…そらそうだろ、開発にかかわってる人数が1/10～1/100だよ？
その上、その開発にかかわってる人間は開発したソフトウェアで評価されるわけでなく
論文で（それも大概はその数で）評価されるわけで…。
（で、その論文にまとまるところまでの食い扶持が足りてないから売り込みにきてるのだから。）
というわけで成果に数えてくれるなら品質ももうちょっと頑張るし、公開だってOKさ！！！！１！！！
＃なのだが我々はそれ以前の状況にある。
＃期間が短く、運任せで先の読めない予算・研究費、
＃その予算の切れ目が雇用の切れ目、
＃万が一雇用が切れても発表できるところまでコードが触れて研究を続けられるように
＃という理由を挙げてオープン・ソース化を進言したよｗ
共通のもの (スコア:2)
こういうのに参加したことはないですが、共通で使えるものってのは無い物なんでしょうか？
自分の身近で言うとLinuxだったりApacheだったりするわけですが、そういうのがあればコードの不具合によるロスもなくせる上に
コードを記述する時間を研究に使えたりしていいんじゃなかな～と思ったり。
研究ごとにやることが違うので共通化したりというのは出来ないのかもしれませんけど。
#畑違いのヤツが何言ってんの？とか思われるかもしれませんが・・・。
公開したくないなぁ (スコア:1, 参考になる)
議論で公開しろと言われれば、しますけどね…
公開するならもう少し綺麗なコードにしたいし、その時間があるなら別のことをしたいというのが本音。
一応、プログラムが正しい結果を出すことはチェックしている…つもりなんですが…
学生さんに渡したプログラムに、卒論提出直前にとんでもないミスが見つかったことがあります。
Re:公開したくないなぁ (スコア:5, 興味深い)
この「正しい」が何を根拠なのかが問題なのだと思いますよ。
自分が「正しい」と思っている結果が出てきているというだけで、本当に正しいかどうかは分からない。
もしも、自分の予想とプログラムの両方が間違っていた場合はどうするのかという問題があります。
この「両方間違い」というのは起こりやすいもので、たとえば、本来あるべき効果や観測量同士の共分散関係などが自分の思考とプログラムの双方に入らないため一見矛盾しない結果を出します。プログラム制作者が現象を正しく理解していなかったのだから当然ですよね。 そんな、いわゆる「間違い」を正すためにもプログラムの公開は最終的には行うべきだと思います。
また、たとえば、理論計算のプログラムに非常に微小なエラーがあって、それは数年先の実験結果がでるまでわからない。
ところが、人間は不思議なもので、数年前からあり、市民権を得ている理論計算が正しいと思い実験結果を信じない。
そのため、実験が正しいことを証明し、理論計算のプログラムのエラーを発見するために膨大な時間と労力が消費された。
なんてことが過去にありますよね。
他にも実験の解析系プログラムにエラーが入っていて、それが微小効果であると数年先まで発見できない、発見されたころは影響が大きくなっている。なんてこともありますし、プログラムの微小なエラーから大発見かなんて世界的に大騒ぎになることもありますよね。
逆に個人的経験も含めますが、プログラムの結果と自分の「正しい」が矛盾していての矛盾を追及したら新しい発見があって良い論文が書けたなんてこともあります。
他にも、個人的経験として、公開されているいくつかのコードにエラーを見つけ、その原因が制作者の思い違いや入力ミスだと思い至ることがありあｍした。
#いま、修正すべきかどうか悩んでいる個所もあります。
#書き換えると影響がでかすぎる一方で、現段階では計算結果には影響がない項目なので緩やかな入れ替えで対処するか
などなど、研究者は決して個人の趣味で研究しているのではなく、みんなから研究資金を得てやっている仕事だと思って、最大限ミスを減らす方向で仕事をすべきだし、そのミス減らしの一つの方法が適切な時期にコードを公開することだと思います。そして、自分は決してプログラムを誤らないとか自分の直感が結果と一致するからＯＫと思わない方が健全だと思います。
ちなみに私は「自明でない部分」はすべて公開して、コードのあるURLとかを論文に書いています。
#決して元投稿の方を非難しているわけではありません、適切な書き込み場所が見つからないのでぶら下げました。。。
Re:公開したくないなぁ (スコア:2, 興味深い)
しばらく前の IEEE Computer Magazine に載っていた記事の受け売りです．職場に置いてあるので，何号の何ページなのかが確認できませんが．
普通の文脈で言うソフトウェアの品質には，クラッシュせず安定して動作すること，ユーザインタフェースが一貫していること，保守しやすいことなどがあります．これらは，一般的なユーザが使用する際に戸惑わないことや，ユーザの新しい要求に応えるためにソフトウェアを変更しやすいことなどを表わす基準です．
一方，計算結果を人間が読み，何らかの判断を下すためのアプリケーションには，「計算結果が間違っていないこと(*1)」が最も強く要求されます．次に重要なのは，「必要な時までに計算結果が得られること」です．記事では，気象予報や経営判断などが例として挙げられていたと記憶しています．このようなアプリケーションを使うのは慣れている人間ですから，ユーザインタフェースが使い難いことや，クラッシュすることは大きな問題になりません．また，アプリケーションがクラッシュして計算結果が得られなかったとしても，間違った計算結果が出力されるよりは良いという判断がなされます．
(*1) 誤差が既定内に収まっていることを含む
もちろん，2種類の品質基準には正の相関があるでしょう． しかし，前者の品質が改善されるように開発プロセスを最適化しても，後者の品質が改善されるとは限りません．
おっしゃっているように，メモリリークのような計算結果に影響しない欠陥は，後者の品質に影響を与えません． ですから，あえてメモリを回収するコードを記述しないという判断は，場合によっては正解ということになるでしょう． なぜならば，複雑なデータ構造に使用したメモリを安全に回収するコードを書くのは難しいので開発時間がかかりますし，他の欠陥を埋め込んでしまう可能性もあるからです． また，回収の仕方によってはプログラムの実行時間に大きな影響を与えてしまいます．
Re:公開したくないなぁ (スコア:2)
＞メモリリークのような計算結果に影響しない欠陥
この辺りがすでに間違った認識なんじゃないかな。
メモリリークしている領域に、他からアクセスしていないという確証が得られるまで、メモリリークしないように作るべきだと思います。
＃メモリを確保したら、次行は解放する処理を書きましょう。
＃確保した領域への処理はその間に書けば良いのです（プログラムにもよりますが・・・）
＃並列処理を行う場合は排他処理を適度に入れましょう
たまたまうまく動いているように見えるだけで、実はとんでもない間違いが混入している可能性はできるだけ排除すべきだと思いますが、研究者は計算が間違っていても気にしない人が多いようですね。
Re:公開したくないなぁ (スコア:1)
> アウトプットが正しければ良いので、やっつけ仕事、コピペ継ぎ接ぎのかたまりです。
ですよねぇ。特に急いで作ったものはその傾向強いですね。
("正しさ"の判定は難しいような気もしますが)
そんなのを公開すること自体あまりうれしくないですし、
もし、査読者がそれのチェックを要求されたりしたら本当に悲惨。
マニアックな内容をマニアックな言語で書いたらマトモに査読できる
人がいなくなったりするかも。>部門名
4 色問題の時みたいな形式で査読するのかな。
てか、検証って意味では論文の記述を基に別のプログラム
を作って同様の結果が得られることのほうが大事だと思う。
(正直、コードを"きちんと"検証するのは難しすぎると思う。)
そういう意味では現状のやり方がそこまで悪いとも思えないなぁ。
論文の内容からそれをできないのならその論文に問題があるってことだし。
# もちろん、公開しろって言われたら初期データ等を含めて公開すべきで
# あるとは思う。その点については異論は無いです。原則公開にしても
# いいけど、単なるゴミ箱になるだけだと思う。
# 初期データとか乱数の発生アルゴリズム、種にも当然依存するから
# 論文の記述から内容を完全に再現できる、とは言えないのも事実…。
# とはいえ、完全に再現しようとすると、コードや初期データはもちろん、
# コンパイラのバージョン、与えるオプションや実行環境(使う CPU 数とか)まで
# 同一にしないとできなかったりするしなぁ…。(場合によるけど。)
Re:公開したくないなぁ (スコア:1)
＞コピペ継ぎ接ぎのかたまりです
うっかり公開するとまずいコードが入っていたなんてことがない様に調べる必要もあったりしませんか？
ランタイムライセンスだけのライブラリを使っていたりとかあると、結構痛いかも。
Re:公開したくないなぁ (スコア:3, すばらしい洞察)
ぜんぜん分かってないってことが分かる。
メモリリークは、途中経過にしろ最終結果にしろ、数値の誤りを意味するものではない。
上出来なプログラムに比べれば、メモリリークするプログラムは実行中により多くの
メモリを要求する筈だが、それを賄い切れる限り、単なるメモリリークだけでは
間違った数値を出力したりはしない。
Re:公開したくないなぁ (スコア:2)
理想的にはその通りですが、現実としてはメモリリークしているようなお粗末なメモリ管理をしているのに間違った数値を出力しないなどという主張には全く説得力がないです。
論文の正当性を主張するのであれば、その論拠としているプログラムも説明可能でなければならないと思います。
メモリリークしているようなプログラムで正当性を説明できるのか、甚だ疑問です。
Re:公開したくないなぁ (スコア:2, すばらしい洞察)
> 理想的にはその通りですが、現実としてはメモリリークしているようなお粗末なメモリ管理をしているのに間違った数値を出力しないなどという主張には全く説得力がないです。
ソースを公開したくないのは、まさしくこういう揚げ足取りへの対応が面倒だと思うから。
Re:公開したくないなぁ (スコア:1, すばらしい洞察)
リークが発生しているからこの結果は間違っている、信用できない、と言う主張の方が説得力がありませんよ。
Re:malloc and free (スコア:2)
意図してfreeしない仕様になっているのならば、それはメモリリークではありません。
freeしているはずがfreeされていないから、メモリリーク(メモリが漏れている)と呼ぶのです。
Re:公開したくないなぁ (スコア:2, すばらしい洞察)
>単なるメモリリークだけでは
メモリリークなんか...メモリリークに限っていないことをまずは、考慮すればよろしいでしょうね。
Re:公開したくないなぁ (スコア:1)
君こそバグの恐ろしさを判っていない。
メモリリークのあるところ、ポインタ操作の間違いアリ、だ。
演算対象や、保存先のアドレスが正しくなければ、数値演算の結果の正しさは保証できん。
fjの教祖様
Re:公開したくないなぁ (スコア:1)
それは相関関係であって、因果関係ではない。
メモリリークの修正をうかつに奨励すれば、一定量の
「メモリリークのある、低品質なプログラム」が「メモリリークのない、低品質なプログラム」
に変換される。前者の方が後者よりも検知容易であることとを考えると、寧ろ放置すべきである。
Re:公開したくないなぁ (スコア:2, すばらしい洞察)
それこそナンセンスだ。
前者だろうが後者だろうが、数値計算結果に間違いがある危険性が高いことに変わりはなく、なおかつソースが公開されない限り、数値計算結果に影響のあるメモリリークか、影響の無いメモリリークかは評価不能なのだから。
「うちの娘は、メモリリークがあっても大丈夫な娘ですっ」
と言いたいなら、ちゃんとソースコードを公開するべきだ。
ついでに言っておくなら。研究用のコードを公開するにあたって、コードのクリーンナップは必要ない。
fjの教祖様
Re:公開したくないなぁ (スコア:2, すばらしい洞察)
それも間違い。
メモリリークではあるから。それ以外の問題でもあるというだけで。
というよりも。メモリリークというバグが単独で発生し、なおかつそれ以外の問題を引き起こさない、と言うのは奇跡的な状況です。
動的メモリ管理というのはすごく簡単に言うと:
1) メモリを確保する。確保したメモリは先頭アドレス/リファレンスで管理する
2) 1 で得たアドレス/リファレンスを基点として、一連の演算を行う
3) 1 で得たメモリを解放する
という3段階で成り立っています。また、コーディングもこの順序で行われるのが一般的です。
メモリリークが「メモリリークとしてだけ」存在するためには 「純粋に 3 の段階だけで」バグが混入しなくてはいけません。
普通はそのようなことは起こりません。2 のステップの最中に 3 に至るはずのパスを一部記述しそこなう事で発生します。問題は 2 のステップの途中でなぜバグが混入されるか。
大抵の場合、メモリ管理が「主目的ではない」ために(主目的なプログラムって malloc/free 自身程度しか私は知らない)、デザインがプログラマの頭の中にしかない場合に問題が発生します。2の記述中に集中が阻害される事象が発生し、回復した時には頭の中のデザインが微妙に違っている。結果として処理順序が変化しメモリリークが起こる。メモリリークがある、というのはプログラミング中にそういうイベントが起こった事を表します。
メモリリークがあるというのは、「他のバグをも発生させている可能性が高い」事象が結構大切な部分をコーディングしている最中に起こった、と言う事なんです。演算部のコーディングそのもので間違える可能性は低いでしょう。一番大事な部分であり、一番意識を集中させているところですからね。でも「数字をどこから持ってくるか」「数字をどこに書き出すか」周りにはバグが混在する公算は非常に高い。間違った数字を正しく演算したら、間違った結果になるに決まっています。
.
メモリリークが生じていないプログラムを組める人は、プログラムのアウトラインデザインを紙に描いている人です。コーディングを始める前に何をどの順番で処理するのかを全部図にする。で、一塊づつコーディングをしていき、一塊単位で バージョン管理システム(自分用)にチェックインしていく。もし、何らかの理由で塊をコーディングしている最中に邪魔が入ったら、そこのコーディングを開始する前までロールバックして組みなおす。なのでチェックインはものすごく細かい単位で行われる。そのために「自分用」のバージョン管理システムをプロジェクトのそれとは別に持っている。
このような組み方をしている人は、メモリリークもめったに起こしませんし、アドレス異常も起こしません。なので、計算部そのものに問題が無ければ、結果は信頼できるでしょう。
fjの教祖様
Re:公開したくないなぁ (スコア:1)
生ポインタをいじれなくても、メモリリークやアドレスミスはなんぼでも生じるよ。
基本的に「メモリリーク」するためには「動的に」メモリを取得出来る必要があるだろう? これが可能であるためには動的に得たメモリを指定、管理する表現と機構が必要なんだが、そこに必ずメモリリークやアドレスミスを起こす要素が残る。
fjの教祖様
Re:公開したくないなぁ (スコア:1)
毎回異常終了するとか、明らかにおかしいデータ(数値の所に文字列とか)を喰わせたら落ちるとか、そーゆー修正は後回しでいーんじゃね？
Re:公開したくないなぁ (スコア:2)
プログラミング（コーティング）のバグはある程度しょうがないと思うけど、理論のバグはまずいよね。
けど、理論を記述する方法（エディターとか）ってやっぱり昔ながらの果てしなく手書に近いフローチャートなんでしょうか。
まずやりたいことの概略を書いていてって、つぎにそれぞれの項目を詳しく書き、最終的にコードまで落としこむみたいな言語ってあるのでしょうか。素人なんでそういうことよく知らないんですが。
回路図なんかだとブロック図を書いてその下の階層にさらに細かいブロック図、その下の階層に実際の回路図みたいな書き方ができるのでブロック図の中はブラックボックスとして機能さえ理解できれば全体像をつかみやすいのですが。
Re:公開したくないなぁ (スコア:1, 参考になる)
ですから、基本的に理論はすべて数式であり、フローチャート以前の話になっちゃいます。
その分、理論のミスはそこそこわかりやすいです。
理論自体にミスがあれば式変形がおかしくなりますし、保存量が保存しません。
また、どのくらいの誤差が出るのかもわかりますので、理論が正しいかはその辺でも判断できます。
その式をCやFortranに落とし込んで、それを走らせることになります。
Re:公開したくないなぁ (スコア:2)
VBをちょっと触ったことがある程度の素人なので参考までに教えてください。
Re:公開したくないなぁ (スコア:2)
ありがとうございました。
結果に影響しないバグ (スコア:1)
プログラムのバグは研究をする上で大きな問題ですが、研究する側もその問題は認識していると思います。
グループ内で独立に解析プログラムを開発して結果を比較したり、シミュレーションのデータを入れてみたり、他の研究グループと比較できる領域で結果を比較したりしてチェックします。
もちろん、後日バグが見つかるのこともあります。
結果に影響するものもありますが、大半は、他の誤差より影響が十分に小さかったり、研究に使っていないエネルギー領域だったり、データが壊れていなければ問題なかったり、逐次近似の計算時間が少し長くなるだけだったりします。
コードの開発力も研究者の能力のうち (スコア:1, 興味深い)
しのぎを削る研究者(チーム)の勝負を決めるのは、アイディア、研究手法もさる事ながらコードの記述能力も含まれるでしょう。
生データの開示義務が無いのと同様に、コードの開示義務なんてのは無い。
ただ共通化できるものは共通化すべき。それがCERNLIBでありGSLであるわけだけど。
勿論、要求された検証にはとことん付き合うべきだと思う。
Re:コードの開発力も研究者の能力のうち (スコア:1)
検証のためにといって、検出器の詳細情報も、生データも、較正データも、解析コードも公開すべきだとなったら、先にグループ外の人に解析されて発表されてしまいますよね。
でも、天文関係は色々と公開している場合が多いですね。
Re:コードの開発力も研究者の能力のうち (スコア:1, すばらしい洞察)
天文関係もある程度論文を発表してからしか、生データは公開してません。
私は天文関係じゃないけど、他研究者に要求してプログラムを提供されなかったことも、要求されて提供しなかったことも基本的にない。
いったいどこの世界の話だろうと思う。
＃気候変動関係もプログラムを公開している方が多いという印象です。
Re:コードの開発力も研究者の能力のうち (スコア:1, 参考になる)
いや、少なくともここ10年位のISAS (JAXA)/NASA/ESAの人工衛星を使った高エネルギー天文だと、権利者にデータ引き渡し後一定期間 (1年程度) で自動的に全公開というのが殆どですよ。観測の種類によっては、引き渡しと同時に全公開の事もあります。この辺は衛星打ち上げ前から国際公約としている事が多いです。
なもんで、権利者（衛星を作った人だったり、観測公募に通った人だったり）が雑務とかで多忙だったりすると、苦労して得たデータを解析したり論文にしたりする時間を作れず成果を他人に持ってかれたりします。まあ、事前に権利者に仁義を切ったり、観測公募を通したという寄与でもって共著者に入るよう持ちかける事も多いですが。
他の分野の人からは「うちの分野ではとてもできん……」と時々言われたりするそうです。
論文の検証可能性のところで (スコア:1)
何かの論文を発表したとして、その論文で使用したサンプルの情報や計算式の情報と同じように、結論を導くまでに用いたプログラムのソースもある程度は提示しないと「その論文の内容が正しいか(≠論文の結論がただしいか)」の検証が取れないんじゃないかな？
◆IZUMI162i6 [mailto]
Re:論文の検証可能性のところで (スコア:1, すばらしい洞察)
論文をコンピューター言語に書き直したものがコードと見るなら、重複や冗長という感覚になるんだろうか。
まあソース公開によって、第三者の検証作業が楽になるのは確か。
Re:論文の検証可能性のところで (スコア:5, 興味深い)
論文を改良したものを実験 → 論文のと比較したら改良版の方が悪い
→ 自分のプログラミングミスと思い単体テストをしまくるが、バグが見つからない
→ 見かねた研究室の教授もコーディングするが、結果は私のと一緒
→ 参考論文の実験結果は、通常より結果が良くなるオプション的なものを付けていたのではないか、と結論。
論文の場合、理論とそれを実証した結果は書いてあっても
それを導いた実験方法が(詳しく)書かれていないことが多くあります（ページ制限もあるし）。
論文を読んで改良などを考える人、結果に疑問を持つ人などにとっては
理論そのものは論文に書いてあるので、その詳しい実験方法が知りたいと思うでしょう。
そのときにソースコードは”生きた証人”として重要なわけです。
どうやってソースコードを保管しておくか（論文投稿時にソースコードも提出とか）など課題もありそうですが
コードが公開されているというのは良い面が多々ありそうな気がします。
# まぁ、自分の稚拙なソースコードが名前付きネットの海に放流されるというのは恥ずかしいですが。
実験に用いた設定を全て書くべき? (スコア:1)
ソフトウェア分野の修論を書いてたら,指導教員の先生からページ数制限も
無いんだし実験に用いた設定を実験が再現可能なレベルまで書くべきと
言われました.確かに,正しい意見だと思います.
ソフトウェアのソースコードと設定ファイルを全て修論に貼ればいいのかな?
いや,修論に貼らずにどこかで公開するのがいいんでしょうけど,共同研究先との
NDAとかなんとかかんとか…orz.
Re:実験に用いた設定を全て書くべき? (スコア:2)
> ソフトウェアのソースコードと設定ファイルを全て修論に貼ればいいのかな?
提出論文の厚みを出すには、最も手っ取り早い方法です。
後輩への土産にもなるし。
＃オイラの卒論の 95% は、さる資料の翻訳だった。ン十年前の話。
公開できない場合もある。 (スコア:1, 興味深い)
ある非営利なプログラムＡに、我々が開発した理論に基づくプログラムＢを、商用プログラムＣのソースを流用しつつ書いた
フライングスパゲッティモンスタープログラムなんかどうしようもない。論文にはその理論の詳細および利用したプログラムはＡ、Ｃである旨を記入して、誰でも追試が可能な状態にしておけばいいんだが、公開なんか二重三重の意味で無理なんです、はい。
大体、他の方も仰るとおり、別のプログラムに基づいて追試してもらったほうが信頼性も上がる上に、他人の書いたソースなんか真面目に読む気も失せるからバグによるエラーを拡大再生産してしまう可能性も大きいんだが・・・。分野による違いも大きいのかな。
Re:公開できない場合もある。 (スコア:2)
同じデータに対する追試であればその通りですが、別のデータに対する追試をする時には初出論文のプログラムでの検証も大事だと思います。
Re:公開できない場合もある。 (スコア:2, 興味深い)
仰ることはよく分かります。
長年研究をしていると、自作のモジュールに依存したプログラムばかりになり、そのモジュールにはもはやどこから
コピペしてきたか忘れたようなコードにあふれており、ライセンス上公開できるのかどうかも分からない状態になって
います。
それに、解析に使用したプログラムを公開している論文も多くありますが、実際に動かそうとすると特定の環境でしか
動かないので、実質上それを使用しての結果の再現が不可能ということも数度ではありませんでした。
エンディアンの問題なら可愛いもので、とある絶対パスにある特定のOS用の商用ソフトウェア（ン十万円）を呼び出し
たり、特定のコンパイラでないとコンパイルが通らないとか、それなのにコンパイラ・インタプリタのバージョンが書かれて
いないとか・・・
このようなプログラムを「公開」されても「プログラムの査読」は不可能ですし、では研究者に対応しろと言っても
そこまでのリソースはとても割けないのが実情ですし、それをしても誰も得をしないのではないでしょうか。
現実にありがたいのは解析に用いた、できるだけ生データに近い、しかし解析しやすいフォーマット（タブ区切りテキストとか）
で書かれたデータとアルゴリズム、そして論文の結論を出すのに十分な解析結果で、これらが整理されている論文は
内容もしっかりしている印象があります。
科学は常に仮説であり間違いを訂正して改善していくプロセスであるので、プログラム自体よりもあいまいさを含まない
方法の記述と結論の提示をし、後に疑問を持った研究者が再現実験して確かめることができるようになっていることが
大切だと思います。
kaho
"市場化"するしかないかもしれない (スコア:1, 興味深い)
後からでたソースの公開された"信頼できる"論文に
ある程度手柄をさらわれても文句は言えない、みたいな感じで。
Re:みんな公開すれば (スコア:2)
いくらソースコードが公開されたところで、
それを現実的な時間で実行できるコンピュータがなければ結果を再検証できません。
世界一のスパコンがあれば、すべてのシミュレーションを
最初に実験が行われたときの時間以下で完了できます。
個々のスパコンの特性を無視した場合ですけどね・・・。