私の小さなパッケージにはかなり複雑な問題があります。基本的に、私はrugarchまさにこの目的のために設計されたパッケージで GARCH(1,1) モデルを構築しています。これは一連のソルバー (汎用非線形最適化であるRsolnpおよびによって提供される) を使用し、正常に動作します。nloptrベンチマーク ソリューションを提供することで、メソッドをテストしてtestthatいます。これは、Windows (パッケージを使用するメイン プラットフォーム) でコードを手動で実行することによって以前に取得したものです。
さて、私は最初、いくつかの連続した実行で解が一貫していないときにいくつかの問題を抱えていました。違いは、ソルバーに指定した許容範囲内 (solver = 'hybrid'ドキュメントで推奨されているようにデフォルト) であったため、ある種のランダム化を使用していると推測されます。そのため、ランダム シードと並列化の両方を取り除き (「正当な」理由)、問題は解決されました。Windows では毎回同じ結果が得られるので、R CMD CHECK を実行してtestthat成功します。
その後、少し自動化することにしました。現在、ビルド プロセスはtravisによって制御されています。驚いたことに、Linux での結果は私のベンチマークとは異なります。ログには次のように記載されています。
read_sequence(file_out) が read_sequence(file_benchmark) と等しくない
平均相対差: 0.00000014688
何度か再構築しても同じ結果が得られ、違いは常に同じです。つまり、Linux では解決策も一貫しています。一時的な修正として、プラットフォームに応じて許容限界を設定しており、テストはパスします (最新のビルドを参照)。
要約すると、次のようになります。
- 数値手続きは、Windows プラットフォームと Linux プラットフォームの両方で別々に同じ出力を生成します。
- ただし、これらの出力は異なり、ランダム シードや並列処理が原因ではありません。
私は通常、Windows でのサポートのみに関心があり、公開リリースを行う予定はありません。そのため、これは私のパッケージ自体にとって大した問題ではありません。しかし、非常に広く使用されているソルバーの 1 つに問題がある可能性があるため、注意を喚起しています。
いいえ、コードを修正するように求めているわけではありません。プラットフォームに依存する許容範囲は非常に醜いですが、これまでのところ機能しています。質問は次のとおりです。
- 「正当に」（または「自然に」）説明されている違いにつながる可能性のあるものは他にありますか?
- すべてのプラットフォームで同じ結果を生成するには、低レベルの数値ルーチンが必要ですか? 期待しすぎてしまうことはありますか？
- 私はこれについて多くのことを気にする必要がありますか？これは一般的な状況ですか？