パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

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

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

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

      >メモリリークなんかのバグがあってもアウトプットが正しければ良い
      正しいのか?

      まあ言いたい事は分かる。
      「個別の値に誤りがあったとしても定性的な傾向さえあっていれば良い」
      的な意味なんだろうけど。

      公開されるつもりで書いたほうが論理的になるし、あとでバグを潰す
      ことは大変な苦労をする。

      「品質は作りこむものです」という言葉もあるしな。

      親コメント
      • Re:公開したくないなぁ (スコア:3, すばらしい洞察)

        by vn (10720) on 2010年02月11日 15時13分 (#1716817) 日記

        >メモリリークなんかのバグがあってもアウトプットが正しければ良い
        正しいのか?

        まあ言いたい事は分かる。
        「個別の値に誤りがあったとしても定性的な傾向さえあっていれば良い」
        的な意味なんだろうけど。

        ぜんぜん分かってないってことが分かる。
        メモリリークは、途中経過にしろ最終結果にしろ、数値の誤りを意味するものではない。
        上出来なプログラムに比べれば、メモリリークするプログラムは実行中により多くの
        メモリを要求する筈だが、それを賄い切れる限り、単なるメモリリークだけでは
        間違った数値を出力したりはしない。

        親コメント
        • by ttm (8278) on 2010年02月11日 15時46分 (#1716826)

          上出来なプログラムに比べれば、メモリリークするプログラムは実行中により多くの
          メモリを要求する筈だが、それを賄い切れる限り、単なるメモリリークだけでは
          間違った数値を出力したりはしない。

          理想的にはその通りですが、現実としてはメモリリークしているようなお粗末なメモリ管理をしているのに間違った数値を出力しないなどという主張には全く説得力がないです。
          論文の正当性を主張するのであれば、その論拠としているプログラムも説明可能でなければならないと思います。
          メモリリークしているようなプログラムで正当性を説明できるのか、甚だ疑問です。

          親コメント
          • Re:公開したくないなぁ (スコア:2, すばらしい洞察)

            by Anonymous Coward on 2010年02月11日 17時53分 (#1716879)

            > 理想的にはその通りですが、現実としてはメモリリークしているようなお粗末なメモリ管理をしているのに間違った数値を出力しないなどという主張には全く説得力がないです。

            ソースを公開したくないのは、まさしくこういう揚げ足取りへの対応が面倒だと思うから。

            親コメント
          • Re:公開したくないなぁ (スコア:1, すばらしい洞察)

            by Anonymous Coward on 2010年02月11日 16時37分 (#1716848)
            論文の正当性を示すのはその結果のみであり、プログラムの品質ではないでしょう。
            リークが発生しているからこの結果は間違っている、信用できない、と言う主張の方が説得力がありませんよ。
            親コメント
            • by njt (4968) on 2010年02月12日 12時36分 (#1717169) 日記

              > 論文の正当性を示すのはその結果のみ

              結果ではなくて、手順(操作)が正当性を示すのではないの?

              親コメント
            • by Anonymous Coward

              >論文の正当性を示すのはその結果のみであり、プログラムの品質ではないでしょう。

              では、その「結果」を出すプログラムの正統性はどうやって示すので?
              品質が低くても出す結果は正しいです!その根拠は?
              ぶっちゃけコード公開するしかないよね。

              # 読む方はつらいだろうけどさw

              • by Anonymous Coward
                >では、その「結果」を出すプログラムの正統性はどうやって示すので?
                >品質が低くても出す結果は正しいです!その根拠は?

                他者が同じアルゴリズムでプログラムを作って、追試、検証するんじゃないでしょうか?

                #元コメントは「適当に着ている普段着をネットに公開するのは恥ずかしい」っていうのと同じ感覚では?
              • by Anonymous Coward
                論文を読めば追試、再現が可能ですので、試してみるのがよいかと。
                コードを読むよりもずっと簡単ですし、コードを読んでも間違いが見つかるとは限りませんから。
              • by Anonymous Coward
                そんなアホな。
                オモチャみたいなプログラムならともかく、スパコンぶん回した結果の追試なんてそうそうできるかい。
              • by Anonymous Coward
                やろうと思えば出来るでしょ?
                スパコンであろうと特別な物じゃないんだから。

                時間がかかる、というのは言い訳にならないよ。
              • by Anonymous Coward
                まさに世界一のスパコンが必要なわけですよwww
          • by Anonymous Coward

            むしろ、人間が手作業でメモリ管理するなんて無駄で馬鹿げた間違いの起こりやすい作業にコストを費やしていたら、他の品質にしわ寄せがいっていないか心配になってきます。

          • by Anonymous Coward

            動作上の不具合を招くものなら問題ですが、そうでなければ目くじらを立てるほどでもないように思います。
            C で malloc() はあっても free() がない計算ものとか、計算が終わるまでもてばいいみたいな戦略も理解できないではありません。
            実行要件として明記されているなら「それは仕様です」

            メモリリークしてるようなソースは、他にも怪しいところ多そうだし、ポイント低いよねーぐらいのニュアンスなら諸手を挙げて同意します。

            • by ttm (8278) on 2010年02月13日 4時54分 (#1717657)

              C で malloc() はあっても free() がない計算ものとか、計算が終わるまでもてばいいみたいな戦略も理解できないではありません。
              実行要件として明記されているなら「それは仕様です」

              意図してfreeしない仕様になっているのならば、それはメモリリークではありません。
              freeしているはずがfreeされていないから、メモリリーク(メモリが漏れている)と呼ぶのです。

              親コメント
          • by Anonymous Coward
            |理想的にはその通りですが、現実としてはメモリリークしているようなお粗末なメモリ管理をしているのに
            |間違った数値を出力しないなどという主張には全く説得力がないです。

            メモリリークするようなお粗末な処理系(プログラミング言語)を使っている方が問題です
            ガリガリ数値計算するならクラシックなFORTRAN使えば良いし、FORTRANで必要十分です
            (本当に動的なメモリ・アロケーションをする・出来る処理系使わなきゃいけない数値演算してるのか?)
            • by Anonymous Coward
              Fortran使ってますが、普通に動的アローケーションしますよ。
          • by Anonymous Coward
            理想的にはその通りですが、現実としてはメモリリークしているようなお粗末なメモリ管理をしているプログラムは間違った数値を出力するなどという主張には全く説得力がないです。

            #って話でしょ
          • by Anonymous Coward

            >> 理想的にはその通りですが、現実としてはメモリリークしているようなお粗末なメモリ管理をしているのに

            研究ジャンルにもよると思いますけど,「科学者」という一般論で.

            自分で使うだけであれば,大抵は「入力データの量を知っている→動的確保するメモリの量の見積もりもついている」という条件です.その条件であれば,「オレのPCの搭載メモリ量からすれば問題になるレベルの量じゃないし,この程度のメモリリークであれば気にしない」とか,本来は入力データ数に応じて決定すべき配列サイズを「どうせオレの持ってるデータ数は~しかないし」という理由で決

          • by Anonymous Coward
            言語マニュアルに載ってる仕様の範疇で書かれてても漏れる時は漏れるのでしょうがない。
            逆にアルゴリズムが間違ってればどんなに正しくプログラミングしても正しい結果は出ません。

            正しいアルゴリズム≠正しいプログラムですよ。

            プログラムはあくまで「計算機」でしかないので、
            重要なのは計算式とその結果であって「計算機」の動きではないのです。
            貴方は電卓で計算する時に「電卓の正当性」を検証はしないでしょう?
            • by Anonymous Coward

              それは市販品の電卓の計算結果は正しいという暗黙の了解があるからでしょう。

              # だからPentiumがバグった時は、一般人にはまず影響の無いレベルだったにも
              # かかわらず、あれだけ大騒ぎになったわけで。

              • by Anonymous Coward

                ときどき聞かれます。
                「EXCELの数式と電卓の結果が違う、EXCELがおかしいんじゃないか?」
                実際は1/3*3のような式でEXCELは1、電卓は0.999999…になるというようなの。

              • by Anonymous Coward

                あれ?0.9999999…=1だからどちらの計算結果も正しいのでは?

        • Re:公開したくないなぁ (スコア:2, すばらしい洞察)

          by bitterbeer_sweetwine (37563) on 2010年02月11日 17時39分 (#1716870)

          >単なるメモリリークだけでは

          メモリリークなんか...メモリリークに限っていないことをまずは、考慮すればよろしいでしょうね。

          親コメント
        • メモリリークは、途中経過にしろ最終結果にしろ、数値の誤りを意味するものではない。

          君こそバグの恐ろしさを判っていない。

          メモリリークのあるところ、ポインタ操作の間違いアリ、だ。
          演算対象や、保存先のアドレスが正しくなければ、数値演算の結果の正しさは保証できん。

          --
          fjの教祖様
          親コメント
          • by vn (10720) on 2010年02月11日 18時34分 (#1716899) 日記

            メモリリークのあるところ、ポインタ操作の間違いアリ、だ。

            それは相関関係であって、因果関係ではない。
            メモリリークの修正をうかつに奨励すれば、一定量の
            「メモリリークのある、低品質なプログラム」が「メモリリークのない、低品質なプログラム」
            に変換される。前者の方が後者よりも検知容易であることとを考えると、寧ろ放置すべきである。

            親コメント
            • Re:公開したくないなぁ (スコア:2, すばらしい洞察)

              by okky (2487) on 2010年02月11日 23時12分 (#1716991) ホームページ 日記

              前者の方が後者よりも検知容易であることとを考えると、寧ろ放置すべきである。

              それこそナンセンスだ。
              前者だろうが後者だろうが、数値計算結果に間違いがある危険性が高いことに変わりはなく、なおかつソースが公開されない限り、数値計算結果に影響のあるメモリリークか、影響の無いメモリリークかは評価不能なのだから。

              「うちの娘は、メモリリークがあっても大丈夫な娘ですっ」
              と言いたいなら、ちゃんとソースコードを公開するべきだ。

              ついでに言っておくなら。研究用のコードを公開するにあたって、コードのクリーンナップは必要ない。

              --
              fjの教祖様
              親コメント
              • by Anonymous Coward
                > 数値計算結果に影響のあるメモリリークか、

                そういうのメモリリークって言わないから
              • Re:公開したくないなぁ (スコア:2, すばらしい洞察)

                by okky (2487) on 2010年02月12日 14時16分 (#1717263) ホームページ 日記

                それも間違い。
                メモリリークではあるから。それ以外の問題でもあるというだけで。

                というよりも。メモリリークというバグが単独で発生し、なおかつそれ以外の問題を引き起こさない、と言うのは奇跡的な状況です。

                動的メモリ管理というのはすごく簡単に言うと:

                1) メモリを確保する。確保したメモリは先頭アドレス/リファレンスで管理する
                2) 1 で得たアドレス/リファレンスを基点として、一連の演算を行う
                3) 1 で得たメモリを解放する

                という3段階で成り立っています。また、コーディングもこの順序で行われるのが一般的です。
                メモリリークが「メモリリークとしてだけ」存在するためには 「純粋に 3 の段階だけで」バグが混入しなくてはいけません。

                普通はそのようなことは起こりません。2 のステップの最中に 3 に至るはずのパスを一部記述しそこなう事で発生します。問題は 2 のステップの途中でなぜバグが混入されるか。

                大抵の場合、メモリ管理が「主目的ではない」ために(主目的なプログラムって malloc/free 自身程度しか私は知らない)、デザインがプログラマの頭の中にしかない場合に問題が発生します。2の記述中に集中が阻害される事象が発生し、回復した時には頭の中のデザインが微妙に違っている。結果として処理順序が変化しメモリリークが起こる。メモリリークがある、というのはプログラミング中にそういうイベントが起こった事を表します。

                メモリリークがあるというのは、「他のバグをも発生させている可能性が高い」事象が結構大切な部分をコーディングしている最中に起こった、と言う事なんです。演算部のコーディングそのもので間違える可能性は低いでしょう。一番大事な部分であり、一番意識を集中させているところですからね。でも「数字をどこから持ってくるか」「数字をどこに書き出すか」周りにはバグが混在する公算は非常に高い。間違った数字を正しく演算したら、間違った結果になるに決まっています

                .

                メモリリークが生じていないプログラムを組める人は、プログラムのアウトラインデザインを紙に描いている人です。コーディングを始める前に何をどの順番で処理するのかを全部図にする。で、一塊づつコーディングをしていき、一塊単位で バージョン管理システム(自分用)にチェックインしていく。もし、何らかの理由で塊をコーディングしている最中に邪魔が入ったら、そこのコーディングを開始する前までロールバックして組みなおす。なのでチェックインはものすごく細かい単位で行われる。そのために「自分用」のバージョン管理システムをプロジェクトのそれとは別に持っている。

                このような組み方をしている人は、メモリリークもめったに起こしませんし、アドレス異常も起こしません。なので、計算部そのものに問題が無ければ、結果は信頼できるでしょう。

                --
                fjの教祖様
                親コメント
              • by Anonymous Coward

                >> メモリリークというバグが単独で発生し、なおかつそれ以外の問題を引き起こさない、と言うのは奇跡的な状況です。

                プログラムの一般論としてはその通りだと思います.しかし,それは暗黙のうちに「メモリリークの無いプログラムを書こうとしている」という前提の下で「どこかで謎のメモリリークが発生してる.その計算結果が信頼できるか?」って命題になっているわけです.一方,ここの議論で主張されてるのは「計算結果に影響の無いところで解放されてないメモリがあることはわかった上でプログラムを書いている」って話だから,根本的に違う話をしてるわけです.

              • 「計算結果に影響の無いところで解放されてないメモリがあることはわかった上でプログラムを書いている」って話だから

                それはもっと根源的に、かつ当然の事として否定されていると思っていたのだが。

                あるプログラムを考えて欲しい。このプログラムには2つのメモリリークバグが入っている。あなたは神様なのでそのことを知っている。

                一箇所は意図的なもので、プログラマには悪影響がないことが判っている(本当か、本当にその判断は正しいのか?? と疑うのはとりあえずやめておこう)。

                もう一箇所は意図していないもので、他の部分への影響があるかどうかは判らない(そりゃそうだ。プログラマはそもそも存在を知らないんだもの、検討しているわけが無い)。

                さ。このプログラム、動かしてみたらメモリリークをしているらしい。第3者はこのプログラムの出力結果を信頼できるか出来ないか?

                当然、できない。
                メモリリークが最初のバグに起因しているのか、二つ目のバグが存在してそいつに起因しているのか、わからないからだ。

                .

                意図したバグは、意図しないバグの存在を隠蔽する。
                故に、意図したバグの含まれているプログラムは信頼できないし、してはならない。
                プログラムを信頼して欲しければ、バグを 意図的に 埋め込んだり、放置したりしてはならない。

                --
                fjの教祖様
                親コメント
              • by Anonymous Coward
                出力結果が信頼できるかはメモリリークとは無関係。リークがあるから信頼できない?そんな馬鹿な。
                結果はリークとは無関係に、別の方法でチェックされるべき。リークがあろうがなかろうが、間違った結果であればエラーと出るべきだ。
                間違いの原因はリークかもしれないし、それ以外かもしれない。リークがないことは、結果の正当性を全く担保しない。
                担保するのは出力結果のチェックのみ。
                そのチェックが信用できない?それは他のどんなエラーに関しても言えることだ。

                自分は神様ではないので、何が正しいのかわからない。わからないので、プログラムの出した結果を何一つとして信用しない。
                信頼するのはチェックを受けた結果のみであり、リークの有無はまるで関係ない。
              • 出力結果が信頼できるかはメモリリークとは無関係。

                それは#1717270 [srad.jp]の主張に対する答になっていない。

                #1717270 [srad.jp] は「計算結果に影響の無いところで解放されてないメモリがあることはわかった上でプログラムを書いている」という主張だ。

                私が言っているのは そのような「わかった」は存在しない というものだ。

                --
                fjの教祖様
                親コメント
              • by Anonymous Coward
                okky氏は随分熱くなっていらっしゃるみたいだけど、
                自分は「メモリリーク」って単語よく知らなくって、なんか分からないけどちょっとしたバグの一種なのかなって思ってたけど、ぐぐったら大したことなくも無いんですね。ひょっとして元ACも同じ勘違いしてるんじゃないかな。

                自分はFortran位しかいじらないんだけど、普通にFortran77組んでも「メモリリーク」って起こることあるのかな。多分、学者の「適当に」書くプログラムレベルじゃ、「メモリリーク」すら起こせないと思いますよ。
              • by Anonymous Coward

                というよりも。メモリリークというバグが単独で発生し、なおかつそれ以外の問題を引き起こさない、と言うのは奇跡的な状況です。

                メモリリークがバグじゃなくて仕様なら良いんじゃないの。計算どおり、アロケーションエラーが発生すれば、信頼性抜群。

              • というよりも。メモリリークというバグが単独で発生し、なおかつそれ以外の問題を引き起こさない、と言うのは奇跡的な状況です。

                参照カウント式のGCのある言語での循環参照とかはどうでしょう?
                グラフをリンクで表現してるとありがちっぽい気も…。

                親コメント
          • by Anonymous Coward

            最近のFORTRANは生ポインタをいじれたりするんでしょうか?
            そんな「高級」言語はC/C++が最初で最後にしてほしかったのに。

            • 最近のFORTRANは生ポインタをいじれたりするんでしょうか?

              生ポインタをいじれなくても、メモリリークやアドレスミスはなんぼでも生じるよ。

              基本的に「メモリリーク」するためには「動的に」メモリを取得出来る必要があるだろう? これが可能であるためには動的に得たメモリを指定、管理する表現と機構が必要なんだが、そこに必ずメモリリークやアドレスミスを起こす要素が残る。

              --
              fjの教祖様
              親コメント
      • いやそれは「データを喰わせれば(正しい)アウトプットが得られる」ならOK。って意味じゃないかと。

        毎回異常終了するとか、明らかにおかしいデータ(数値の所に文字列とか)を喰わせたら落ちるとか、そーゆー修正は後回しでいーんじゃね?
        親コメント
      • by saitoh (10803) on 2010年02月12日 16時01分 (#1717321)
        ただのいいがかりにしか読めない。 プログラムにバグが無いことは証明困難。メモリリークがあろうが無かろうが、未知のバグは存在し得る。 それをメモリリークの有無が重要なバグの証拠であると勝手に位置付けてるだけじゃん。 メモリリークが無い筈のプログラムでリークがあればそりゃ何らかのバグが存在することはあきらかだけど。

        mallocだけしてfreeを一切呼ばないプログラムってののほう(出力結果に影響する)バグは少ないと思うが。もちろん、プログラムの適用範囲(扱えるデータ量限界)は小さくなってしまうが。

        親コメント

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

処理中...