java float、double精度研究（转）

在java中运行一下代码
System.out.println(2.00-1.10);
输出的结果是：0.8999999999999999
很奇怪，并不是我们想要的值0.9

再运行如下代码：
System.out.println(2.00f-1.10f);
输出结果：0.9

又正确了，为什么会导致这种问题？程序中为什么要尽量避免浮点数比较？

在java中浮点型默认是double的，及2.00和1.10都要在计算机里转换进行二进制存储，这就涉及到数据精度，出现这个现象的原因正是浮点型数据的精度问题。先了解下float、double的基本知识:
1. float和double是java的基本类型，用于浮点数表示，在java中float占4个字节32位，double占8个字节64位，一般比较适合用于工程测量计算中，其在内存里的存储结构如下：float：

符号位（1 bit）

指数（8 bit）

尾数（23 bit）

double：

符号位（1 bit）

指数（11 bit）

尾数（52 bit）

注意：从左到右是从低位到高位，而在计算机内部是采用逆序存储的。

2. System.out.println(2.00-1.10);中的1.10不能被计算机精确存储，以double类型数据1.10举例计算机如何将浮点型数据转换成二进制存储，
这里重点讲小数部分转换成二进制：
1.10整数部分就是1，转换成二进制1（这里整数转二进制不再赘述）
小数部分：0.1
0.1*2=0.2取整数部分0，基数=0.2
0.2*2=0.4取整数部分0，基数=0.4
0.4*2=0.8取整数部分0，基数=0.8
0.8*2=1.6取整数部分1，基数=1.6-1=0.6
0.6*2=1.2取整数部分1，基数=1.2-1=0.2
0.2*2=0.4取整数部分0，基数=0.4
.
.
.
.
直至基数为0。1.1用二进制表示为：1.000110...xxxx....(后面表示省略)
0.1 = 0*2^(-1)+0*2^(-2)+0*2^(-3)+1*2^(-4)+.........而double类型表示小数部分只有52位，当向后计算52位后基数还不为0，那后面的部分只能舍弃，从这里可以看出float、double并不能准确表示每一位小数，对于有的小数只能无限趋向它（所以有的数运行正常，有的数不正常）。在计算机中加减成除运算实际上最后都要在计算机中转换成二进制的加运算，由此，当计算机运行System.out.println(2.00-1.10);
时会拿他们在计算机内存中的二进制表示计算，而1.10的二进制表示本身就不准确，所以会出现0.8999999999999999的结果。

但为什么System.out.println(2.00f-1.10f);得出的结果是0.9呢。因为float精度没有double精度那么大，小数部分0.1二进制表示被舍去的比较多。

但是这不意味着float就是准确的 ，比如

float f = 1.0f - 0.9f;
System.out.println(f)

运行结果为0.100000024

因此，有个原则：

• 程序中应尽量避免浮点数的比较
• float、double类型的运算往往都不准确

那该如何表示一个精准的

在《Effective Java》这本书中也提到这个原则，float和double只能用来做科学计算或者是工程计算，在商业计算中我们要用java.math.BigDecimal。

BigDecimal一共有4个够造方法，我们不关心用BigInteger来够造的那两个，那么还有两个，它们是：
BigDecimal(double val) 
          Translates a double into a BigDecimal. 
BigDecimal(String val) 
          Translates the String repre sentation of a BigDecimal into a BigDecimal.
     上面的API简要描述相当的明确，而且通常情况下，上面的那一个使用起来要方便一些。我们可能想都不想就用上了，会有什么问题呢？等到出了问题的时候，才发现上面哪个够造方法的详细说明中有这么一段：
Note: the results of this constructor can be somewhat unpredictable. One might assume that new BigDecimal(.1) is exactly equal to .1, but it is actually equal to .1000000000000000055511151231257827021181583404541015625. This is so because .1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length). Thus, the long value that is being passed in to the constructor is not exactly equal to .1, appearances nonwithstanding. 
The (String) constructor, on the other hand, is perfectly predictable: new BigDecimal(".1") is exactly equal to .1, as one would expect. Therefore, it is generally recommended that the (String) constructor be used in preference to this one.
原来我们如果需要精确计算，非要用String来够造BigDecimal不可！在《Effective Java》一书中的例子是用String来够造BigDecimal的，但是书上却没有强调这一点，这也许是一个小小的失误吧。
如

BigDecimal bg1 = new BigDecimal(0.9);
BigDecimal bg2 = new BigDecimal(1.0);
System.out.println(bg2.subtract(bg1));//输出0.09999999999999997779553950749686919152736663818359375

BigDecimal bg3= new BigDecimal("0.9");
BigDecimal bg4 = new BigDecimal("1.0");
System.out.println(bg4.subtract(bg3));//输出0.1

解决方案
现在我们已经可以解决这个问题了，原则是使用BigDecimal并且一定要用String来够造。