問題タブ [floating-accuracy]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
math - いくつかの丸め誤差を回避するには?
.NET でいくつかの地理座標を処理するメソッドがあり、座標の 1 つに 256 が渡された場合に 0 になるような座標ペアを格納する構造体があります。ただし、ある特定のインスタンスでは、約 255.99999998 が計算され、構造体に格納されます。255.9999998 が出力されてもかまいませんが、デバッガーが 255.99999998 を表示したときに 256 が出力されるという事実は問題です。保存と表示の両方を 0 にするとさらに良いでしょう。
具体的には、比較の問題があります。255.99999998 は 256 に十分近いので、256 と等しくなるはずです。double を比較するときはどうすればよいですか? ある種のイプシロン値を使用しますか?
編集:具体的には、私の問題は、値を取得し、いくつかの計算を実行してから、その数値に対して反対の計算を実行し、元の値を正確に戻す必要があることです。
c# - 異なる言語/アーキテクチャ/オペレーティング システムで比較的小さい数の対数を取る
Javaで私は実行します:
出力: -0.008000042667076265
C# で実行: <- 修正済み
出力: -0.175281838 (プログラムの後半で出力)
Google は次のように主張しています。
出力: -0.00347437439
また、MacOS も同じことを主張しています (Google と Snow Leopard の最初の違いは約 10^-8 で、無視できます。
これらの結果がすべて非常に大きく異なる理由があるのでしょうか、それとも非常に明白なものを見落としているのでしょうか? (JavaとC#の両方がベースeを使用していることを確認しました)。e のわずかな値の違いでさえ、それほど大きな違いを説明していないようです。助言がありますか?
編集:
Wolfram Alpha で検証すると、Java が正しい (または Wolfram Alpha が対数に Java Math を使用している) こと、および私の C# プログラムが正しい入力を持っていないことが示唆されているようですが、(e^ (google result) - 249/251) 私の意見ではかなり大きな 0.0044 のエラーが発生し、手元に別の問題があることを示唆しています...
python - Python の 10 進数の精度は C の精度と比べてどうですか?
n 番目のフィボナッチ数を見つけるための黄金比の公式を見ていましたが、興味をそそられました。
Python が任意の大きな整数を処理することは知っていますが、小数ではどのような精度が得られるのでしょうか? それは C の double か何かの上にあるだけですか、それともより正確に変更された実装も使用していますか? (明らかに、恣意的な精度ではありません。;D)
c++ - C++ 精度: 文字列から倍精度
double に変換された文字列に対していくつかの操作を実行した後、double の精度に問題があります。
これは、文字列として入力されたすべての数値に当てはまるわけではないため、エラーは一定ではありません。一部の数値にのみ影響します (34.38 は定数のようです)。
現時点で、a = 34.38 および i=100 を渡すと、次のように返されます。
精度が低いため、Valをfloatに変更すると機能しますが、doubleが必要です。
これは、sstream の代わりに atof、sscanf、strtod を使用した場合にも再現されます。
C++ で、文字列を double に正しく変換し、実際に正確な値を返す最良の方法は何ですか?
ありがとう。
c++ - double から float への変換時の桁落ちの検出
double 値から float 値に変換する必要があるコードを書いています。boost::numeric_cast を使用してこの変換を行い、オーバーフロー/アンダーフローを警告します。ただし、その変換により精度が低下するかどうかも知りたいです。
例えば
1988.1 の値を持つ dest を生成します。
この種の精度の損失/丸めを検出できる方法はありますか
sqlite - 浮動小数点数を含む句が失敗するSQLiteクエリ?
次のように、Android ベースの SQLite データベースに float を入れています。
テーブルをクエリすると:
カーソルは空に戻ります。float の値を 37.0 に変更すると、正しく動作し、カーソル内のレコードが返されます。
データベース列の仕様を「REAL」から「float」に変更するなどして、これをある程度テストしました。小数点の後に小数部分がある限り、カーソルは空を返します。何が起こっている?
前もって感謝します!
c# - C# の分散関数が正確な値を返さない
ソースデータ:
分散関数:
Excel と一部のオンライン計算機では、分散が 1.56562E-06 であると表示されますが、私の関数では 1.53492394804015E-06 が得られます。C#に精度の問題があるのか 、それとも何なのか疑問に思い始めます。以前にこの種の問題を抱えている人はいますか?
perl - Fortran は、他の言語と比較して、数値の精度に固有の制限がありますか?
簡単なプログラミング演習に取り組んでいるときに、実変数が正確な値に達したときに終了することを意図した while ループ (Fortran では DO ループ) を作成しました。
精度が使用されているため、等式が満たされず、ループが無限になることに気付きました。もちろん、これは前例のないことではなく、2 つの数値が等しいかどうかを比較するのではなく、2 つの数値の絶対差が設定されたしきい値よりも小さいかどうかを確認することをお勧めします。
残念だったのは、変数が倍精度であっても、ループが適切に終了するために、このしきい値をどれだけ低く設定しなければならなかったかということです。さらに、Perl でこのループの「蒸留」バージョンを書き直したところ、数値の精度に問題はなく、ループは正常に終了しました。
Perl と Fortran の両方で、問題を生成するコードは非常に小さいため、重要な詳細を説明する場合に備えて、ここで再現したいと思います。
Fortran コード
Perl コード
Fortran のコメントアウトされた行は、ループが正常に終了するために使用する必要があるものです。しきい値が 1E-4 に設定されていることに注意してください。
変数の名前は、私が行っていた自習ベースのプログラミング演習に由来するものであり、関連性はありません。
その意図は、速度変数が 1700 に達したときにループが停止することです。
切り捨てられた出力は次のとおりです。
Perl 出力
...
Fortran 出力
...
精度が悪ければ、Fortran の速度と並列化の容易さは何の役に立つでしょうか? 物事を行う3つの方法を思い出します:
正しい道
間違った方法
マックスパワーウェイ
「やり方が間違っているだけじゃないの?」
「うん!でももっと早く!」
冗談はさておき、私は何か間違ったことをしているに違いありません。
Fortran は、他の言語と比較して数値の精度に固有の制限がありますか、それとも (かなりの確率で) 私に問題があるのでしょうか?
私のコンパイラは gfortran (gcc バージョン 4.1.2)、Perl v5.12.1、デュアル コア AMD Opteron @ 1 GHZ です。
perl - Perlモジュロ演算子の質問
最初の例で間違った結果が出力されるのはなぜですか?
c++ - 浮動小数点 C++ コンパイラ オプション | a/b の防止 -> a* (1/b)
私は C++ でリアルタイム数値ソフトウェアを作成しており、現在 Visual-C++ 2008 でコンパイルしています。現在、「高速」浮動小数点モデル ( /fp:fast
)、さまざまな最適化を使用しています。
私の計算の多くには数値的に不安定すぎます。
(参照: Microsoft Visual C++ 浮動小数点の最適化)
に切り替えると/fp:precise
、アプリケーションの実行速度が 2 倍以上遅くなります。オプティマイザーを微調整する (つまり、この特定の最適化を無効にする) か、何らかの方法で手動でバイパスすることは可能ですか?
- 実際の最小限のコード例: -
[私の実際のコードは、ほとんどが行列関連のアルゴリズムです]
出力: VC (cl、バージョン 15、0x86) は次のとおりです。
2 つではなく 1 つの div を持つことは、数値的には大きな問題です (xmm0 は RAM から 1.0f でプリロードされます)。 SSE なしでコンパイルすると、同様の stack-x87-FPU コードが出力されます)。
関数をラップする
精度の問題は解決しますが、第一に、関数レベル (グローバル スコープ) でのみ利用可能であり、第二に、関数のインライン化を防ぎます (つまり、速度のペナルティが高すぎます)。
「正確な」出力も「ダブル」にキャストされています。