Java BigDecimal转换、除法“陷阱”

    今天在用BigDecimal“出现费解”现象,以前虽然知道要避免用,但没研究过。借此机会,查证一下分享给大家参详参详。

 

    在Java中经常可以用到double转BigDecimal,也经常进行除法运算,但是以下用法需要特别小心了。

 

Java代码   收藏代码
  1. package com.ccxe.number;  
  2.   
  3. import java.math.BigDecimal;  
  4. import java.math.RoundingMode;  
  5.   
  6. public class Test {  
  7.   
  8.     public static void main(String[] args) {  
  9.   
  10.         // 打印0.899999999999999911182158029987476766109466552734375  
  11.         System.out.println(new BigDecimal(2.00).subtract(new BigDecimal(Double  
  12.                 .toString(1.10))));  
  13.         // double转BigDecimal建议做法  
  14.         System.out.println(new BigDecimal(Double.toString(2.00))  
  15.                 .subtract(new BigDecimal(1.10)));  
  16.   
  17.         // 打印0.90  
  18.         System.out.println(new BigDecimal("2.00").subtract(new BigDecimal(  
  19.                 "1.10")));  
  20.   
  21.         // 异常java.lang.ArithmeticException: Non-terminating decimal expansion;  
  22.         // System.out.println(new BigDecimal("2.00")  
  23.         //        .divide(new BigDecimal("1.10")));  
  24.         // 打印1.81818  
  25.         System.out.println(new BigDecimal("2.00").divide(  
  26.                 new BigDecimal("1.10"), 5, RoundingMode.HALF_EVEN));  
  27.   
  28.     }  
  29.   
  30. }  

一下将解释这一现象。

 

正文:

 

    引言中的代码样例,指明了两个问题:

 

    1,第11行:执行的结果,居然和18行不同;

    2,第22行:除不尽,居然抛出异常。

 

而且更重要的是,这两个问题在编码时隐蔽性很强~。=

 

    先看第1个问题:

 

一看到减法结果很长,立马想到1.10在二进制表达时,是不能准确表达的。随后在JDK API中找到了答案。说法如下:

 

C代码   收藏代码
  1. public BigDecimal(double val)  
  2.   
  3. 将 double 转换为 BigDecimal,后者是 double 的二进制浮点值准确的十进制表示形式。返回   
  4. 的BigDecimal 的标度是使 (10scale × val) 为整数的最小值。   
  5.   
  6. 注:   
  7. (1)此构造方法的结果有一定的不可预知性。有人可能认为在 Java 中写入new BigDecimal(0.1)  
  8. 所创建的 BigDecimal 正好等于 0.1(非标度值 1,其标度为 1),但是它实际上等于   
  9. 0.1000000000000000055511151231257827021181583404541015625。这是因为 0.1 无法准确地表  
  10. 示为double(或者说对于该情况,不能表示为任何有限长度的二进制小数)。这样,传入 到构  
  11. 造方法的值不会正好等于 0.1(虽然表面上等于该值)。   
  12. (2)另一方面,String 构造方法是完全可预知的:写入 new BigDecimal("0.1") 将创建一个   
  13. BigDecimal,它正好 等于预期的 0.1。因此,比较而言,通常建议优先使用 String 构造方法。   
  14. (3)当 double 必须用作 BigDecimal 的源时,请注意,此构造方法提供了一个准确转换;  
  15. 它不提供与以下操作相同的结果:先使用 Double.toString(double) 方法,然后使用   
  16. BigDecimal(String) 构造方法,将 double 转换为 String。要获取该结果,请使用   
  17. static valueOf(double) 方法。   
  18.   
  19. 参数:  
  20. val - 要转换为 BigDecimal 的 double 值。   
  21. 抛出:   
  22. NumberFormatException - 如果 val 为无穷大或 NaN。  

 

由此,可以看出,果然又是经典的“10进制无法精确表达为2进制”问题。

 

    再看第二个问题:

 

从异常信息“Non-terminating decimal expansion ;”(非终止十进制扩张)可以猜出,可能商不能精确表达。于是再查JDK API,找到如下说法:

 

C代码   收藏代码
  1. public BigDecimal divide(BigDecimal divisor)  
  2. 返回一个 BigDecimal,其值为 (this / divisor),其首选标度为 (this.scale()   
  3. - divisor.scale());如果无法表示准确的商值(因为它有无穷的十进制扩展),  
  4. 则抛出 ArithmeticException。   
  5.   
  6. 参数:  
  7. divisor - 此 BigDecimal 要相除的值。   
  8. 返回:  
  9. this / divisor   
  10. 抛出:   
  11. ArithmeticException - 如果准确的商值没有无穷的十进制扩展  

 

以上为JDK API 1.5中的说法,1.6中,多了一个意思,建议优先考虑如下方法:

 

C代码   收藏代码
  1. public BigDecimal divide(BigDecimal divisor,  
  2.                          int scale,                                    // 精度  
  3.                          RoundingMode roundingMode)  // 舍入模式  

可以避免上面所报异常。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值