我总是被告知永远不要用双类型或浮点类型来表示货币，这一次我向你提出一个问题:为什么?
我相信有一个很好的理由，我只是不知道是什么。
当前回答
我对其中一些回答感到困扰。我认为双数和浮点数在财务计算中占有一席之地。当然，在使用整数类或BigDecimal类时，在加减非分数货币金额时，不会损失精度。但是，当执行更复杂的操作时，无论您如何存储这些数字，您经常会得到小数点后几位或许多位的结果。问题在于你如何呈现结果。
如果你的结果是在四舍五入和四舍五入之间的边缘，最后一分真的很重要，你可能应该告诉观众答案几乎在中间——通过显示更多的小数点后数位。
双精度浮点数的问题是，当它们被用来组合大数和小数时。在java中,
System.out.println(1000000.0f + 1.2f - 1000000.0f);
结果
1.1875
其他回答
美国货币可以很容易地用美元和美分来表示。整数是100%精确的，而浮点二进制数并不完全匹配浮点小数。
虽然浮点类型确实只能表示近似的十进制数据，但如果在表示数字之前将数字舍入到必要的精度，则可以获得正确的结果。通常。
通常是因为双排精度小于16位。如果你要求更高的精度，这不是一个合适的类型。近似也可以累积。
必须指出的是，即使您使用定点算术，您仍然必须对数字进行四舍五入，如果不是因为BigInteger和BigDecimal在获得周期性小数时会给出错误。所以这里也有一个近似。
例如，历史上用于财务计算的COBOL的最大精度为18位数字。所以通常会有一个隐含的舍入。
总之，在我看来，双精度主要不适合它的16位精度，这可能是不够的，而不是因为它是近似值。
考虑以下后续程序的输出。它表明，在舍入double后，得到与BigDecimal相同的结果，精度为16。
Precision 14
------------------------------------------------------
BigDecimalNoRound : 56789.012345 / 1111111111 = Non-terminating decimal expansion; no exact representable decimal result.
DoubleNoRound : 56789.012345 / 1111111111 = 5.111011111561101E-5
BigDecimal : 56789.012345 / 1111111111 = 0.000051110111115611
Double : 56789.012345 / 1111111111 = 0.000051110111115611
Precision 15
------------------------------------------------------
BigDecimalNoRound : 56789.012345 / 1111111111 = Non-terminating decimal expansion; no exact representable decimal result.
DoubleNoRound : 56789.012345 / 1111111111 = 5.111011111561101E-5
BigDecimal : 56789.012345 / 1111111111 = 0.0000511101111156110
Double : 56789.012345 / 1111111111 = 0.0000511101111156110
Precision 16
------------------------------------------------------
BigDecimalNoRound : 56789.012345 / 1111111111 = Non-terminating decimal expansion; no exact representable decimal result.
DoubleNoRound : 56789.012345 / 1111111111 = 5.111011111561101E-5
BigDecimal : 56789.012345 / 1111111111 = 0.00005111011111561101
Double : 56789.012345 / 1111111111 = 0.00005111011111561101
Precision 17
------------------------------------------------------
BigDecimalNoRound : 56789.012345 / 1111111111 = Non-terminating decimal expansion; no exact representable decimal result.
DoubleNoRound : 56789.012345 / 1111111111 = 5.111011111561101E-5
BigDecimal : 56789.012345 / 1111111111 = 0.000051110111115611011
Double : 56789.012345 / 1111111111 = 0.000051110111115611013
Precision 18
------------------------------------------------------
BigDecimalNoRound : 56789.012345 / 1111111111 = Non-terminating decimal expansion; no exact representable decimal result.
DoubleNoRound : 56789.012345 / 1111111111 = 5.111011111561101E-5
BigDecimal : 56789.012345 / 1111111111 = 0.0000511101111156110111
Double : 56789.012345 / 1111111111 = 0.0000511101111156110125
Precision 19
------------------------------------------------------
BigDecimalNoRound : 56789.012345 / 1111111111 = Non-terminating decimal expansion; no exact representable decimal result.
DoubleNoRound : 56789.012345 / 1111111111 = 5.111011111561101E-5
BigDecimal : 56789.012345 / 1111111111 = 0.00005111011111561101111
Double : 56789.012345 / 1111111111 = 0.00005111011111561101252
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.math.BigDecimal;
import java.math.MathContext;
public class Exercise {
public static void main(String[] args) throws IllegalArgumentException,
SecurityException, IllegalAccessException,
InvocationTargetException, NoSuchMethodException {
String amount = "56789.012345";
String quantity = "1111111111";
int [] precisions = new int [] {14, 15, 16, 17, 18, 19};
for (int i = 0; i < precisions.length; i++) {
int precision = precisions[i];
System.out.println(String.format("Precision %d", precision));
System.out.println("------------------------------------------------------");
execute("BigDecimalNoRound", amount, quantity, precision);
execute("DoubleNoRound", amount, quantity, precision);
execute("BigDecimal", amount, quantity, precision);
execute("Double", amount, quantity, precision);
System.out.println();
}
}
private static void execute(String test, String amount, String quantity,
int precision) throws IllegalArgumentException, SecurityException,
IllegalAccessException, InvocationTargetException,
NoSuchMethodException {
Method impl = Exercise.class.getMethod("divideUsing" + test, String.class,
String.class, int.class);
String price;
try {
price = (String) impl.invoke(null, amount, quantity, precision);
} catch (InvocationTargetException e) {
price = e.getTargetException().getMessage();
}
System.out.println(String.format("%-30s: %s / %s = %s", test, amount,
quantity, price));
}
public static String divideUsingDoubleNoRound(String amount,
String quantity, int precision) {
// acceptance
double amount0 = Double.parseDouble(amount);
double quantity0 = Double.parseDouble(quantity);
//calculation
double price0 = amount0 / quantity0;
// presentation
String price = Double.toString(price0);
return price;
}
public static String divideUsingDouble(String amount, String quantity,
int precision) {
// acceptance
double amount0 = Double.parseDouble(amount);
double quantity0 = Double.parseDouble(quantity);
//calculation
double price0 = amount0 / quantity0;
// presentation
MathContext precision0 = new MathContext(precision);
String price = new BigDecimal(price0, precision0)
.toString();
return price;
}
public static String divideUsingBigDecimal(String amount, String quantity,
int precision) {
// acceptance
BigDecimal amount0 = new BigDecimal(amount);
BigDecimal quantity0 = new BigDecimal(quantity);
MathContext precision0 = new MathContext(precision);
//calculation
BigDecimal price0 = amount0.divide(quantity0, precision0);
// presentation
String price = price0.toString();
return price;
}
public static String divideUsingBigDecimalNoRound(String amount, String quantity,
int precision) {
// acceptance
BigDecimal amount0 = new BigDecimal(amount);
BigDecimal quantity0 = new BigDecimal(quantity);
//calculation
BigDecimal price0 = amount0.divide(quantity0);
// presentation
String price = price0.toString();
return price;
}
}
我对其中一些回答感到困扰。我认为双数和浮点数在财务计算中占有一席之地。当然，在使用整数类或BigDecimal类时，在加减非分数货币金额时，不会损失精度。但是，当执行更复杂的操作时，无论您如何存储这些数字，您经常会得到小数点后几位或许多位的结果。问题在于你如何呈现结果。
如果你的结果是在四舍五入和四舍五入之间的边缘，最后一分真的很重要，你可能应该告诉观众答案几乎在中间——通过显示更多的小数点后数位。
双精度浮点数的问题是，当它们被用来组合大数和小数时。在java中,
System.out.println(1000000.0f + 1.2f - 1000000.0f);
结果
1.1875
如果你的计算涉及到不同的步骤，任意的精度算法都不能100%覆盖你。
使用完美的结果表示(使用自定义Fraction数据类型，将除法操作批处理到最后一步)并且仅在最后一步转换为十进制的唯一可靠方法。
任意精度不会有帮助，因为总有可能有很多小数点后的数字，或者一些结果，如0.6666666……最后一个例子没有任意的表示法。所以每一步都会有小误差。
这些错误会累积起来，最终可能变得不再容易被忽视。这被称为错误传播。
我将冒着被否决的风险，但我认为浮点数在货币计算中的不适用性被高估了。只要确保正确地进行了舍入，并且有足够的有效数字来处理zneak解释的二进制十进制表示不匹配，就不会有问题。
在Excel中使用货币计算的人总是使用双精度浮点数(Excel中没有货币类型)，我还没有看到有人抱怨舍入错误。
当然，你必须在合理范围内;例如，一个简单的网络商店可能永远不会遇到双精度浮点数的任何问题，但如果你做会计或其他需要添加大量(无限制)数字的事情，你不会想要用十英尺的杆子触摸浮点数。
