パスワードを忘れた? アカウント作成
192314 story

科学者は研究に使っているコードを公開すべき? 148

ストーリー by soara
論文妥当性の検証にコード査読も必要か 部門より

あるAnonymous Coward 曰く、

科学者はその研究で使っているプログラムのコードを公開すべきであるとの主張が英Guardian誌で取り上げられている(本家/.より)。

このコラムで Open Universityの Darrel Ince教授は特に最近の気候科学分野での論争に言及しながら、コードが公開できる状態にあるのにそれをしぶる研究者は科学者と見なされるべきではないとまで述べている。

教授曰く「科学分野で使われているソフトウエアを憂慮すべき証拠は十分にある」とのこと。ソフトウエアテストの国際的な専門家であるケント大学の Les Hatton教授が何百万行に及ぶ科学分野のソフトウエアコードを分析したところ、多くの矛盾点が検出されたとのこと。例えばプログラム内のモジュール間インターフェイスでは、Fortranで書かれたプログラムにおいてはインターフェイス 7つあたり 1件の割合で矛盾点が見つかったとのこと。Cで書かれたプログラムでは 37インターフェイスあたり 1件の問題が発見されたという。たった一つのエラーがその立証力を無くさせるのに十分であると考えると、非常に憂慮すべき事態であると教授は指摘しているそうだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by metta (20740) on 2010年02月11日 13時41分 (#1716773) 日記
    > 特に最近の気候科学分野での論争

    クライメートゲート事件ですね。

    > 1月18日、英国のイーストアングリア大学にある「気候研究所」(CRU)のサーバーがハッキングされ、
    > 1000通以上の電子メールや、プログラムのスクリプトなど電子文書類が、
    > 何者かによってネット上に公開された。その公開されたメールやデータを分析することにより、
    > CRUなどの研究者たちが、温暖化人為説を根拠づけるため、
    > さまざまな歪曲や論敵つぶしを展開してきたことが明らかになりつつある。

    > 今回、ネット上で暴露されたCRUの文書は、約1000通のメール以外に、
    > 多くのコンピュータープログラム(フォートランやIDLなどのソースコード)のスクリプトが含まれている。

    > 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
    > という2行がある。

    > これは「誤差」(fudge factor)と注釈がつけられているが、
    > 処理の内容は、1904年から94年(データの最終年)までを5年区切りにして、
    > その20個の各年の温度変化に対し、個別に数字(温度)を加算し、
    > 現在に近づくほど加算値を大きくしている。
    > つまり、現在に近づくほど気温が上がったように、結果を歪曲している。
    地球温暖化めぐる歪曲と暗闘(1) [tanakanews.com]
    • by Anonymous Coward on 2010年02月12日 3時18分 (#1717032)

      ソースの中から 2行だけ抜き出して何かわかったような気になるのは、やめたほうがいいと思いますよ。

      http://www.jgc.org/blog/2009/11/very-artificial-correction-flap-looks.html [jgc.org] で、そのコードを調べた結果が解説されているので、それを読んでからにしてはいかがですか。年輪から推定される温度と実際の温度が昔はあっていたのに最近になってずれている現象について述べた論文で、どれだけずれているかを示すために使われたコードで、気温を歪曲するのに使われたものではないというのが結論です。

      親コメント
    • by Anonymous Coward on 2010年02月11日 14時47分 (#1716801)

      当の本人達やその周りは

      >たった一つのエラーがその立証力を無くさせるのに十分である

      とは考えてないんですけどね。大筋には問題無いとか堂々とほざいているわけで。
      藤村新一よろしくあんなことやったにも関わらず研究者そのものの生命が断たれていないって不思議!

      親コメント
    • by quaternion (18655) on 2010年02月11日 22時34分 (#1716979) 日記
      fudge factor は誤差という意味の熟語ですが,fudge には「ずるをする」という意味もありますね.
      親コメント
    • by BlueRain (37857) on 2010年02月11日 23時37分 (#1717001)
      ごめん。
      > CRUなどの研究者たちが、温暖「擬人化」説を根拠づけるため、
      に見えてしまった。

      オフトピになるけど「温暖化」っていい事のように聞こえるよね。すみやすい環境が増えるだけじゃん、って。
      「温暖」の持つイメージってそういう方向だと思う。
      そういう言葉を意図的に選ぶことで真剣みを削いで商業化しやすくしているんじゃないかと。
      「熱帯化」だともうちょっと危機感があるような気がしない?
      親コメント
  • by wd-nara (25864) on 2010年02月11日 13時24分 (#1716765) 日記

    元のコラムではプログラムを公開して成功した例としてApelとHakenによる四色予想の証明をあげているけど、良い例ではないでしょう。あの論文の本文でアルゴリズムの詳細は解説されているし、ジャーナルの付録としてマイクロフィルムがついていてそこにデータは全部入っていたから、たとえ原プログラムを公開しなくても、独立した実装による追試が可能な状態でした。むしろ、原プログラムを参照しない独立した実装で追試を行ったほうが、原プログラムを検証するよりも強い支持を得られますよね。

    例の一つを例になっていないよと言っているだけで、元の主張全体を否定するものではありません。念のため。

  • なにがそれを分ける基準かというと,コードを公開しないと信じて
    もらえないかどうか,そしてそこまでして信じてもらいたいかどう
    かだと思う.

    30年後の地球の気温のように,誰にも答の分からない問題を予測し
    た場合,予測に用いたコードが正しいかどうかは見てみないと分か
    らないだろう.そして,それが各国の政策にまで影響が及ぶとなれ
    ば,なおさら公開の必要ありと考える.

    一方,シミュレーションの結果新しい現象が予言され,それが実験
    で確認された場合などは,シミュレーションコードそのものがその
    研究者の武器なのだから,オリジナリティを維持するために公開し
    たくないだろうし,コードが正しいかどうかは「余計なお世話」だ
    ろう.

    研究が公費で行われたなら全てを公開するべきだという考えはちょ
    っと極端に走りすぎという印象.一方で研究は競争でもあるわけだ
    から,相手に手の内を晒したくないことは多くある.

  • by gonta (11642) on 2010年02月11日 14時53分 (#1716802) 日記

    学生時代に、同じような内容の研究を2名でやった(うち1名私)。もう1人の方は、プログラミングも初心者。で出た結果は、そいつの方がよかった。

    研究室(というか担当教員は)そいつの方のコードを正しいと採用しました。5回中3回、Segmentation Faultで止まるのにね・・・期限直前にバグだと騒ぎだし3年間の締めくくりが、大変なことになってた。

    それこそ、世界レベルで検証を行うような、トップレベルの研究内容じゃない限り、プログラムの質ってこんなもん。

    --
    -- gonta --
    "May Macintosh be with you"
  • by Anonymous Coward on 2010年02月11日 18時18分 (#1716889)

    詳しい内容を書くのはあれなのですが、特許になっていたとあるアルゴリズムを追試して応用をしてみようと思ったわけです。
    特許の内容そのものはかなりしっかり書かれてまして、それを仕様書としてソフトウェアに落とすのは楽でした。
    それは、通常では検知できない部分にあれこれして品質を上げるというものでして、すでに複数の有名企業に採用されているようなものだったのですが、少し条件を変えてあれこれしている部分を検知できるようにしますと…

    品質を上げたとされる場面でも実際にそうだったかどうか疑われるようなものでした。そのようなわけでその特許を採用するのを見送りました。
    このようなときに元ソースを入手できたらこちらで作ったものとの差異を比べてより正確に評価できたんでしょうが、出力が同等だったとしたら…効果を信じ込ませて売り込んだだけのオカルト技術だったのかもなと思ってしまいます。

    アルゴリズムのみ公開されている場面では、出力の同一性と評価環境の評価がそろわないと信用できないですね。出力だけで一目瞭然というものならともかく。

  • まだ発表できてない研究に関するコードが山ほどあるんで
    公開コードが成果実績に数えられるなら喜んで出すよ!w

    知的クラスター創生事業での経験だが
    採用面接や部内のミーティングでは開発しろ、事業化だとうるさくと言うくせに
    採用時にも給与にも開発成果についてなんら配慮してくれるわけじゃない。

    事業化をエサに企業から研究予算を取れと
    公共部門の研究費がグイグイ絞られてる昨今、
    企業へもっていってデモするわけだが
    「(商品に比べて)完成度が低い」とダメだしされる。
    …そらそうだろ、開発にかかわってる人数が1/10~1/100だよ?
    その上、その開発にかかわってる人間は開発したソフトウェアで評価されるわけでなく
    論文で(それも大概はその数で)評価されるわけで…。
    (で、その論文にまとまるところまでの食い扶持が足りてないから売り込みにきてるのだから。)

    というわけで成果に数えてくれるなら品質ももうちょっと頑張るし、公開だってOKさ!!!!1!!!

    #なのだが我々はそれ以前の状況にある。
    #期間が短く、運任せで先の読めない予算・研究費、
    #その予算の切れ目が雇用の切れ目、
    #万が一雇用が切れても発表できるところまでコードが触れて研究を続けられるように
    #という理由を挙げてオープン・ソース化を進言したよw

  • by iwakuralain (33086) on 2010年02月12日 9時40分 (#1717077)

    こういうのに参加したことはないですが、共通で使えるものってのは無い物なんでしょうか?
    自分の身近で言うとLinuxだったりApacheだったりするわけですが、そういうのがあればコードの不具合によるロスもなくせる上に
    コードを記述する時間を研究に使えたりしていいんじゃなかな~と思ったり。
    研究ごとにやることが違うので共通化したりというのは出来ないのかもしれませんけど。

    #畑違いのヤツが何言ってんの?とか思われるかもしれませんが・・・。

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

    一応、プログラムが正しい結果を出すことはチェックしている…つもりなんですが…
    学生さんに渡したプログラムに、卒論提出直前にとんでもないミスが見つかったことがあります。
    • by Anonymous Coward on 2010年02月11日 13時55分 (#1716777)
      >一応、プログラムが正しい結果を出すことはチェックしている…つもりなんですが…

      この「正しい」が何を根拠なのかが問題なのだと思いますよ。
      自分が「正しい」と思っている結果が出てきているというだけで、本当に正しいかどうかは分からない。
      もしも、自分の予想とプログラムの両方が間違っていた場合はどうするのかという問題があります。
      この「両方間違い」というのは起こりやすいもので、たとえば、本来あるべき効果や観測量同士の共分散関係などが自分の思考とプログラムの双方に入らないため一見矛盾しない結果を出します。プログラム制作者が現象を正しく理解していなかったのだから当然ですよね。 そんな、いわゆる「間違い」を正すためにもプログラムの公開は最終的には行うべきだと思います。

      また、たとえば、理論計算のプログラムに非常に微小なエラーがあって、それは数年先の実験結果がでるまでわからない。
      ところが、人間は不思議なもので、数年前からあり、市民権を得ている理論計算が正しいと思い実験結果を信じない。
      そのため、実験が正しいことを証明し、理論計算のプログラムのエラーを発見するために膨大な時間と労力が消費された。
      なんてことが過去にありますよね。

      他にも実験の解析系プログラムにエラーが入っていて、それが微小効果であると数年先まで発見できない、発見されたころは影響が大きくなっている。なんてこともありますし、プログラムの微小なエラーから大発見かなんて世界的に大騒ぎになることもありますよね。

      逆に個人的経験も含めますが、プログラムの結果と自分の「正しい」が矛盾していての矛盾を追及したら新しい発見があって良い論文が書けたなんてこともあります。
      他にも、個人的経験として、公開されているいくつかのコードにエラーを見つけ、その原因が制作者の思い違いや入力ミスだと思い至ることがありあmした。
      #いま、修正すべきかどうか悩んでいる個所もあります。
      #書き換えると影響がでかすぎる一方で、現段階では計算結果には影響がない項目なので緩やかな入れ替えで対処するか


      などなど、研究者は決して個人の趣味で研究しているのではなく、みんなから研究資金を得てやっている仕事だと思って、最大限ミスを減らす方向で仕事をすべきだし、そのミス減らしの一つの方法が適切な時期にコードを公開することだと思います。そして、自分は決してプログラムを誤らないとか自分の直感が結果と一致するからOKと思わない方が健全だと思います。
      ちなみに私は「自明でない部分」はすべて公開して、コードのあるURLとかを論文に書いています。


      #決して元投稿の方を非難しているわけではありません、適切な書き込み場所が見つからないのでぶら下げました。。。
      親コメント
    • by Anonymous Coward on 2010年02月11日 19時16分 (#1716922)

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

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

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

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

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

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

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

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

        親コメント
    • > アウトプットが正しければ良いので、やっつけ仕事、コピペ継ぎ接ぎのかたまりです。

      ですよねぇ。特に急いで作ったものはその傾向強いですね。
      ("正しさ"の判定は難しいような気もしますが)
      そんなのを公開すること自体あまりうれしくないですし、
      もし、査読者がそれのチェックを要求されたりしたら本当に悲惨。
      マニアックな内容をマニアックな言語で書いたらマトモに査読できる
      人がいなくなったりするかも。>部門名
      4 色問題の時みたいな形式で査読するのかな。

      てか、検証って意味では論文の記述を基に別のプログラム
      を作って同様の結果が得られることのほうが大事だと思う。
      (正直、コードを"きちんと"検証するのは難しすぎると思う。)
      そういう意味では現状のやり方がそこまで悪いとも思えないなぁ。
      論文の内容からそれをできないのならその論文に問題があるってことだし。

      # もちろん、公開しろって言われたら初期データ等を含めて公開すべきで
      # あるとは思う。その点については異論は無いです。原則公開にしても
      # いいけど、単なるゴミ箱になるだけだと思う。

      # 初期データとか乱数の発生アルゴリズム、種にも当然依存するから
      # 論文の記述から内容を完全に再現できる、とは言えないのも事実…。
      # とはいえ、完全に再現しようとすると、コードや初期データはもちろん、
      # コンパイラのバージョン、与えるオプションや実行環境(使う CPU 数とか)まで
      # 同一にしないとできなかったりするしなぁ…。(場合によるけど。)

      親コメント
    • >コピペ継ぎ接ぎのかたまりです

      うっかり公開するとまずいコードが入っていたなんてことがない様に調べる必要もあったりしませんか?
      ランタイムライセンスだけのライブラリを使っていたりとかあると、結構痛いかも。

      親コメント
  • by Ooty (29466) on 2010年02月11日 13時27分 (#1716766) 日記

    プログラムのバグは研究をする上で大きな問題ですが、研究する側もその問題は認識していると思います。

    グループ内で独立に解析プログラムを開発して結果を比較したり、シミュレーションのデータを入れてみたり、他の研究グループと比較できる領域で結果を比較したりしてチェックします。

    もちろん、後日バグが見つかるのこともあります。
    結果に影響するものもありますが、大半は、他の誤差より影響が十分に小さかったり、研究に使っていないエネルギー領域だったり、データが壊れていなければ問題なかったり、逐次近似の計算時間が少し長くなるだけだったりします。

  • by Anonymous Coward on 2010年02月11日 13時44分 (#1716774)

    しのぎを削る研究者(チーム)の勝負を決めるのは、アイディア、研究手法もさる事ながらコードの記述能力も含まれるでしょう。
    生データの開示義務が無いのと同様に、コードの開示義務なんてのは無い。
    ただ共通化できるものは共通化すべき。それがCERNLIBでありGSLであるわけだけど。
    勿論、要求された検証にはとことん付き合うべきだと思う。

    • 検証のためにといって、検出器の詳細情報も、生データも、較正データも、解析コードも公開すべきだとなったら、先にグループ外の人に解析されて発表されてしまいますよね。

      でも、天文関係は色々と公開している場合が多いですね。

      親コメント
      • by Anonymous Coward on 2010年02月11日 20時29分 (#1716943)

        天文関係もある程度論文を発表してからしか、生データは公開してません。

        私は天文関係じゃないけど、他研究者に要求してプログラムを提供されなかったことも、要求されて提供しなかったことも基本的にない。
        いったいどこの世界の話だろうと思う。

        #気候変動関係もプログラムを公開している方が多いという印象です。

        親コメント
        • by Anonymous Coward on 2010年02月12日 0時10分 (#1717012)

          いや、少なくともここ10年位のISAS (JAXA)/NASA/ESAの人工衛星を使った高エネルギー天文だと、権利者にデータ引き渡し後一定期間 (1年程度) で自動的に全公開というのが殆どですよ。観測の種類によっては、引き渡しと同時に全公開の事もあります。この辺は衛星打ち上げ前から国際公約としている事が多いです。

          なもんで、権利者(衛星を作った人だったり、観測公募に通った人だったり)が雑務とかで多忙だったりすると、苦労して得たデータを解析したり論文にしたりする時間を作れず成果を他人に持ってかれたりします。まあ、事前に権利者に仁義を切ったり、観測公募を通したという寄与でもって共著者に入るよう持ちかける事も多いですが。

          他の分野の人からは「うちの分野ではとてもできん……」と時々言われたりするそうです。

          親コメント
  • 何かの論文を発表したとして、その論文で使用したサンプルの情報や計算式の情報と同じように、結論を導くまでに用いたプログラムのソースもある程度は提示しないと「その論文の内容が正しいか(≠論文の結論がただしいか)」の検証が取れないんじゃないかな?

    --
    ◆IZUMI162i6 [mailto]
    • by Anonymous Coward on 2010年02月11日 15時06分 (#1716808)
      第三者が論文を元に一からコーディングして検証するんでしょう。論文はプログラム仕様書だからコーディングに必要な情報はすべて書いてある(はず)と。
      論文をコンピューター言語に書き直したものがコードと見るなら、重複や冗長という感覚になるんだろうか。
      まあソース公開によって、第三者の検証作業が楽になるのは確か。
      親コメント
      • by Anonymous Coward on 2010年02月11日 16時34分 (#1716844)
        先日、参考にしていた論文に必要事項が書いてなくて困った。

        論文を改良したものを実験 → 論文のと比較したら改良版の方が悪い
        → 自分のプログラミングミスと思い単体テストをしまくるが、バグが見つからない
        → 見かねた研究室の教授もコーディングするが、結果は私のと一緒
        → 参考論文の実験結果は、通常より結果が良くなるオプション的なものを付けていたのではないか、と結論。

        論文の場合、理論とそれを実証した結果は書いてあっても
        それを導いた実験方法が(詳しく)書かれていないことが多くあります(ページ制限もあるし)。
        論文を読んで改良などを考える人、結果に疑問を持つ人などにとっては
        理論そのものは論文に書いてあるので、その詳しい実験方法が知りたいと思うでしょう。
        そのときにソースコードは”生きた証人”として重要なわけです。
        どうやってソースコードを保管しておくか(論文投稿時にソースコードも提出とか)など課題もありそうですが
        コードが公開されているというのは良い面が多々ありそうな気がします。

        # まぁ、自分の稚拙なソースコードが名前付きネットの海に放流されるというのは恥ずかしいですが。
        親コメント
  • ソフトウェア分野の修論を書いてたら,指導教員の先生からページ数制限も
    無いんだし実験に用いた設定を実験が再現可能なレベルまで書くべきと
    言われました.確かに,正しい意見だと思います.

    ソフトウェアのソースコードと設定ファイルを全て修論に貼ればいいのかな?

    いや,修論に貼らずにどこかで公開するのがいいんでしょうけど,共同研究先との
    NDAとかなんとかかんとか…orz.

  • by Anonymous Coward on 2010年02月11日 15時21分 (#1716819)

    ある非営利なプログラムAに、我々が開発した理論に基づくプログラムBを、商用プログラムCのソースを流用しつつ書いたフライングスパゲッティモンスタープログラムなんかどうしようもない。
    論文にはその理論の詳細および利用したプログラムはA、Cである旨を記入して、誰でも追試が可能な状態にしておけばいいんだが、公開なんか二重三重の意味で無理なんです、はい。

    大体、他の方も仰るとおり、別のプログラムに基づいて追試してもらったほうが信頼性も上がる上に、他人の書いたソースなんか真面目に読む気も失せるからバグによるエラーを拡大再生産してしまう可能性も大きいんだが・・・。分野による違いも大きいのかな。

    • 大体、他の方も仰るとおり、別のプログラムに基づいて追試してもらったほうが信頼性も上がる上に、他人の書いたソースなんか真面目に読む気も失せるからバグによるエラーを拡大再生産してしまう可能性も大きいんだが・・・。分野による違いも大きいのかな。

      同じデータに対する追試であればその通りですが、別のデータに対する追試をする時には初出論文のプログラムでの検証も大事だと思います。

      親コメント
    • 仰ることはよく分かります。
      長年研究をしていると、自作のモジュールに依存したプログラムばかりになり、そのモジュールにはもはやどこから
      コピペしてきたか忘れたようなコードにあふれており、ライセンス上公開できるのかどうかも分からない状態になって
      います。
      それに、解析に使用したプログラムを公開している論文も多くありますが、実際に動かそうとすると特定の環境でしか
      動かないので、実質上それを使用しての結果の再現が不可能ということも数度ではありませんでした。
      エンディアンの問題なら可愛いもので、とある絶対パスにある特定のOS用の商用ソフトウェア(ン十万円)を呼び出し
      たり、特定のコンパイラでないとコンパイルが通らないとか、それなのにコンパイラ・インタプリタのバージョンが書かれて
      いないとか・・・
      このようなプログラムを「公開」されても「プログラムの査読」は不可能ですし、では研究者に対応しろと言っても
      そこまでのリソースはとても割けないのが実情ですし、それをしても誰も得をしないのではないでしょうか。
      現実にありがたいのは解析に用いた、できるだけ生データに近い、しかし解析しやすいフォーマット(タブ区切りテキストとか)
      で書かれたデータとアルゴリズム、そして論文の結論を出すのに十分な解析結果で、これらが整理されている論文は
      内容もしっかりしている印象があります。

      科学は常に仮説であり間違いを訂正して改善していくプロセスであるので、プログラム自体よりもあいまいさを含まない
      方法の記述と結論の提示をし、後に疑問を持った研究者が再現実験して確かめることができるようになっていることが
      大切だと思います。

      --
      kaho
      親コメント
  • by Anonymous Coward on 2010年02月11日 18時28分 (#1716895)
    別に公開する義務はないけど、そのぶん論文の信頼性が問われ、
    後からでたソースの公開された"信頼できる"論文に
    ある程度手柄をさらわれても文句は言えない、みたいな感じで。
typodupeerror

あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall

読み込み中...