java舍入错误，对x.715和x.915使用half\u偶数

Question

使用圆化模式时。java的半偶数（默认值）。文本DecimalFormat，我在返回值中看到异常。

我意识到存在精度错误，请参见：Java BigDecimal setScale和舍入为半偶数

然而，由于这是java.text.DecimalFormat，我希望它会被处理

定义：

HALF_EVEN
Rounding mode to round towards the "nearest neighbor" unless both neighbors are equidistant, in which case, round towards the even neighbor.

这是检查双倍舍入的示例：

import java.text.DecimalFormat;
import java.math.RoundingMode;

public class MyClass {
    public static void main(String args[]) {
        String[] dStrings= new String[] { "1548.015", "1548.115", "1548.215", "1548.515", "1548.715", "1548.815", "1548.915",    "1548.705", "1548.715", "1548.725", "1548.755", "1548.775", "1548.785", "1548.795",   "1548.710", "1548.711", "1548.712", "1548.715", "1548.717", "1548.718", "1548.719" } ;
        DecimalFormat df = new DecimalFormat("0.00");
        df.setMaximumFractionDigits(2);

        Double dValue;
        System.out.println("round mode:half_even...");
        System.out.println("String   => str-frmt| dec-frmt");
        //df.setRoundingMode(RoundingMode.CEILING);
        for (String dStr : dStrings) {
            //dValue = new Double(dStr);
            //dValue = Double.parseDouble(dStr);
            dValue = Double.valueOf(dStr);
            System.out.println(String.format("%s => %.2f | BD: %s |DF %s", dStr, dValue, BigDecimal.valueOf(dValue).setScale(2, RoundingMode.HALF_EVEN), df.format(dValue) ));
        }
    }
}

使用java对第4个值进行四舍五入。文本十进制格式，第一个值为原始值

1548.015 => 1548.02 | BD: 1548.02 |DF 1548.02
1548.115 => 1548.12 | BD: 1548.12 |DF 1548.12
1548.215 => 1548.22 | BD: 1548.22 |DF 1548.21 - not ok
1548.515 => 1548.52 | BD: 1548.52 |DF 1548.52
1548.715 => 1548.72 | BD: 1548.72 |DF 1548.71 - not ok
1548.815 => 1548.82 | BD: 1548.82 |DF 1548.82
1548.915 => 1548.92 | BD: 1548.92 |DF 1548.91 - not ok

上面列出的每种情况下，最近邻是1,5是等距的，对吗？所以所有这些情况都应该变成2，对吗？

我在多个当前和过去的JDK版本上进行了测试，都得到了相同的结果。我是误解了还是这是一个错误？请解释为什么java.text.DecimalFormat没有注意浮点精度，因为这似乎是问题所在。

还有为什么字符串中使用基本舍入模型。格式<代码>'%。2f’，未在java中表示。数学圆形模式？i、 e.当5岁及以上时，将最近的邻居四舍五入。

Answer 1

答案很复杂，不足之处在于无法依赖基于浮点的舍入，所看到的行为是正确的，正如巴兹尔所指出的那样。舍入输入时，不应使用浮点。

最佳解决方案，是最简单和明显的使用示例：String.format（"%s=

Oracle SR响应：

html" target="_blank">JDK7是错误行为（请参阅JDK-7131459），以及。JDK8是正确的行为。

问题是“0.5555”，我们都理解为十进制值0.5555，不能用任何二进制表示（包括IEEE-754）来表示。可以获得的这个数字的最精确的二进制表示是0.55549999999999999378275106209912337362766265869140625。使用BigDecimal可以得到这个最好的近似，它提供了无限的精度：

System.out.println（"BigDecimal输出为0.5555："new BigDecimal（0.5555）. toString（））；

上面将返回：“0.5555的BigDecimal输出：0.555499999939378275106209912337362766265869140625”

因此，我们可以看到，0.5555的最接近二进制表示略小于0.5555（0.555499…）。

因此，即使程序员打算使用十进制0.5555，计算机也可以使用IEEE-754的最佳近似值，即0.5554999999999。。。这同样小于0.5555十进制值。

在HALF-EVEN舍入规则下，当在小数点后的第3位小数位舍入时，即上述程序中的情况，不应对该小数位进行舍入，此处的正确结果是“55.5%”

这里JDK7是错误的，JDK8是正确的。

使用-XX:AggressiveOpts选项（从7u14-b13开始）可以获得正确的JDK7行为。

***非常重要的是要理解几乎所有浮点值都不能被任何二进制表示精确记录（如这里的IEEE-754）。使用浮点，你看到的不是你得到的！

根据我的发现以及我从其他工程师那里得到的信息，这不是java 8及更高版本的问题，而是关于浮动小数的预期行为。该实现基于IEEE-754标准。