四捨五入

unibonさんの書き込み (2003-07-29 14:50) より:
long のキャストは、切捨てではなく、四捨五入に似た丸めかもしれません

0.1を55回加算すると、Console.WriteLine の出力は 5.5 に見えますが、
実際には 5.5 より小さい値(5.499999...)になっているのでしょう。
すなわち、Console.WriteLine が過度に丸めています。
したがって、この段階ですでに変数の値が誤差を持っていることになります。

＃以下、あとで追加。
Console.WriteLine が丸めているわけではなく、
数値を文字列に変換するモジュールが丸めています。

yamasaさんの書き込み (2003-07-29 15:47) より:

引用:
unibonさんの書き込み (2003-07-29 14:50) より: long のキャストは、切捨てではなく、四捨五入に似た丸めかもしれません

C#では double -> long のキャストは切捨て(ゼロに向かって最も近い整数値への丸め)です。
http://www.microsoft.com/japan/msdn/library/ja/csspec/html/vclrfcsharpspec_6_2_1.asp

yamasaさんの書き込み (2003-07-29 15:47) より:
この例で私が意図していたのは、
「精度の高いdoubleを使用していても、ごく単純な演算とMath.Round()の組み合わせで
あっという間に誤差が膨れ上がってしまう」
ということです。

unibonさんの書き込み (2003-07-29 16:37) より:

引用:
引用: 0.1を55回加算すると、Console.WriteLine の出力は 5.5 に見えますが、 実際には 5.5 より小さい値(5.499999...)になっているのでしょう。 すなわち、Console.WriteLine が過度に丸めています。 したがって、この段階ですでに変数の値が誤差を持っていることになります。 ＃以下、あとで追加。 Console.WriteLine が丸めているわけではなく、 数値を文字列に変換するモジュールが丸めています。 この例で私が意図していたのは、 「精度の高いdoubleを使用していても、ごく単純な演算とMath.Round()の組み合わせで あっという間に誤差が膨れ上がってしまう」 ということです。

演算の過程で誤差が生じるのではなく、
演算の対象として例示された値(10000000000049999)が、
演算前に、すでに double で表現できる整数の範囲を
超えていることがもっとも大きな要因だと思います。
この値を表現するには約53.15ビット必要ですが、
double の仮数部のビット数は53ビットです。

yamasaさんの書き込み (2003-07-29 02:08) より:

引用:
Jittaさんの書き込み (2003-07-28 18:32) より: 　１０万分の１にして、0.5足して、int型に代入し、１０万倍する。FAQ「小数点ｘ桁で四捨五入する」と、考え方は同じです。

そのやり方には大きな落とし穴があります。
計算に浮動小数点を使用していた場合、丸め誤差により
正しくない値になってしまうことがあります。

yamasaさんの書き込み (2003-07-29 17:28) より:
???
ここで私が言及しているのは、
// おまけ: 0.1を55回加算してからRound()
以降の部分についてですよ。

damepgさんの書き込み (2003-07-28 18:02) より:
Dim aa as Integer = 2367896
↓
一万の位「6」を四捨五入して「2400000」にしたい！