MCMCプログラムをデバッグするための標準的なテクニックはありますか？

MCMCプログラムのデバッグは非常に困難です。いくつかの問題が原因で問題が発生します。

（a）アルゴリズムの循環的性質

他のすべてのパラメーターを条件としてパラメーターを繰り返し描画します。したがって、実装が適切に機能していない場合、問題は反復サンプラーのどこにでもある可能性があるため、バグを特定することは困難です。

（b）正解は必ずしもわかっていない。

収束したかどうかを判断する方法はありません。これはある程度、シミュレートされたデータでコードをテストすることで軽減できます。

上記の問題に照らして、MCMCプログラムのデバッグに使用できる標準的な手法があるかどうか疑問に思いました。

編集する

自分のプログラムのデバッグに使用するアプローチを共有したかったのです。もちろん、私はPeterRが述べたすべてのことをします。それらとは別に、シミュレーションデータを使用して次のテストを実行します。

1. すべてのパラメーターを真の値から開始し、サンプラーが真の値から離れすぎているかどうかを確認します。

2. 反復サンプラーにパラメーターを描画するかどうかを決定するフラグが、反復サンプラーの各パラメーターにあります。たとえば、フラグ「gen_param1」がtrueに設定されている場合、反復サンプラーで完全な条件から「param1」を描画します。これがfalseに設定されている場合、 'param1'はその真の値に設定されます。

サンプラーの作成が完了したら、次のレシピを使用してプログラムをテストします。

• 1つのパラメーターの生成フラグをtrueに設定し、他のすべてのフラグをfalseに設定して、true値に関して収束を評価します。
• 最初のパラメーターと組み合わせて別のパラメーターの生成フラグを設定し、再度収束を評価します。

上記の手順は私にとって非常に役に立ちました。

標準プログラミングの練習：

• デバッグ時には、乱数の固定ソース（つまり、同じシード）でシミュレーションを実行します。これにより、変更はコードの変更によるものであり、異なる乱数によるものではありません。
• 答えがわかっているモデル（または複数のモデル）でコードを試してください。
• バグを少なくするために、良いプログラミングの習慣を採用してください。
• あなたが得る答えについて、彼らが意味をなすかどうかなどについて、非常に熱心に考えてください。

がんばって、たくさんのコーヒーを！

私はここで共有する憂鬱であまり具体的でない逸話を持っています。統計学のMT研究者の同僚としてしばらく時間を過ごしました。本当に大きくて複雑なモデルを見たいなら、もう探す必要はありません。

彼は彼自身の娯楽のために私をNLPブートキャンプに通していた。私は一般的に、単体テストとデバッガーで生き死ぬプログラマーのような人です。Symbolicsの若い頃、私は「プログラミングは空のエディターバッファーをデバッグしている」という格言に悩まされました。（パーセプトロンモデルをトレーニングするようなものです。）

だから、私は彼に尋ねました、「どうやってこれをテストしてデバッグするのですか？」彼は、「あなたは、最初にそれを正しく理解します。あなたはそれを（彼の場合、しばしば紙の上で）非常に注意深く検討し、非常に注意深くコード化しました。とてもスリムだ」と語った。

PeterRの回答の良いヒント。実際のデバッグに関するこれ以上のヒントはありませんが、コードにバグがあるかどうかをテストするための非常に便利な手順が見つかりました。これについては、このペーパーで説明します。

http://pubs.amstat.org/doi/abs/10.1198/016214504000001132

基本的には、2つのシミュレーションを行うというアイデアです。1つはモデルのパラメーターを（おそらく）推測するためのMCMCです。2番目のシミュレータは、以前のパラメータを単純にサンプリングします。両方のシミュレータのパラメータからデータを生成し、パラメータとデータの同時分布を比較する検定統計量を計算します。MCMCコードが事後からパラメーターを正しくサンプリングすると、検定統計量はN（0,1）の分布になります。テスト統計を計算するためのコードが利用可能です。