scientific-computing - 科学的プログラミングにおける再現性

Question

誤った結果を生成することに加えて、科学的プログラミングにおける最悪の恐怖の 1 つは、生成した結果を再現できないことです。分析の再現性を確保するのに役立つベスト プラクティスは何ですか?

Answer 1

• 元の生データをオンラインで公開し、自由にダウンロードできるようにします。
• コード ベースをオープン ソースにし、オンラインでダウンロードできるようにします。
• 最適化でランダム化を使用する場合は、同じ結果が繰り返されるように、結果として得られる最良の値を選択するか、固定のランダム シードを使用して、最適化を数回繰り返します。
• 分析を実行する前に、データを「トレーニング/分析」データセットと「テスト/検証」データセットに分割する必要があります。「トレーニング」データセットで分析を実行し、得られた結果が「検証」データセットに保持されていることを確認して、分析が実際に一般化可能であり、問​​題のデータセットの特性を単に記憶していないことを確認します。

最初の 2 点は非常に重要です。なぜなら、データセットを利用できるようにすることで、他のユーザーが同じデータに対して独自の分析を実行できるようになり、独自の分析の有効性に対する信頼レベルが高まるからです。さらに、特にリンクされたデータ形式を使用している場合は、データセットをオンラインで利用できるようにすることで、クローラーがデータセットを他のデータセットと集約できるようになり、それによってより大きなデータセットでの分析が可能になります...多くの種類の研究では、サンプルサイズ小さすぎて結果に確信が持てない場合があります... しかし、データセットを共有することで、非常に大きなデータセットを構築することができます。または、誰かがあなたのデータセットを使用して、他のデータセットで実行した分析を検証する可能性があります。

さらに、コードをオープン ソースにすることで、コードと手順を同僚がレビューできるようになります。多くの場合、そのようなレビューは、欠陥の発見、または追加の最適化と改善の可能性の発見につながります。最も重要なことは、他の研究者があなたの方法を改善できることです。あなたがすでに行ったことをすべてゼロから実装する必要はありません。研究が車輪の再発明ではなく改善のみに集中できる場合、研究のペースが大幅に加速されます。

ランダム化に関しては...多くのアルゴリズムはランダム化に依存して結果を達成しています。確率的およびモンテカルロ法は非常に一般的であり、特定のケースでは収束することが証明されていますが、異なる結果が得られる可能性があります。同じ結果が確実に得られるようにする方法は、一定の回数だけ計算を呼び出すコード内のループを作成し、最良の結果を選択することです。十分な繰り返しを使用すると、局所的な最適値に行き詰まる代わりに、グローバルまたはほぼグローバルな最適値を見つけることが期待できます。もう1つの可能性は、事前定義されたシードを使用することです。これは、私見ではありませんが、ローカルオプティマで立ち往生するシードを選択できるため、良いアプローチではありません。さらに、異なるプラットフォームの乱数ジェネレーターがそのシード値に対して同じ結果を生成するという保証はありません。

Answer 2

私は研究地球物理学者のチームに組み込まれたソフトウェア エンジニアであり、現在 (いつものように) 必要に応じて結果を再現する能力を向上させるために取り組んでいます。私たちの経験から得られたいくつかの指針を次に示します。

1. ソースコード、入力データセット、メイクファイルなど、すべてをバージョン管理下に置く
2. 実行可能ファイルをビルドするとき: 実行可能ファイル自体にコンパイラ ディレクティブを埋め込み、ビルド ログに UUID のタグを付け、実行可能ファイルに同じ UUID のタグを付け、実行可能ファイルのチェックサムを計算し、すべてを自動ビルドし、データベースを自動更新します (OK、それは単なるフラットです)。ファイル) ビルドの詳細など
3. Subversion のキーワードを使用して、ソースのすべての部分にリビジョン番号 (など) を含めます。これらは、生成される出力ファイルに書き込まれます。
4. 新しいバージョンのコードまたは新しいビルド バリアントが同じ (または十分に類似した) 結果を生成することを確認するために、多くの (半) 自動化された回帰テストを行っています。発生する。
5. 私の地球物理学者の同僚は、入力の変化に対するプログラムの感度を分析しています。コンパイラの設定やプラットフォームなどに対する (地域ではなくコードの) 感度を分析します。

私たちは現在、すべてのジョブ実行の詳細を記録するワークフロー システムに取り組んでいます: 入力データセット (バージョンを含む)、出力データセット、使用されたプログラム (バージョンとバリアントを含む)、パラメーターなど - 一般に来歴と呼ばれるもの。これが稼働すると、結果を公開する唯一の方法は、ワークフロー システムを使用することになります。詳細な設計はまだ行っていませんが、すべての出力データセットには独自の来歴の詳細が含まれます。

数値結果を最下位桁まで再現することについては、かなり (おそらくあまりにも) リラックスしています。私たちの仕事の根底にある科学と、基本的なデータセットの測定に固有のエラーは、2または3 sfを超える数値結果の妥当性をサポートしていません

ピアレビューのためにコードやデータを公開するつもりはありません。私たちは石油ビジネスに携わっています。

Answer 3

すでにたくさんの良い提案があります。追加します（両方とも苦い経験から---出版前に、ありがたいことに！）、

1) 結果の安定性を確認します。

• データのいくつかの異なるサブセットを試す
• 入力をリビンする
• 出力を再ビン化する
• グリッド間隔を微調整する
• いくつかのランダム シードを試す (該当する場合)

安定していない場合は、完了していません。

上記のテストの結果を公開します (または、少なくとも、証拠を保持し、それを行ったことを言及してください)。

2) 中間結果の抜き取りチェック

はい、おそらく小さなサンプルでメソッドを開発し、その後、混乱全体をすりつぶします. その粉砕が行われている間、数回真ん中にピークを迎えます. さらに良いのは、可能な場合は、中間ステップに関する統計を収集し、その中の異常の兆候を探すことです。

繰り返しますが、驚きがあれば、戻ってやり直す必要があります。

そして、繰り返しますが、これを保持および/または公開してください。

---

私が好きなことはすでに述べました

• ソース管理 --- とにかく自分で必要です。
• ビルド環境のロギング。同じの出版は素晴らしいです。
• コードとデータを利用できるようにすることを計画します。

誰も言及していない別のもの：

3) コードを文書化する

はい、あなたはそれを書くのに忙しく、おそらくそれを設計するのに忙しいでしょう。しかし、私は詳細なドキュメントを意味するのではなく、すべての驚きを適切に説明しています。とにかくそれらを書き留める必要があるので、紙の上で有利なスタートを切ると考えてください. また、ドキュメントをソース管理に保管して、不要になったチャンクを自由に破棄できるようにすることもできます。

ビルド手順と「実行方法」の宣伝文を含む小さな README を作成しても問題ありません。コードを利用できるようにすると、人々はこのようなことについて質問します...さらに、私にとっては、コードをチェックすることで、順調に進むことができます.

Answer 4

プログラム コードを公開し、レビューできるようにします。

これは決してあなたに向けられたものではありませんが、ここに私の暴言があります：

納税者の資金によって後援された仕事をする場合、査読付きジャーナルに結果を公開する場合は、オープン ソース ライセンスまたはパブリック ドメインでソース コードを提供してください。誰かが思いついたこの素晴らしいアルゴリズムについて読むのにうんざりしています.xを実行すると主張していますが、ソースコードを検証/チェックする方法はありません. コードが見えない場合は、アルゴリズムの実装が非常に劇的な違いになる可能性があるため、結果を確認できません。

私の意見では、納税者が支払った研究を他の研究者の手の届かないところに置くことは道徳的ではありません. 論文を発表することは科学に反しますが、実用的な仕事という点で、一般の人々に具体的な利益をもたらしません。

Answer 5

以前の回答の多くは、質問の「科学計算」の部分を見逃しており、あらゆる科学に適用される非常に一般的なもので回答したと思います（データと方法を公開し、CSに特化しています）。

それらに欠けているのは、さらに専門化する必要があるということです。使用したコンパイラのバージョン、コンパイル時に使用したスイッチ、使用したオペレーティング システムのバージョン、使用したすべてのライブラリのバージョンを特定する必要があります。リンク先、使用しているハードウェア、マシンで同時に実行されていた他のものなど。これらの要因のすべてが重要な方法で結果に影響を与えた論文が公開されています。

たとえば、(Intel ハードウェアで) FPU の 80 ビット float を使用するライブラリを使用していて、O/S アップグレードを実行すると、そのライブラリが 64 ビット double のみを使用するようになり、結果が大幅に変わる可能性があります。問題は、少しでも調子が悪いことでした。

コンパイラのアップグレードにより、デフォルトの丸め動作が変更される可能性があります。または、単一の最適化により、2 つの命令が実行される順序が反転する可能性があります。これもまた、条件の悪いシステムではブームとなり、結果が異なります。

実際のテストで「最高」を示す準最適アルゴリズムのファンキーな話がいくつかあります。これは、過熱時に CPU の速度を自動的に低下させるラップトップでテストされたためです (これは最適アルゴリズムが行ったことです)。

これらは、ソース コードやデータからは見えません。

Answer 6

コード、データ、および結果をインターネットに投稿します。紙にURLを書いてください。

また、「コンテスト」にコードを提出してください。例えば、音楽情報検索ではMIREXがあります。

Answer 7

何らかの方法で構成パラメーターを記録します (たとえば、特定の変数を特定の値に設定できる場合)。これは、データ出力またはバージョン管理にあります。

常にプログラムを変更している場合 (私はそうです!)、使用しているプログラムのバージョンを必ず記録してください。