6

µL単位で液体の量を追跡しているアプリケーションがあります。現在、システム全体のボリュームの保存に「double」を使用していますが、ほとんどの場合、これは正常に機能します。ただし、これらのボリュームを多数加算および減算し始めると、さまざまな累積エラーが忍び寄り始めます。エラーの大きさは非常に小さいですが、しきい値の比較で問題が発生し、突然ボリュームがごくわずかな量で予想よりも小さくなります。検証の失敗を引き起こします。これは、浮動小数点演算の累積を実行する際のかなり一般的な問題であることを理解していますが、この問題にどのように対処するのが最善か疑問に思っています。私が持っていたいくつかの考え：

  1. すべての二重参照を整数に置き換え、代わりにすべてをnLで追跡できます。これは間違いなく問題を解決しますが、それは非常に侵襲的な変更です。このシステムはまだ実稼働環境で使用されていません。つまり、後で適用するよりも、今すぐ適用する方がはるかに簡単です。

  2. doubleの代わりにDecimalを使用できます。これは整数に変更するよりも侵襲的ではありませんが、それでもかなり重要な変更が必要です。

  3. すべてのボリューム比較で、指定されたエラー許容度を考慮に入れるように要求できます。これは主に私が現在行っていることですが、比較コードが醜くなり、パターンの適用を忘れないようにするためにコードレビューが必要になります。

  4. エラーの蓄積を防ぐために、各計算の後に指定された許容誤差への丸めを実行できます。これにより比較がより明確になりますが、割り当てがある場合はどこでも同様の問題が発生します。

この問題にも苦労している人にとって、どのソリューションが最もクリーンに実装できるのでしょうか。累積計算を実行するときに知っておくべき他の落とし穴はありますか？

4

1 に答える 1

2

理想的には、

  • 丸め（近似）エラーの影響を受けないデータ型を使用し、
  • 小数点以下の桁数を四捨五入
  • 正確な時に。

倍精度浮動小数点数の広い範囲は必要ありません。おそらく整数は使いたくないでしょう。それらはわずかに高速ですが、それらの使用はより複雑です。数値または小数を使用します。数値および小数のデータ型は、丸め誤差や近似誤差の影響を受けません。しかし、それでもプログラミングを不注意にしたり、だらしなくしたりすることはできません。double型の変数に数値を割り当てると、問題がすぐに発生します。

適切な小数点以下の桁数と適切な時間の意味は、アプリケーションによって異なります。小数点以下の桁数は、最終値として保存する必要のある桁数よりも多い場合があります。適切な時期は、中間計算の数と性質によって影響を受ける可能性があります。

時々、人々が丸め誤差と呼ぶものは、実際には近似誤差です。10進値rを浮動小数点変数またはデータベース列に格納するようにコンピューターに指示すると、実際にはrに最も近い浮動小数点近似が格納されます。

FP演算の正規リファレンス

于 2013-02-25T18:12:14.403 に答える