タグ付けされた質問 「floating-point」

私はかなり大きなモデル（約5000行）をCで記述しています。これはシリアルプログラムであり、乱数の生成はどこにもありません。FFTを使用する関数にFFTWライブラリを使用します。FFTW実装の詳細はわかりませんが、その中の関数も確定的であると想定しています（エラーが発生した場合は修正してください）。 私が理解できない問題は、同じマシン（同じコンパイラ、同じライブラリ）での同一の実行の結果に小さな違いがあることです。 私は、倍精度変数を使用して、変数に結果を出力するvalue例えば、私が発行します fprintf(outFID, "%.15e\n", value);か fwrite(&value, 1, sizeof(double), outFID); そして、私は常に次のような違いを得るでしょう： 2.07843469652206 4 e-16対2.07843469652206 3 e-16 私はこれがなぜなのかを理解するために多くの時間を費やしてきました。私は最初、メモリチップの1つが故障していると思っていたので、注文して交換しましたが、役に立ちませんでした。その後、同僚のLinuxマシンでコードを実行してみたところ、同じ性質の違いが生じました。 何が原因でしょうか？今は小さな問題ですが、「氷山の一角」（深刻な問題）なのでしょうか。 数値モデルを扱う誰かがこの問題に遭遇した場合に備えて、StackOverflowの代わりにここに投稿すると思いました。誰かがこれに光を当てることができれば、私は多くの義務があります。 コメントの フォローアップ： Christian ClasonとVikram：まず、私の質問に関心をお寄せいただきありがとうございます。あなたがリンクした記事は、次のことを示唆しています：1.丸め誤差は精度を制限し、2。異なるコード（一見害のない印刷ステートメントを導入するなど）がマシンのイプシロンまでの結果に影響を与える可能性があります。効果fwriteとfprintf機能を比較していないことを明確にすべきです。どちらか一方を使用しています。特に、両方の実行で同じ実行可能ファイルが使用されます。fprintfOR を使用しているかどうかに関係なく、問題が発生すると単に述べていfwriteます。 したがって、コードパス（および実行可能ファイル）は同じであり、ハードウェアも同じです。これらすべての外部要因が一定に保たれている場合、基本的にランダム性はどこから来るのでしょうか？不良メモリがビットを正しく保持していないためにビットフリップが発生したのではないかと疑ったので、メモリチップを交換しましたが、これは問題ではないようです。私のプログラムは、1回の実行で数千のこれらの倍精度数値を出力します。ランダムなビットフリップを持つランダムな握りが常にあります。 クリスチャンClasonの最初のコメントへのフォロー：なぜマシンの精度内で0と同じ？doubleの最小の正の数は2.22e-308なので、0に等しくないはずです。私のプログラムは10 ^ -16の範囲（1e-15から8e-17の範囲）で数千の値を出力し、私たちの研究プロジェクトには意味のある変化が見られたので、無意味なものを見ていなかったと思います番号。2 ⋅ 10− 162⋅10−162\cdot 10^{-16} フォローアップ＃2： これは、コメントでの派生的議論を支援するために、モデルによって出力された時系列のプロットです。

10 floating-point  precision  computer-arithmetic 

読んだ （1）条件の悪い操作は、条件の良い操作の前に実行する必要があります。 例として、乗算はそうで​​はないのに減算は悪条件なので、x z− yzバツz−yzxz-yzをとして計算する必要（x − y）z（バツ−y）z(x-y)zがあります。 ただし、両方のアルゴリズムの1次エラー分析では、3倍（*）だけ異なることがわかり、これをステートメント（1）に一般化できる理由もわかりません。また、その重要性を直感的に把握していません。操作の順序。ステートメントは（1）は受け入れられたルールであると思いますか、それについて他の説明がありますか？ *：より具体的には、最初のバージョンには、 eps+3|x|+|y||x|−|y|epseps+3|x|+|y||x|−|y|eps\text{eps}+3\frac{|x|+|y|}{|x|-|y|}\text{eps}第二のバージョンの相対誤差がで囲まれている間 3eps+|x|+|y||x|−|y|eps3eps+|x|+|y||x|−|y|eps3\text{eps}+\frac{|x|+|y|}{|x|-|y|}\text{eps} ここで、epseps\text{eps}はマシンの精度です。 ことをこの分析は、仮定に基づいているi私i番目の中間結果を用いて乗算される(1+εi)(1+εi)(1+\varepsilon_i)（丸め誤差に）、εiεi\varepsilon_iによって囲まIIDランダム変数であるepseps\text{eps}。「一次」とは、ような高次の項ϵiϵjxϵiϵjバツ\epsilon_i\epsilon_jxが無視されることを意味します。

10 stability  floating-point 

浮動小数点演算のライブラリ/パッケージはほとんどありません。浮動小数点表現のさまざまな不正確さを考えると、この増加した精度が固定小数点での作業の複雑さの価値があるかもしれないフィールドが少なくともいくつかない理由が問題になります。 たとえば、固定小数点固有値ソルバーを使用する上で大きな問題はありますか？彼らはどのくらい遅く/速く、不正確/正確でしょうか？ 関連：これとこれ

10 floating-point  numerics 

f(x, y)いくつかの数式を実装する二重浮動小数点数を返す数値関数があり、パラメーターのすべての組み合わせの分析式に対して正しいことxとy、興味があることを確認したいと思います。計算された値と分析浮動小数点数？ 2つの数値がaとであるとしましょうb。これまでのところ、絶対abs(a-b) < eps（abs(a-b)/max(abs(a), abs(b)) < eps）エラーと相対（）エラーの両方がeps未満であることを確認しています。このようにすると、たとえ1e-20程度の数値であったとしても、数値の不正確さをキャッチできます。 しかし、今日、私は問題を発見しました。数値aと分析値bは次のとおりです。 In [47]: a Out[47]: 5.9781943146790832e-322 In [48]: b Out[48]: 6.0276008792632078e-322 In [50]: abs(a-b) Out[50]: 4.9406564584124654e-324 In [52]: abs(a-b) / max(a, b) Out[52]: 0.0081967213114754103 したがって、絶対誤差[50]は（明らかに）小さいですが、相対誤差[52]は大きいです。そのため、プログラムにバグがあると思いました。デバッグにより、これらの数値は非正規であることがわかりました。そのため、適切な相対比較を行うために次のルーチンを作成しました。 real(dp) elemental function rel_error(a, b) result(r) real(dp), intent(in) :: a, b real(dp) :: m, d d = …

10 floating-point 

最近、FORTRAN95で奇妙な問題が発生しました。変数XとYを次のように初期化しました。 X=1.0 Y=0.1 後でそれらを一緒に追加して、結果を出力します。 1.10000000149012 変数を調べたところ、0.1は完全な精度の倍精度で表されていないようです。これを回避する方法はありますか？

10 fortran  floating-point 

2つの浮動小数点数の等価性をテストすることは、プログラミングで通常どのような意味がありますか？ すなわち a == b ここで、aとbはどちらも浮動小数点数です。 私の素朴な印象は、ある程度の耐性イプシロンに対して常に違いをテストするということです。 私が間違っている？フロートの等価性をテストすることは、特定のコンテキストで意味がありますか？ 野生の例はありますか？つまり、実際のコードベースまたはアプリケーションから、gitなどにあります。 PS。floatで等値演算子を使用することは、一部のコンテキストでは実際に意味があると想定しています。そうでなければ、ほとんどのプログラミング言語がそれを許可する理由。

8 floating-point 

浮動小数点数の比較には許容誤差を使用する必要があることを知っています。しかし、ベクトルを比較するために、さまざまな距離メトリックに対応する3つの可能なソリューションを考えることができます。 各ベクトルのコンポーネントを個別に比較します。3つすべてが許容範囲内であれば、ベクトルは等しいです。このオプションは、均一なノルムのように動作し、公差の立方体を提供します。 すべての絶対差の合計をある許容誤差と比較します。これは、タクシーの規範のように動作し、許容範囲のシンプレックスを提供します。 （vecA-vecB）のユークリッド長を計算し、許容範囲内かどうかを確認します。これは、許容範囲を持つ標準ユークリッドノルムを与えます。 しかし、私の主な関心事は数値の安定性です。ユークリッドノルムは最良のオプションのように「感じます」が、すべての計算がより多くの丸め誤差を誘発するのではないかと心配しています。程度は低いですが、オプション2でもエラーが発生する可能性があります。（たとえば、ベクトルのx成分がyおよびzよりもはるかに大きい場合、すべての差を合計すると、yおよびzからの寄与がすべて失われる可能性があります。）現在、オプション1に傾いています。 誰もがこの問題について権威ある立場を取ることを検討できますか？

8 floating-point