0
votes

Immutable, arbitrary-precision signed decimal numbers. A BigDecimal consists of an arbitrary precision integer unscaled value and a 32-bit integer scale. If zero or positive, the scale is the number of digits to the right of the decimal point. If negative, the unscaled value of the number is multiplied by ten to the power of the negation of the scale. The value of the number represented by the BigDecimal is therefore (unscaledValue × 10-scale).

That is what the doc says. Based on the docs it appears that BigDecimal i useful when

  • You are dealing with super large numbers
  • You are concerned about precision

But are there any other scenarios where BigDecimal is a better choice ?

2
What other scenarios can there be that don't fall under the categories you already mentioned?cs95
I think you summed it up pretty well.PM 77-1
A question plus answer... that's good :)Damián Rafael Lattenero
One common scenario (which is already here if you read between the lines), is money. Taxes, surcharges or just calculating daily returns are all better with BigDecimal because a precise answer is desired.Elliott Frisch
@ElliottFrisch yes that's right, I just right now was reading a little about one of that examples, and your point was perfect as example.Damián Rafael Lattenero

2 Answers

0
votes

Double is a floating value, meaning that it is not an exact value. Therefore, you need to use BigDecimal which gives you the exact value. Double will display only 15 significant decimal digits but you can have as many significant digits in BigDecimal as you wish. You can set the value using MathContext class. BigDecimal is used when you are writing code for developing applications like scientific calculators.

0
votes

The question maybe has some good sizes to check, for example the financial one is an example, I'll took it from here because I liked it:

Primer on Financial Issues

Currency calculations require precision to a specific degree, such as two digits after the decimal for most currencies. They also require a specific type of rounding behavior, such as always rounding up in the case of taxes.

For example, suppose we have a product which costs 10.00 in a given currency and the local sales tax is 0.0825, or 8.25%. If we work it out on paper, the tax amount is,

10.00 * 0.0825 = 0.825

Because our precision for the currency is two digits after the decimal, we need to round the 0.825 figure. Also, because this is a tax, it is good practice to always round up to the next highest cent. That way when the accounts are balanced at the end of the day, we never find ourselves underpaying taxes.

0.825 -> 0.83

And so the total we charge to the customer is 10.83 in the local currency and pay 0.83 to the tax collector. Note that if we sold 1000 of these, we would have overpaid the collector by this much,

1000 * (0.83 - 0.825) = 5.00

Another important issue is where to do the rounding in a given computation. Suppose we sold Liquid Nitrogen at 0.528361 per liter. A customer comes in and buys 100.00 liters, so we write out the total price,

100.0 * 0.528361 = 52.8361

Because this isn't a tax, we can round this either up or down at our discretion. Suppose we round according to standard rounding rules: If the next significant digit is less than 5, then round down. Otherwise round up. This gives us a figure of 52.84 for the final price.

Now suppose we want to give a promotional discount of 5% off the entire purchase. Do we apply this discount on the 52.8361 figure or the 52.84 figure? What's the difference?

Calculation 1: 52.8361 * 0.95 = 50.194295 = 50.19 Calculation 2: 52.84 * 0.95 = 50.198 = 50.20

Note that we rounded the final figure by using the standard rounding rule.

See how there's a difference of one cent between the two figures? The old code never bothered to consider rounding, so it always did computations as in Calculation 1. But in the new code we always round before applying promotions, taxes, and so on, just like in Calculation 2. This is one of the main reasons for the one cent error.