問題タブ [rounding-error]

データベースには 2.700000002 という値があります。SQL SERVER 2005 の Management Studio でクエリを実行すると、2.7 になります。しかし、SQL SERVER 2000 クエリ アナライザーで実行すると、2.700000002 になります。

2.70000002 は正しいです。なぜ SQL SERVER 2005 は値を丸めたり下限値を選択したりして値を変更しようとしますか?

重複の可能性:
浮動小数点数の精度の問題への対処

一方、99.99 * 0.01 = 0.99

明らかに、これは古くからある浮動小数点の丸めの問題ですが、この場合の丸め誤差はかなり大きいように思えます。つまり、結果が 0.99990000001 または同様の「近い」結果になると予想していた可能性があるということです。

記録として、JavaVM と .Net 環境で同じ答えを得ました。

現在、System.Decimals を使用して、開発中の .NET アプリケーションで数値を表しています。小数は丸めによる誤差を最小限に抑えるように設計されていることは知っていますが、特定の数値、たとえば 1/3 は小数として表すことができないため、計算によっては小さな丸め誤差が生じることも知っています。このエラーの大きさは非常に小さく、取るに足らないものになると思いますが、同僚は同意しません。したがって、アプリでの丸めによる誤差の大きさを推定できるようにしたいと考えています。たとえば、現在の「取引」の合計を計算しており、1 日あたり約 10,000 件の「取引」を行い、現在の合計を計算するために約 5 ～ 10 の小数演算 (add、sub、div、mul など) があるとします。受け取った各取引の新しい現在の合計、ラウンドエラーのマグネイトの順位は？これを計算する手順も答えてくれるといいので、将来自分でこれを行う方法を学ぶことができます。

double 値から float 値に変換する必要があるコードを書いています。boost::numeric_cast を使用してこの変換を行い、オーバーフロー/アンダーフローを警告します。ただし、その変換により精度が低下するかどうかも知りたいです。

例えば

1988.1 の値を持つ dest を生成します。

この種の精度の損失/丸めを検出できる方法はありますか

decimals一部をに変換しようとしvarcharていますが、丸められています。

誰かが理由を教えてもらえますか?

注: はい、緯度/経度が間違っていることはわかっています。すぐに切り替えます。

検討 、

しかし、fの値を出力すると、1.123455が得られます。

四捨五入されています。また、問題は、コード内のfloatのデータ型を変更できないことです。助けてください。

私は最近、丸めを最小化するためのカハン（または補償）加算アルゴリズムに出くわしました。除算および/または乗算、および減算（ある場合は、私は知っています）に同等のアルゴリズムがあるかどうかを知りたいです。連想性について）。任意の言語、擬似コード、またはリンクでの実装例は素晴らしいでしょう！

ありがとう

財務データの計算に関しては、「丸め」基準の存在に興味があります。私の最初の考えは、データがユーザー（プレゼンテーション層）に提示されているときにのみ丸めを実行することです。

「丸められた」データがその後の計算に使用される場合、「丸められた」数値または「生の」数値を使用する必要がありますか？誰かアドバイスはありますか？

銀行の丸めなど、さまざまな丸め方法を知っていることに注意してください。

SQL Server 2008 では、XML 属性に値 "0.01" があります。OPENXML を使用して、XML を一時テーブルに分割します。該当する列が実数型(単精度)の場合、表では0.01と出てきます。良い。ただし、精度が float (倍精度) の場合は、0.00999999977648258 となります。これは意味がありません。なぜこれを行うのですか？

次の質問は、値が一時テーブルでどのように表現されているかに関係なく、集計関数を実行すると、常に 0.00999999977648258 として返されるということです。これにより、検証エラーが発生しています。プロシージャは、入力が小さすぎる (< 0.01) と報告していますが、これは正しくありません。

これらの丸め誤差が発生する理由とそれらを克服する方法はありますか?

すでに試しました：列をvarcharにします。

EDIT2：

回答に基づいて、問題はIEEE数値が0.01を正確に表すことができないという事実によるものであることを理解しています。したがって、次の質問:

「WHERE {computed} < 0.01」、なぜその 0.01 もここで丸められないのですか? もしそうなら、式は予想通りに評価されます (つまり、0.00999999977648258 は < 0.00999999977648258 ではありません)。

編集:サンプルコードを表示

このコードはエラーを生成します。示されたフロートを実数に変更すると、エラーが「消えます」。少なくとも一時テーブルに関する限り。

UNIXベースのシステムで問題が発生しました。sprintfが適切に値を切り上げません。

例えば

それは88,888,888,888,885.875です。小さい数でうまく機能するように見えるので、私はそのような具体的で大きな例を挙げています。

私はそれを次のように使おうとしています

Windowsでは、次のようになります。

たとえばAIXの場合ですが、Linuxでも表示されます。

なぜこうなった？Win /Unixでアイデアとそれを同じように動作させる方法

ありがとう