BigDecimal：使用setScale向上舍入半个

Question

我们有以下代码：

BigDecimal net = price
.divide(taxCumulative, RoundingMode.HALF_UP)
.setScale(2, BigDecimal.ROUND_UP); 

我们正在对此进行单元测试，并根据是否在测试类上使用事务性测试得到不同的结果。

我只想知道我们是否应该期望HALF_UP的应用程序与setScale一起考虑，还是在它之前考虑。

例如：

说：

价格=4.00

累计税收=1.20

您是否希望计算结果如下：

a） <代码>4.00/1.20=3.33333333--

或

b）<代码>4.00 / 1.20 = 3.33333333...--

正如我所说，我们对这段代码进行了单元测试，当我们有没有事务性代码时，它们的行为会有所不同。因此，我们无法得出结论。在现实世界中，结果是b。但a也是有意义的。

有什么想法吗？

更新：

根据@Mark的建议，我在Spring上下文之外创建了一个测试。（但我想没有办法像coDepen一样在线分享它）。

package com.company;

import java.math.BigDecimal;
import java.math.RoundingMode;

public class Main {

    public static void main(String[] args) {
        BigDecimal price = new BigDecimal("4.00");
        BigDecimal taxCumulative = new BigDecimal("1.20");
        BigDecimal net = price.divide(taxCumulative, RoundingMode.HALF_UP).setScale(2, BigDecimal.ROUND_UP);
        System.out.println("With String constructor, the net =  " + net.toString());
        // prints 3.33
        price = new BigDecimal(4.00);
        taxCumulative = new BigDecimal(1.20);
        net = price.divide(taxCumulative, RoundingMode.HALF_UP).setScale(2, BigDecimal.ROUND_UP);
        System.out.println("With doubles, the net =  " + net.toString());
        // prints 3.00
    }
}

因此，正如@gtgaxiola所指出的，字符串构造函数起到了作用。

至于除法运算使用setScale的问题。我还做了一些测试：

price = new BigDecimal("4.000000");
taxCumulative = new BigDecimal("1.2000000");
net = price.divide(taxCumulative, RoundingMode.HALF_UP).setScale(2, BigDecimal.ROUND_UP);
// 3.34

price = new BigDecimal("4.000000");
taxCumulative = new BigDecimal("1.2000000");
net = price.divide(taxCumulative, RoundingMode.HALF_UP);
// 3.333333

price = new BigDecimal("4");
taxCumulative = new BigDecimal("1.2");
net = price.divide(taxCumulative, RoundingMode.HALF_UP);
// 3

因此，结果在很大程度上取决于字符串输入的精度，在除法产生结果后应用setScale。

Answer 1

它似乎会受到影响，这取决于您如何构建BigDecimal

检查公共BigDecimal（double val）上的构造函数注释

1.-这个构造函数的结果可能有些不可预测。人们可能会假设在Java中编写新的BigDecimal（0.1）会创建一个正好等于0.1的BigDecimal（一个未缩放的值为1，刻度为1），但它实际上等于0.1000000000000000055511151231257827021181583404541015625。这是因为0.1不能完全表示为双精度（或者，就此而言，作为任何有限长度的二进制分数）。因此，传递给构造函数的值并不完全等于0.1，尽管看起来是这样。

2.-另一方面，字符串构造函数是完全可预测的：编写新的BigDecimal（“0.1”）会创建一个恰好等于0.1的BigDecimal，正如人们所期望的那样。因此，通常建议优先使用String构造函数而不是这个。

3.-当双精度必须用作BigDecimal的源时，请注意，此构造函数提供了精确的转换；它不会给出与使用Double.toString（双精度）方法将双精度转换为String然后使用BigDecimal（String）构造函数相同的结果。要获得该结果，请使用静态value Of（双精度）方法。