10

私は科学研究コード、特にバイオインフォマティクスを書いています。もちろん、科学では、結果は再現可能でなければなりません。定期的にプロジェクトに関与しておらず、インフラストラクチャを詳細に理解していない人は、正当に私のコードを見て結果を再現したいと思うかもしれません。問題は、そのような人に簡単に提供/説明できるようにコードを自己完結型にすることは、可能な再利用の量を大幅に制限するように思われることです。

  • いくつかの関連プロジェクトで使用されている機能を個人用ライブラリに分解するのは便利なことがよくありますが、何も持たない 5,000 行のコード (製品/リリースの品質を意図していないため、ドキュメントが不十分であることは確かです) を含むライブラリをダンプするのは便利ではありません。すぐに結果を再現したい人が直面している問題を処理します。

  • システムにいくつかの重要なライブラリのセットをインストールし、何も考えずにすぐに使用できるようにしておくと便利なことがよくありますが、プログラマーではなく主に科学者である人に、これらすべてをどのようにセットアップするかを説明するのは便利ではありません。これは、自分で詳細を覚えていない場合に特に当てはまります。(ただし、問題の詳細は科学とは何の関係もない技術的な細目であることに注意してください。)

  • 研究プロジェクトのいくつかの関連する側面のすべてのコードを、多数のオプションを備えた 1 つの大きなプログラムに保持する方が、わずかなバリエーションや試したことごとに完全に自己完結型のコードを記述するよりも便利な場合がよくありますが、繰り返しになりますが、すべてをダンプするのは便利ではありません。結果を再現したいだけの人に、これについて、またはこれらすべてを説明してください。

これらの問題に対処してコードを再利用できるようにする方法はありますか?ただし、結果を再現したい人が妥当な労力でコードを実行できるようにする方法はありますか? 私の質問の中心にあるのは、あまり成熟していないコードの再利用可能なライブラリを作成する可能性であることに注意してください。

4

2 に答える 2

4

この質問に答える1つの方法は、科学プログラミングの世界にある他のツールがどのようにそれを行うかを検討することだと思います。私はこの答えをコミュニティウィキにするつもりです、そして人々は彼らが知っているコードでそれに追加することができます。そうすれば、私たち全員がこの種のものに使用できるアイデアや例のリストになってしまうかもしれません。

  1. 「数十億のオプション」アプローチ

    1. 多くのメニューとサブメニューを備えたGUI：
    2. 多くの引数を持つコマンドラインツール、できればそれらの多くはオプションです
      • とてもたくさん！PETScを使用するツールは、これを使用して線形代数を制御します
    3. うまくいけばオプションである多くの引数を持つ構成ファイルを持っているツール、コマンドラインまたはその他

  2. UNIXの小さなツールのアプローチ-複雑なツールを作成するためにつなぎ合わせることができる多くの小さなツールを構築します。ツールの機能をそのように分解できる場合は、うまく機能します。

    • 分子動力学パッケージGromacs
    • NEMOステラダイナミクスツールボックス
    • 多くの視覚化パッケージもこのように機能します。GUI内で、小さなツールのパイプラインを定義します。 ParaView、OpenDX、VisIT
    • 一般的なPython計算の場合、Ruffusを使用して、小さなツールをより大きなワークフローに編成できます。

  3. ルーチンからツールを構築する：ここでは、プログラムは、問題固有のアプリケーションを断片から構築するスクリプト（およびいくつかの例）が付属するキットとして配布されます。

    • FLASHコードはこれを行うものです。
  4. リンクできる1つ以上のライブラリとして機能を公開します。
    • FFTW、PETSc、GSLなどのツール。多くの場合数学的な性質のものです。
  5. 3 + 4に関連：ツール（常にではありませんが、多くの場合GUI）が、より大きなワークフローに簡単に組み込むことができるプラグイン機能を公開するプラグインタイプのアプローチ
    • ParaViewのような多くの視覚化パッケージ
  6. 関連2：コマンドラインでツールを呼び出す代わりに、ツールには独自のコマンドラインがあり、多くの個別のルーチンを呼び出すことができます。独自のコマンドラインを使用すると、単にシェルに任せるよりも、環境を少し細かく制御できます（ただし、当然のことながら、より多くの作業が必要になります）。
于 2011-03-02T03:50:10.043 に答える
2

これはコメントのはずですが、その小さなボックスにすべてを入れることはできません...

私は科学研究コード、特にバイオインフォマティクスを書いています。もちろん、科学では、結果は再現可能でなければなりません。定期的にプロジェクトに関与しておらず、インフラストラクチャを理解していない人

ここでは、プログラミングに関してインフラストラクチャについて話しているのですね。

結果を再現するために私のコードを正当に見たいと思うかもしれません。問題は、そのような人に簡単に提供/説明できるようにコードを自己完結型にすることは、可能な再利用の量を大幅に制限するように思われることです。

理解できない。なぜ彼らは結果を再現できないのでしょうか? それとも、彼らがあなたのプログラムを再利用したいと言っているのですか?

いくつかの関連プロジェクトで使用されている機能を個人用ライブラリに分解するのは便利なことがよくありますが、何も持たない 5,000 行のコード (製品/リリースの品質を意図していないため、ドキュメントが不十分であることは確かです) を含むライブラリをダンプするのは便利ではありません。すぐに結果を再現したい人が直面している問題を処理します。

（「結果の再現」は別として、それは私の側の言語の問題かもしれません）; あなたの図書館を実際に利用する人がどれだけいるかを自問してください。多くの場合そうであるように、1 つまたは 2 つしかない場合は、彼らのために変更するのは合理的ではないと思います。

私は普段、自分の考え方に合うように私用のライブラリを作っています。純粋に彼らの便宜のために（つまり、あなたはそうではないと思いますが、そのための特別な報酬を得ることなく）彼らに合わせて調整することは、実際には彼らが「私は自分で書く気がしませんでした。どうやって作曲したかなんて考えたくないから、考えなくても簡単に使えるように作り直して」

システムにいくつかの重要なライブラリのセットをインストールし、何も考えずにすぐに使用できるようにしておくと便利な場合がよくありますが、プログラマーではなく主に科学者である人に、これらすべてをどのようにセットアップするかを説明するのは便利ではありません。これは、自分で詳細を覚えていない場合に特に当てはまります。(ただし、問題の詳細は科学とは何の関係もない技術的な細目であることに注意してください。)

研究プロジェクトのいくつかの関連する側面のすべてのコードを、多数のオプションを備えた 1 つの大きなプログラムに保持する方が、わずかなバリエーションや試したことごとに完全に自己完結型のコードを記述するよりも便利な場合がよくありますが、繰り返しになりますが、すべてをダンプするのは便利ではありません。結果を再現したいだけの人に、これについて、またはこれらすべてを説明してください。

もちろん。「科学的コーディング」の問題 (私はその表現が嫌いです) は、プログラムが他の何かに取り組んでいる最中の単なるツールであることです。作業が進むにつれて変更されます。

これらの問題に対処してコードを再利用できるようにする方法はありますか?ただし、結果を再現したい人が妥当な労力でコードを実行できるようにする方法はありますか?

特定の場合に VCS でコードを分岐し、必要なものに最も近いバージョンを誰かに提供することは、常に私にとってはうまくいきました。

于 2011-03-02T14:29:54.483 に答える