ChatGPT解决这个技术问题 Extra ChatGPT

Why not use Double or Float to represent currency?

I've always been told never to represent money with double or float types, and this time I pose the question to you: why?

I'm sure there is a very good reason, I simply do not know what it is.

See this SO question: Rounding Errors?
Just to be clear, they shouldn't be used for anything that requires accuracy -- not just currency.
They shouldn't be used for anything that requires exactness. But double's 53 significant bits (~16 decimal digits) are usually good enough for things that merely require accuracy.
@jeff Your comment completely misrepresents what binary floating-point is good for and what it isn't good for. Read the answer by zneak below, and please delete your misleading comment.
And to be clear, by "exactness" (or "precision") you mean in decimal.

R
Rambatino

Because floats and doubles cannot accurately represent the base 10 multiples that we use for money. This issue isn't just for Java, it's for any programming language that uses base 2 floating-point types.

In base 10, you can write 10.25 as 1025 * 10-2 (an integer times a power of 10). IEEE-754 floating-point numbers are different, but a very simple way to think about them is to multiply by a power of two instead. For instance, you could be looking at 164 * 2-4 (an integer times a power of two), which is also equal to 10.25. That's not how the numbers are represented in memory, but the math implications are the same.

Even in base 10, this notation cannot accurately represent most simple fractions. For instance, you can't represent 1/3: the decimal representation is repeating (0.3333...), so there is no finite integer that you can multiply by a power of 10 to get 1/3. You could settle on a long sequence of 3's and a small exponent, like 333333333 * 10-10, but it is not accurate: if you multiply that by 3, you won't get 1.

However, for the purpose of counting money, at least for countries whose money is valued within an order of magnitude of the US dollar, usually all you need is to be able to store multiples of 10-2, so it doesn't really matter that 1/3 can't be represented.

The problem with floats and doubles is that the vast majority of money-like numbers don't have an exact representation as an integer times a power of 2. In fact, the only multiples of 0.01 between 0 and 1 (which are significant when dealing with money because they're integer cents) that can be represented exactly as an IEEE-754 binary floating-point number are 0, 0.25, 0.5, 0.75 and 1. All the others are off by a small amount. As an analogy to the 0.333333 example, if you take the floating-point value for 0.01 and you multiply it by 10, you won't get 0.1. Instead you will get something like 0.099999999786...

Representing money as a double or float will probably look good at first as the software rounds off the tiny errors, but as you perform more additions, subtractions, multiplications and divisions on inexact numbers, errors will compound and you'll end up with values that are visibly not accurate. This makes floats and doubles inadequate for dealing with money, where perfect accuracy for multiples of base 10 powers is required.

A solution that works in just about any language is to use integers instead, and count cents. For instance, 1025 would be $10.25. Several languages also have built-in types to deal with money. Among others, Java has the BigDecimal class, and C# has the decimal type.


@Fran You will get rounding errors and in some cases where large quantities of currency are being used, interest rate computations can be grossly off
...most base 10 fractions, that is. For example, 0.1 has no exact binary floating-point representation. So, 1.0 / 10 * 10 may not be the same as 1.0.
@linuxuser27 I think Fran was trying to be funny. Anyway, zneak's answer is the best I've seen, better even than the classic version by Bloch.
Of course if you know the precision, you can always round the result and thus avoid the whole issue. This is much faster and simpler than using BigDecimal. Another alternative is to use fixed precision int or long.
@JoL You are right, the statement that float(0.1) * 10 ≠ 1 is wrong. In a double-precision float, 0.1 is represented as 0b0.00011001100110011001100110011001100110011001100110011010 and 10 as 0b1010. If you multiply these two binary numbers, you get 1.0000000000000000000000000000000000000000000000000000010, and after that has been rounded to the available 53 binary digits, you have exactly 1. The problem with floats is not that they always go wrong, but that they sometimes do - as with the example of 0.1 + 0.2 ≠ 0.3.
S
Steve Casey

From Bloch, J., Effective Java, (2nd ed, Item 48. 3rd ed, Item 60):

The float and double types are particularly ill-suited for monetary calculations because it is impossible to represent 0.1 (or any other negative power of ten) as a float or double exactly. For example, suppose you have $1.03 and you spend 42c. How much money do you have left? System.out.println(1.03 - .42); prints out 0.6100000000000001. The right way to solve this problem is to use BigDecimal, int or long for monetary calculations.

Though BigDecimal has some caveats (please see currently accepted answer).


I'm a little confused by the recommendation to use int or long for monetary calculations. How do you represent 1.03 as an int or long? I've tried "long a = 1.04;" and "long a = 104/100;" to no avail.
@Peter, you use long a = 104 and count in cents instead of dollars.
@zneak What about when a percentage needs to be applied like compounding interest or similar?
@trusktr, I'd go with your platform's decimal type. In Java, that's BigDecimal.
@maaartinus ...and you don't think using double for such things is error-prone? I've seen the float rounding issue hit real systems hard. Even in banking. Please don't recommend it, or if you do, provide that as a separate answer (so we can downvote it :P )
R
Randy D Oxentenko

This is not a matter of accuracy, nor is it a matter of precision. It is a matter of meeting the expectations of humans who use base 10 for calculations instead of base 2. For example, using doubles for financial calculations does not produce answers that are "wrong" in a mathematical sense, but it can produce answers that are not what is expected in a financial sense.

Even if you round off your results at the last minute before output, you can still occasionally get a result using doubles that does not match expectations.

Using a calculator, or calculating results by hand, 1.40 * 165 = 231 exactly. However, internally using doubles, on my compiler / operating system environment, it is stored as a binary number close to 230.99999... so if you truncate the number, you get 230 instead of 231. You may reason that rounding instead of truncating would have given the desired result of 231. That is true, but rounding always involves truncation. Whatever rounding technique you use, there are still boundary conditions like this one that will round down when you expect it to round up. They are rare enough that they often will not be found through casual testing or observation. You may have to write some code to search for examples that illustrate outcomes that do not behave as expected.

Assume you want to round something to the nearest penny. So you take your final result, multiply by 100, add 0.5, truncate, then divide the result by 100 to get back to pennies. If the internal number you stored was 3.46499999.... instead of 3.465, you are going to get 3.46 instead 3.47 when you round the number to the nearest penny. But your base 10 calculations may have indicated that the answer should be 3.465 exactly, which clearly should round up to 3.47, not down to 3.46. These kinds of things happen occasionally in real life when you use doubles for financial calculations. It is rare, so it often goes unnoticed as an issue, but it happens.

If you use base 10 for your internal calculations instead of doubles, the answers are always exactly what is expected by humans, assuming no other bugs in your code.


Related, interesting: In my chrome js console: Math.round(.4999999999999999): 0 Math.round(.49999999999999999): 1
This answer is misleading. 1.40 * 165 = 231. Any number other than exactly 231 is wrong in a mathematical sense (and all other senses).
@Karu I think that's why Randy says floats are bad... My Chrome JS console shows 230.99999999999997 as the result. That is wrong, which is the point made in the answer.
@Karu: Imho the answer is not mathematically wrong. It's just that there are 2 questions one being answered which is not the question being asked. The question your compiler answers is 1.39999999 * 164.99999999 and so on which mathematically correct equals 230.99999.... Obviously tha's not the question that was asked in the first place....
@CurtisYallop because the closes double value to 0.49999999999999999 is 0.5 Why does Math.round(0.49999999999999994) return 1?
R
Rob Scala

I'm troubled by some of these responses. I think doubles and floats have a place in financial calculations. Certainly, when adding and subtracting non-fractional monetary amounts there will be no loss of precision when using integer classes or BigDecimal classes. But when performing more complex operations, you often end up with results that go out several or many decimal places, no matter how you store the numbers. The issue is how you present the result.

If your result is on the borderline between being rounded up and rounded down, and that last penny really matters, you should be probably be telling the viewer that the answer is nearly in the middle - by displaying more decimal places.

The problem with doubles, and more so with floats, is when they are used to combine large numbers and small numbers. In java,

System.out.println(1000000.0f + 1.2f - 1000000.0f);

results in

1.1875

THIS!!!! I was searching all answers to find this RELEVANT FACT!!! In normal calculations nobody cares if you are of by some fraction of a cent, but here with high numbers easily some dollars get lost per transaction!
And now imagine someone getting daily revenue of 0.01% on his 1 Million dollars - he would get nothing each day - and after a year he has not gotten 1000 Dollars, THIS WILL MATTER
The problem is not the accuracy but that float doesn't tell you that it becomes inaccurate. An integer can only hold up to 10 digits a float can hold up to 6 without becoming inaccurate (when you cut it accordingly). It does allow this while an integer gets an overflow and a language like java will warn you or won't allow it. When you use a double, you can go up to 16 digits which is enough for many use cases.
@Klaws Thank you for the specifics. I feel like I'm starting to understand. But I'm unfamiliar with European tax law, and thus confused. Is it correct that prices are often shown as "end user prices" (including tax) and that the seller ought to take the end user price of €0.02, which includes €0.017 for the seller and €0.003 of tax, multiply that by 1000 to get €17.00 for the seller and €3.00 of tax? This feels odd (from an American context, where taxes are always calculated at the end and never included in the advert price), where it feels the taxes on €17.00 @19% ought to be €3.23. Thanks!
@Josiah Yoder VAT laws in the EU are...complicated. Since the introduction of the Euro, three decimal places are mandatory, meaning that applications typically use 4 decimal places to ensure correct rounding. Prices shown are usually end user prices, but are typically stored as net prices (excl. VAT). VAT is calculated at the end per delivery in Germany, not for individual items. I think the Netherlands however allow to calculate the tax for each item and add sum this up at the end. For VAT advance payments in Germany, different rules apply (even rounding down to zero places at one point).
e
escitalopram

I'll risk being downvoted, but I think the unsuitability of floating point numbers for currency calculations is overrated. As long as you make sure you do the cent-rounding correctly and have enough significant digits to work with in order to counter the binary-decimal representation mismatch explained by zneak, there will be no problem.

People calculating with currency in Excel have always used double precision floats (there is no currency type in Excel) and I have yet to see anyone complaining about rounding errors.

Of course, you have to stay within reason; e.g. a simple webshop would probably never experience any problem with double precision floats, but if you do e.g. accounting or anything else that requires adding a large (unrestricted) amount of numbers, you wouldn't want to touch floating point numbers with a ten foot pole.


This is actually a pretty decent answer. In most cases it's perfectly fine to use them.
It should be noted that most investment banks use double as do most C++ programs. Some use long but thus has it's own problem of tracking scale.
I find this answer intriguing. I assume you and @PeterLawrey speak from experience. Is it possible to find citations / web links to back your claims? I know for a fact that companies use financial information in Excel all the time from my own experience. But what about investment banks using double?
@JosiahYoder Trading systems were traditionally written in C++ where using double or fixed precision is common. i.e. no BigDecimal. The problem I have with fixed precision is the cost of any potential error. For double is probably less than 1 cents even on a billion-dollar trade, but for fixed precision, you could be out by a factor of 10x or more.
I was first exposed to this problem many years ago when an accountant told they can not accept a difference of a cent in the books.
N
Nathan Hughes

Floats and doubles are approximate. If you create a BigDecimal and pass a float into the constructor you see what the float actually equals:

groovy:000> new BigDecimal(1.0F)
===> 1
groovy:000> new BigDecimal(1.01F)
===> 1.0099999904632568359375

this probably isn't how you want to represent $1.01.

The problem is that the IEEE spec doesn't have a way to exactly represent all fractions, some of them end up as repeating fractions so you end up with approximation errors. Since accountants like things to come out exactly to the penny, and customers will be annoyed if they pay their bill and after the payment is processed they owe .01 and they get charged a fee or can't close their account, it's better to use exact types like decimal (in C#) or java.math.BigDecimal in Java.

It's not that the error isn't controllable if you round: see this article by Peter Lawrey. It's just easier not to have to round in the first place. Most applications that handle money don't call for a lot of math, the operations consist of adding things or allocating amounts to different buckets. Introducing floating point and rounding just complicates things.


float, double and BigDecimal are represent exact values. Code to object conversion are inexact as well as other operations. The types themselves are not inexact.
@chux: rereading this, I think you have a point that my wording could be improved. I'll edit this and reword.
c
cs95

While it's true that floating point type can represent only approximatively decimal data, it's also true that if one rounds numbers to the necessary precision before presenting them, one obtains the correct result. Usually.

Usually because the double type has a precision less than 16 figures. If you require better precision it's not a suitable type. Also approximations can accumulate.

It must be said that even if you use fixed point arithmetic you still have to round numbers, were it not for the fact that BigInteger and BigDecimal give errors if you obtain periodic decimal numbers. So there is an approximation also here.

For example COBOL, historically used for financial calculations, has a maximum precision of 18 figures. So there is often an implicit rounding.

Concluding, in my opinion the double is unsuitable mostly for its 16 digit precision, which can be insufficient, not because it is approximate.

Consider the following output of the subsequent program. It shows that after rounding double give the same result as BigDecimal up to precision 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;
    }
}

COBOL has a native decimal type that is fixed-point. This can accurately reference all decimal types up to 18 digits. That's not the same thing as a floating-point number, regardless of the number of digits, because it is a native decimal type. 0.1 will always be 0.1, not sometimes 0.99999999999999
V
Valter Silva

The result of floating point number is not exact, which makes them unsuitable for any financial calculation which requires exact result and not approximation. float and double are designed for engineering and scientific calculation and many times doesn’t produce exact result also result of floating point calculation may vary from JVM to JVM. Look at below example of BigDecimal and double primitive which is used to represent money value, its quite clear that floating point calculation may not be exact and one should use BigDecimal for financial calculations.

    // floating point calculation
    final double amount1 = 2.0;
    final double amount2 = 1.1;
    System.out.println("difference between 2.0 and 1.1 using double is: " + (amount1 - amount2));

    // Use BigDecimal for financial calculation
    final BigDecimal amount3 = new BigDecimal("2.0");
    final BigDecimal amount4 = new BigDecimal("1.1");
    System.out.println("difference between 2.0 and 1.1 using BigDecimal is: " + (amount3.subtract(amount4)));

Output:

difference between 2.0 and 1.1 using double is: 0.8999999999999999
difference between 2.0 and 1.1 using BigDecimal is: 0.9

Let us try something other than trivial addition/subtraction and integer mutplicaiton, If code calculated the monthly rate of a 7% loan, both types would need fail to provide an exact value and need rounding to the nearest 0.01. Rounding to the lowest monetary unit is a part of money calculations, Using decimal types avoid that need with addition/subtraction - but not much else.
@chux-ReinstateMonica: If interest is supposed to compound monthly, compute the interest each month by adding together the daily balance, multiply that by 7 (the interest rate), and divide, rounding to the nearest penny, by the number of days in the year. No rounding anywhere except once per month at the very last step.
@supercat My comment emphasizes using a binary FP of the smallest monetary unit or a decimal FP both incur similar rounding issues - like in your comment with "and divide, rounding to the nearest penny". Using a base 2 or base 10 FP does not provide an advantage either way in your scenario.
@chux-ReinstateMonica: In the above scenario, if the math works out that the interest should be precisely equal to some number of half-cents, a correct financial program must round in precisely specified fashion. If floating-point calculations yield an interest value of e.g. $1.23499941, but the mathematically-precise value before rounding should have been $1.235 and rounding is specified as "nearest even",, use of such floating-point calculations won't cause the result to be off by $0.000059, but rather by a whole $0.01, which for accounting purposes is Just Plain Wrong.
What is required to do financial/accounting calculations properly is to use only mathematically-exact operations except at places where rounding is precisely specified. When properly dividing numbers, either rounding must be specified, one must compute both quotient and remainder, or the product of the quotient and divisor must precisely equal the dividend. Dividing by 7 without specifying rounding or remainder would generally be wrong.
W
William Desportes

As said earlier "Representing money as a double or float will probably look good at first as the software rounds off the tiny errors, but as you perform more additions, subtractions, multiplications and divisions on inexact numbers, you’ll lose more and more precision as the errors add up. This makes floats and doubles inadequate for dealing with money, where perfect accuracy for multiples of base 10 powers is required."

Finally Java has a standard way to work with Currency And Money!

JSR 354: Money and Currency API

JSR 354 provides an API for representing, transporting, and performing comprehensive calculations with Money and Currency. You can download it from this link:

JSR 354: Money and Currency API Download

The specification consists of the following things:

An API for handling e. g. monetary amounts and currencies APIs to support interchangeable implementations Factories for creating instances of the implementation classes Functionality for calculations, conversion and formatting of monetary amounts Java API for working with Money and Currencies, which is planned to be included in Java 9. All specification classes and interfaces are located in the javax.money.* package.

Sample Examples of JSR 354: Money and Currency API:

An example of creating a MonetaryAmount and printing it to the console looks like this:

MonetaryAmountFactory<?> amountFactory = Monetary.getDefaultAmountFactory();
MonetaryAmount monetaryAmount = amountFactory.setCurrency(Monetary.getCurrency("EUR")).setNumber(12345.67).create();
MonetaryAmountFormat format = MonetaryFormats.getAmountFormat(Locale.getDefault());
System.out.println(format.format(monetaryAmount));

When using the reference implementation API, the necessary code is much simpler:

MonetaryAmount monetaryAmount = Money.of(12345.67, "EUR");
MonetaryAmountFormat format = MonetaryFormats.getAmountFormat(Locale.getDefault());
System.out.println(format.format(monetaryAmount));

The API also supports calculations with MonetaryAmounts:

MonetaryAmount monetaryAmount = Money.of(12345.67, "EUR");
MonetaryAmount otherMonetaryAmount = monetaryAmount.divide(2).add(Money.of(5, "EUR"));

CurrencyUnit and MonetaryAmount

// getting CurrencyUnits by locale
CurrencyUnit yen = MonetaryCurrencies.getCurrency(Locale.JAPAN);
CurrencyUnit canadianDollar = MonetaryCurrencies.getCurrency(Locale.CANADA);

MonetaryAmount has various methods that allow accessing the assigned currency, the numeric amount, its precision and more:

MonetaryAmount monetaryAmount = Money.of(123.45, euro);
CurrencyUnit currency = monetaryAmount.getCurrency();
NumberValue numberValue = monetaryAmount.getNumber();

int intValue = numberValue.intValue(); // 123
double doubleValue = numberValue.doubleValue(); // 123.45
long fractionDenominator = numberValue.getAmountFractionDenominator(); // 100
long fractionNumerator = numberValue.getAmountFractionNumerator(); // 45
int precision = numberValue.getPrecision(); // 5

// NumberValue extends java.lang.Number.
// So we assign numberValue to a variable of type Number
Number number = numberValue;

MonetaryAmounts can be rounded using a rounding operator:

CurrencyUnit usd = MonetaryCurrencies.getCurrency("USD");
MonetaryAmount dollars = Money.of(12.34567, usd);
MonetaryOperator roundingOperator = MonetaryRoundings.getRounding(usd);
MonetaryAmount roundedDollars = dollars.with(roundingOperator); // USD 12.35

When working with collections of MonetaryAmounts, some nice utility methods for filtering, sorting and grouping are available.

List<MonetaryAmount> amounts = new ArrayList<>();
amounts.add(Money.of(2, "EUR"));
amounts.add(Money.of(42, "USD"));
amounts.add(Money.of(7, "USD"));
amounts.add(Money.of(13.37, "JPY"));
amounts.add(Money.of(18, "USD"));

Custom MonetaryAmount operations

// A monetary operator that returns 10% of the input MonetaryAmount
// Implemented using Java 8 Lambdas
MonetaryOperator tenPercentOperator = (MonetaryAmount amount) -> {
    BigDecimal baseAmount = amount.getNumber().numberValue(BigDecimal.class);
    BigDecimal tenPercent = baseAmount.multiply(new BigDecimal("0.1"));
    return Money.of(tenPercent, amount.getCurrency());
};

MonetaryAmount dollars = Money.of(12.34567, "USD");

// apply tenPercentOperator to MonetaryAmount
MonetaryAmount tenPercentDollars = dollars.with(tenPercentOperator); // USD 1.234567

Resources:

Handling money and currencies in Java with JSR 354

Looking into the Java 9 Money and Currency API (JSR 354)

See Also: JSR 354 - Currency and Money


kudos for mentioning the MonetaryAmount in Java 9
D
Dev Amitabh

Most answers have highlighted the reasons why one should not use doubles for money and currency calculations. And I totally agree with them.

It doesn't mean though that doubles can never be used for that purpose.

I have worked on a number of projects with very low gc requirements, and having BigDecimal objects was a big contributor to that overhead.

It's the lack of understanding about double representation and lack of experience in handling the accuracy and precision that brings about this wise suggestion.

You can make it work if you are able to handle the precision and accuracy requirements of your project, which has to be done based on what range of double values is one dealing with.

You can refer to guava's FuzzyCompare method to get more idea. The parameter tolerance is the key. We dealt with this problem for a securities trading application and we did an exhaustive research on what tolerances to use for different numerical values in different ranges.

Also, there might be situations when you're tempted to use Double wrappers as a map key with hash map being the implementation. It is very risky because Double.equals and hash code for example values "0.5" & "0.6 - 0.1" will cause a big mess.


A
Arsen Khachaturyan

If your computation involves various steps, arbitrary precision arithmetic won't cover you 100%.

The only reliable way to use a perfect representation of results(Use a custom Fraction data type that will batch division operations to the last step) and only convert to decimal notation in the last step.

Arbitrary precision won't help because there always can be numbers that has so many decimal places, or some results such as 0.6666666... No arbitrary representation will cover the last example. So you will have small errors in each step.

These errors will add-up, may eventually become not easy to ignore anymore. This is called Error Propagation.


f
fishermanhat

Many of the answers posted to this question discuss IEEE and the standards surrounding floating-point arithmetic.

Coming from a non-computer science background (physics and engineering), I tend to look at problems from a different perspective. For me, the reason why I wouldn't use a double or float in a mathematical calculation is that I would lose too much information.

What are the alternatives? There are many (and many more of which I am not aware!).

BigDecimal in Java is native to the Java language. Apfloat is another arbitrary-precision library for Java.

The decimal data type in C# is Microsoft's .NET alternative for 28 significant figures.

SciPy (Scientific Python) can probably also handle financial calculations (I haven't tried, but I suspect so).

The GNU Multiple Precision Library (GMP) and the GNU MFPR Library are two free and open-source resources for C and C++.

There are also numerical precision libraries for JavaScript(!) and I think PHP which can handle financial calculations.

There are also proprietary (particularly, I think, for Fortran) and open-source solutions as well for many computer languages.

I'm not a computer scientist by training. However, I tend to lean towards either BigDecimal in Java or decimal in C#. I haven't tried the other solutions I've listed, but they are probably very good as well.

For me, I like BigDecimal because of the methods it supports. C#'s decimal is very nice, but I haven't had the chance to work with it as much as I'd like. I do scientific calculations of interest to me in my spare time, and BigDecimal seems to work very well because I can set the precision of my floating point numbers. The disadvantage to BigDecimal? It can be slow at times, especially if you're using the divide method.

You might, for speed, look into the free and proprietary libraries in C, C++, and Fortran.


Regarding SciPy/Numpy, fixed-precision (ie Python's decimal.Decimal) is not supported (docs.scipy.org/doc/numpy-dev/user/basics.types.html). Some function won't properly work with Decimal (isnan for instance). Pandas is based on Numpy and was initiated at AQR, one major quantitative hedge-fund. So you have your answer regarding financial calculations (not grocery accounting).
T
Tadija Malić

To add on previous answers, there is also the option of implementing Joda-Money in Java, besides BigDecimal, when dealing with the problem addressed in the question. Java module name is org.joda.money.

It requires Java SE 8 or later and has no dependencies.

To be more precise, there is a compile-time dependency but it is not required.

<dependency>
  <groupId>org.joda</groupId>
  <artifactId>joda-money</artifactId>
  <version>1.0.1</version>
</dependency>

Examples of using Joda Money:

  // create a monetary value
  Money money = Money.parse("USD 23.87");
  
  // add another amount with safe double conversion
  CurrencyUnit usd = CurrencyUnit.of("USD");
  money = money.plus(Money.of(usd, 12.43d));
  
  // subtracts an amount in dollars
  money = money.minusMajor(2);
  
  // multiplies by 3.5 with rounding
  money = money.multipliedBy(3.5d, RoundingMode.DOWN);
  
  // compare two amounts
  boolean bigAmount = money.isGreaterThan(dailyWage);
  
  // convert to GBP using a supplied rate
  BigDecimal conversionRate = ...;  // obtained from code outside Joda-Money
  Money moneyGBP = money.convertedTo(CurrencyUnit.GBP, conversionRate, RoundingMode.HALF_UP);
  
  // use a BigMoney for more complex calculations where scale matters
  BigMoney moneyCalc = money.toBigMoney();

Documentation: http://joda-money.sourceforge.net/apidocs/org/joda/money/Money.html Implementation examples: https://www.programcreek.com/java-api-examples/?api=org.joda.money.Money


W
WilliamK

Take a look at this simple example: it looks like logically correct, but in real world this can return unexpected results if not threated correctly:

0.1 x 10 = 1 👍 , so:

double total = 0.0;

// adds 10 cents, 10 times
for (int i = 0; i < 10; i++) {
    total += 0.1;  // adds 10 cents
}

Log.d("result: ", "current total: " + total);

// looks like total equals to 1.0, don't?

// now, do reverse
for (int i = 0; i < 10; i++) {
    total -= 0.1;  // removes 10 cents
}

// total should be equals to 0.0, right?
Log.d("result: ", "current total: " + total);
if (total == 0.0) {
    Log.d("result: ", "is total equal to ZERO? YES, of course!!");
} else {
    Log.d("result: ", "is total equal to ZERO? No...");
    // so be careful comparing equality in this cases!!!
}

OUTPUT:

 result: current total: 0.9999999999999999
 result: current total: 2.7755575615628914E-17   🤔
 result: is total equal to ZERO? No... 😌

The problem is not that round-off error happens, but that you doesn't deal with it. Round the result to two decimal places (if you want cents) and you're done.
C
Chris Tsang

Float is binary form of Decimal with different design; they are two different things. There are little errors between two types when converted to each other. Also, float is designed to represent infinite large number of values for scientific. That means it is designed to lost precision to extreme small and extreme large number with that fixed number of bytes. Decimal can't represent infinite number of values, it bounds to just that number of decimal digits. So Float and Decimal are for different purpose.

There are some ways to manage the error for currency value:

Use long integer and count in cents instead. Use double precision, keep your significant digits to 15 only so decimal can be exactly simulated. Round before presenting values; Round often when doing calculations. Use a decimal library like Java BigDecimal so you don't need to use double to simulate decimal.

p.s. it is interesting to know that most brands of handheld scientific calculators works on decimal instead of float. So no one complaint float conversion errors.


R
RollerSimmer

American currency can easily be represented with dollar and cent amounts. Integers are 100% precise, while floating point binary numbers do not exactly match floating point decimals.


Wrong. Integers are not 100% precise. Precision requires decimal or fraction.
They are precise for integral values like currency.