不要用float和double來(lái)進(jìn)行精確的小數(shù)計(jì)算
什么?難道它們不就是為了小數(shù)計(jì)算而生的么?在我看到 effective java - item31 的時(shí)候,發(fā)出了這個(gè)孤陋寡聞的疑問(wèn)。
知其然:
為什么說(shuō)不能用 float 和 double 來(lái)進(jìn)行精確小數(shù)計(jì)算呢?
試試執(zhí)行這樣的語(yǔ)句:
System.out.println( 1.00 ? - ? 9 * . 10 ); // 答案是0.09999999999999995?!
你會(huì)發(fā)現(xiàn)結(jié)果和你的小學(xué)數(shù)學(xué)課程有沖突。
知其所以然
之所以出現(xiàn)這樣的奇怪答案,是因?yàn)?/span> float 和 double 不能精確的表達(dá) 0.1 ,或者任何 10 的負(fù) n 次方。他們是設(shè)計(jì)來(lái)進(jìn)行科學(xué)和工程上的計(jì)算,提供精確的近似值的。它們?cè)谏婕敖鹑诜矫娴挠?jì)算則是不在行的。因?yàn)榻鹑诜矫嬉蠼^對(duì)的精確。
解決方法
用 BigDecimal , int 或者 long 。

?
把所有牽涉到的小數(shù)都以這種方式轉(zhuǎn)變?yōu)?/span> BigDecimal 對(duì)象,然后用它提供的方法進(jìn)行計(jì)算。
你就得到了精確的計(jì)算結(jié)果,隨之而來(lái)有兩個(gè)小缺點(diǎn),一個(gè)。。。很顯然,就是比直接用原始類型要麻煩,也不能用 +,-,*,/ 這些直觀的符號(hào)了;第二個(gè)就是速度會(huì)慢一點(diǎn),如果不是用于大量的循環(huán)之中,則不是那么要緊。不過(guò),你也同時(shí)得到了一個(gè)好處, BigDecimal 類還帶了豐富的舍入方法,也是不錯(cuò)的。
如果小數(shù)位本身不長(zhǎng),則可以用 int 或者 long 來(lái)替代,我想你明白這個(gè)方法是什么意思的。在速度必須很快的位置,你又不介意自己看著小數(shù)點(diǎn)位,這個(gè)還是可用的,但如果數(shù)字本身超過(guò)了 18 位,就只能用 BigDecimal 了。
Wednesday, September 13, 2006
Don’t use float and double when exact answers are required
What? Aren’t calculating decimal are what they are design for? I made such an ignorant question when I first read effective java-item31.
The phenomenon:
Why we can’t use float and double to calculate decimal when exact results are required?
Try the following statements:
?
System.out.println( 1.00 ? - ? 9 * . 10 ); // the?answer?is?0.09999999999999995?!
?
You will find the answers are not agree with what you have learned in primary school.
The reason:
It is all because float and double can not represent exactly 0.1, or any other negative power of ten. They are designed for scientific and engineering calculation which demands accurate approximation. And they are ill-suited for monetary calculations.
The solution:
Use BigDecimal, int or long instead.

?
Transfer all decimal numbers involved in the calcution into BigDecimal objects as above, and then use them to calcute for a exact result, following with two disadvantages, the first, obviously, less convenient than using primitive types, all notations like +,-,*,/ can not be applied neither; the second, it will be slower, which can be ignored if it was not used in a heavily repeated loop. But you also get one merit which comes from the fact that BigDecimal carrys quite a lot of rounding methods.
If the quantity is not big, you can use int or long instead, you surely understand how to implement the idea. In performance critical section, and you don’t mind keeping track the of the decimal point yourself, this is feasible. But you have not choice if the quantity is over 18 digits, only BigDecimal is available.