当前位置: 首页 > 知识库问答 >
问题:

BigDecimalHALF_UP舍入问题

韩经武
2023-03-14

我尝试使用scale=3和HALF\u向上舍入模式舍入0.14049,希望看到舍入值=0.141,但得到的是0.140。

根据我的理解,最后一个十进制数字9应该将4到5四舍五入,当使用小数点3时,应该将0到1四舍五入,我应该看到0.141。

这是BigDecimal setScale方法中的错误还是我对舍入的期望是错误的。如何获得类似于0.141而不是0.140的舍入值?

BigDecimal bd=new BigDecimal("0.14049");
BigDecimal normalizedField = field.setScale(3, RoundingMode.HALF_UP);
System.out.println(normalizedField);
// Output = 0.140

共有2个答案

欧阳元魁
2023-03-14

根据您的业务领域,“4999998”案件将始终发生在同一位置。我也遇到过类似的情况,分数是2。因此,我在舍入中添加了额外的步骤。在您的情况下:

BigDecimal bd=new BigDecimal("0.14049");
BigDecimal normalizedField = bd.setScale(4, RoundingMode.HALF_UP).setScale(3, RoundingMode.HALF_UP);
System.out.println(normalizedField);
轩辕奕
2023-03-14

根据我的理解,最后一个十进制数字9应该将4到5四舍五入,当使用小数点3时,应该将0到1四舍五入,我应该看到0.141。

这种理解是错误的。舍入不是一个迭代过程。只考虑刻度位置后的第一个数字,而不是整个数字链。在你的例子中,数字是4,所以它被转换为零。

 类似资料:
  • 问题内容: 有人可以向我解释以下代码的原因: 给出以下输出? 如果您看不到它,则:“ 6.2089”舍入为3位数字将输出为“ 6.208”,而“ 6.2088”将输出为“ 6.209”。少即是多? 使用Java 5、6或7时,效果很好,但是此Java 8给了我奇怪的输出。Java版本: 编辑:这是Java 7的输出: Java 7版本: 问题答案: 我可以将此问题归类到522行。 这种情况是,它认

  • 有人能向我解释为什么以下代码: 给出以下输出? 以防您没有看到:“6.2089”四舍五入为3位给出输出“6.208”,而“6.2088”给出“6.209”作为输出。少即是多? 当使用Java 5、6或7时,结果很好,但这个Java 8给了我这个奇怪的输出。Java版本: 编辑:这是Java7的输出: Java7版本:

  • 问题内容: 这是小代码来说明我所看到的 打印: 我要打印 我需要做什么? 问题答案: 在使用之前添加以下行: 查看其他舍入模式,看看哪种最适合您。 注意:此方法仅在JDK 1.6或更高版本中有效

  • 问题内容: 我正在尝试执行 累积乘法 。我正在尝试两种方法来做到这一点 样本数据: 注意:列中 的数据永远不会是整数,并且值将具有小数部分。为了显示近似问题,我将示例值保留为整数。 方法1:EXP + LOG + SUM()结束(排序依据) 在这种方法中,我使用技术来查找累积乘法。在这种方法中,数值不准确;结果中存在一些舍入和近似问题。 结果: 方法2:传统乘法(递归CTE) 该方法完美地工作,没

  • 我有一个由数字组成的数据集。我想在一份报告中陈述这一点。我已经设法生成了一个具有以下格式的报告。这有点类似于会计中的试算表。但事实并非如此!表中的数据在其值中有4个小数点。但在报告中,它应该四舍五入到小数点后两位。报告还必须准确,因此需要使用。 基于@marciob、@user3679868和@joopeggen的编辑3决定根据舍入值进行计算。差额。047(.56-.553)显然被冲销了(审计标准

  • 问题内容: 在我的课程中,我被告知: 连续值大约在内存中表示,因此使用浮点数进行计算会产生舍入误差。这些是位模式的微小差异。因此,如果和为浮点,则测试是不安全的。 指的是Java。 这是真的?我已经将比较语句与s和s一起使用,并且从未遇到过舍入问题。我从来没有读过类似的教科书。虚拟机肯定占了这一切吗? 问题答案: 是真的。 这是如何在内存中以有限数量的位表示浮点值的固有限制。 例如,该程序显示“