我正在调用一个截断方法来截断 double 值，以便小数点后应该有一个数字(不四舍五入)，
对于前。 截断(123.48574)= 123.4。

我的截断方法是这样的

public double truncate (double x) {
    long y = (long) (x * 10);
    double z = (double) (y / 10);
    return z;
}

除了这个奇怪的输出外，它几乎适用于所有值。

double d = 0.787456;
d = truncate(d + 0.1); //gives 0.8 as expected. Okay.

但是，

double d = 0.7;
d = truncate(d + 0.1); //should also give 0.8. But its giving 0.7 only. 
                       //Strange I don't know why?

事实上，它适用于所有其他 0.1、0.2、0.3、0.4、0.5、0.6、-、0.8、0.9
我的意思是，例如，

double d = 0.8;
d = truncate(d + 0.1); //gives 0.9 as expected

我也用 BigDecimal 试过了。但是一样。没变。 这是相关代码。

double d = 0.7;
BigDecimal a = new BigDecimal(d + 0.1);
BigDecimal floored = a.setScale(1, BigDecimal.ROUND_DOWN);
double d1 = floored.doubleValue();
System.out.println(d1); //Still gives 0.7

再一次，真实的事实是它与 Math.round 一起工作得很好。

public double roundUp1d (double d) {
    return Math.round(d * 10.0) / 10.0;
}

因此，如果我调用 roundUp1d(0.7 + 0.1)，它会按预期给出 0.8。但我不希望这些值四舍五入，所以我不能使用它。

0.7 有什么问题？

最佳答案

(如果您对理论不感兴趣，请滚动到末尾，这是您代码的修复方法)

原因很简单:如你所知，二进制系统只支持0和1

那么，让我们看看您的值，以及它们在二进制表示中的含义:

0.1 - 0.0001100110011001100110011001100110011001100110011001101
0.2 - 0.001100110011001100110011001100110011001100110011001101
0.3 - 0.010011001100110011001100110011001100110011001100110011
0.4 - 0.01100110011001100110011001100110011001100110011001101
0.5 - 0.1
0.6 - 0.10011001100110011001100110011001100110011001100110011
0.7 - 0.1011001100110011001100110011001100110011001100110011
0.8 - 0.1100110011001100110011001100110011001100110011001101
0.9 - 0.11100110011001100110011001100110011001100110011001101

这是什么意思？ 0.1 是 1 的十分之一。在十进制 系统中没什么大不了的，只需将分隔符移动一个位置。但是在二进制中，您不能表示 0.1 - 因为小数点的每次移位都等于 *2 或 /2 - 取决于方向。 (而且10不能分成2的X类)

对于你想除以 2 的倍数的值 - 你会得到一个精确的结果:

1/2 - 0.1
1/4 - 0.01
1/8 - 0.001
1/16- 0.0001
and so on.

因此，尝试计算 /10 是一个无限长的结果，当值用完位时将被截断。

也就是说，这是计算机工作方式的局限性，这样的值永远无法完全精确地存储。

站点注释:Patriot System 忽略了这个“事实”，导致它在运行几个小时后变得无法使用，请参见此处:http://sydney.edu.au/engineering/it/~alum/patriot_bug.html

但为什么它对除了 0.7 + 0.1 之外的所有东西都有效 - 你可能会问

如果您使用 0.8 测试您的代码 - 它可以工作 - 但不能使用 0.7 + 0.1。

同样，在二进制中，这两个值都已经不精确了。如果将两个值相加，则结果 更加不精确，导致错误的结果:

如果将 0.7 和 0.1(小数点后)相加，您会得到:

  0.101100110011001100110011001100110011001100110011001 1000
+ 0.000110011001100110011001100110011001100110011001100 1101
  ---------------------------------------------------------
  0.110011001100110011001100110011001100110011001100110 0101     

但是 0.8 会是

  0.110011001100110011001100110011001100110011001100110 1000

比较最后 4 位并注意，加法的结果“0.8”小于将 0.8 直接转换为二进制的情况。

猜猜看:

System.out.println(0.7 + 0.1 == 0.8); //returns false

在处理数字时，您应该为自己设置一个精度限制 - 并且始终相应地对数字进行舍入以避免此类错误(不是截断!):

 //compare doubles with 3 decimals
 System.out.println((lim(0.7, 3) + lim(0.1, 3)) == lim(0.8, 3)); //true

 public static long lim(double d, int t){
     return Math.round(d*10*t);
 }

要修复您的代码:将其舍入为 4 位数字，然后在第一个数字后截断:

public static double truncate(double x){
   long y = (long)((Math.round(x*10000)/10000.0)*10);
   double z = (double)y/10;
   return z;
}

System.out.println(truncate(0.7+0.1)); //0.8
System.out.println(truncate(0.8)); //0.8

这仍将根据需要进行截断，但确保 0.69999 在截断之前将四舍五入为 0.7。您可以根据应用程序的需要设置精度。 10、20、30、40 位数？

其他值仍将保持正确，因为像 0.58999 这样的值将四舍五入为 0.59 - 因此仍被截断为 0.5 而不是四舍五入为 0.6

关于java - 为什么使用 truncate 和 BigDecimal 会出现这种奇怪的输出？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26312985/