2010-05-01 09:03:07 8 Comments

I thought `java.math.BigDecimal`

is supposed to be The Answer™ to the need of performing infinite precision arithmetic with decimal numbers.

Consider the following snippet:

```
import java.math.BigDecimal;
//...
final BigDecimal one = BigDecimal.ONE;
final BigDecimal three = BigDecimal.valueOf(3);
final BigDecimal third = one.divide(three);
assert third.multiply(three).equals(one); // this should pass, right?
```

I expect the `assert`

to pass, but in fact the execution doesn't even get there: `one.divide(three)`

causes `ArithmeticException`

to be thrown!

```
Exception in thread "main" java.lang.ArithmeticException:
Non-terminating decimal expansion; no exact representable decimal result.
at java.math.BigDecimal.divide
```

It turns out that this behavior is explicitly documented in the API:

In the case of

`divide`

, the exact quotient could have an infinitely long decimal expansion; for example, 1 divided by 3. If the quotient has a non-terminating decimal expansion and the operation is specified to return an exact result, an`ArithmeticException`

is thrown. Otherwise, the exact result of the division is returned, as done for other operations.

Browsing around the API further, one finds that in fact there are various overloads of `divide`

that performs *inexact* division, i.e.:

```
final BigDecimal third = one.divide(three, 33, RoundingMode.DOWN);
System.out.println(three.multiply(third));
// prints "0.999999999999999999999999999999999"
```

Of course, the obvious question now is "What's the point???". I thought `BigDecimal`

is the solution when we need *exact* arithmetic, e.g. for financial calculations. If we can't even `divide`

exactly, then how useful can this be? Does it actually serve a general purpose, or is it only useful in a very niche application where you fortunately just don't need to `divide`

at all?

If this is not the right answer, what *CAN* we use for exact division in financial calculation? (I mean, I don't have a finance major, but they still use division, right???).

### Related Questions

#### Sponsored Content

#### 33 Answered Questions

#### 9 Answered Questions

### [SOLVED] ArithmeticException: "Non-terminating decimal expansion; no exact representable decimal result"

**2011-01-04 06:34:37****Jason****287284**View**480**Score**9**Answer- Tags: java bigdecimal arithmeticexception

#### 1 Answered Questions

### [SOLVED] IntelliJ hint while rounding BigDecimal division stream result

**2019-03-19 19:06:20****Martin****86**View**1**Score**1**Answer- Tags: java intellij-idea java-stream bigdecimal

#### 1 Answered Questions

### How to deal with exact precision in Java?

**2018-12-22 15:43:53****Shirgill Farhan****58**View**1**Score**1**Answer- Tags: java double precision bigdecimal

#### 1 Answered Questions

### [SOLVED] Java BigDecimal is rounding necessary with addition?

**2017-09-29 12:47:15****amicoderozer****730**View**1**Score**1**Answer- Tags: java bigdecimal

#### 2 Answered Questions

### [SOLVED] Why Am I Getting a Non-terminating decimal expansion when I am rounding up already?

**2016-07-12 20:06:25****Jack Parker****85**View**1**Score**2**Answer- Tags: java bigdecimal

#### 2 Answered Questions

### [SOLVED] How scale is defined when decimal and bigint are divided?

**2015-10-29 14:30:13****gotqn****327**View**2**Score**2**Answer- Tags: sql-server tsql sql-server-2012 decimal division

#### 3 Answered Questions

#### 3 Answered Questions

### [SOLVED] Maximum precision below unlimited?

**2013-08-07 15:13:44****4thfloorstudios****1826**View**15**Score**3**Answer- Tags: java

## 9 comments

## @Stephen C 2010-05-01 10:50:27

Then I was in primary school

^{1}, they taught me that when you divide by 1 by 3 you get a 0.33333... i.e. arecurringdecimal. Division of numbers represented in decimal form is NOT exact. In fact for any fixedbasethere will be fractions (the result of dividing one integer by another) that cannot be representedexactlyas a finite precision floating point number in that base. (The number will have a recurring part ...)When you do financial calculations involving division, you

haveto consider the what to do with a recurring fraction. You can round it up, or down, or to the nearest whole number, or something else, but basically youcannotjust forget about the issue.The BigDecimal javadoc says this:

In other words, it is

your responsibilityto tell BigDecimal what to do about rounding.EDIT- in response to these followups from the OP.It does not explicitly detect the recurring decimal. It simply detects that the result of some operation cannot be represented exactly using the specified precision; e.g. too many digits are required after the decimal point for an exact representation.

I suppose that

`BigDecimal`

could have been specified to represent a recurring decimal exactly; i.e. as a`BigRational`

class. However, this would make the implementation more complicated and more expensive to use^{2}. And since most people expect numbers to be displayed in decimal, and the problem of recurring decimal recurs at that point.The bottom line is that this extra complexity and runtime cost would be inappropriate for typical use-cases for

`BigDecimal`

. This includes financial calculations, where accounting conventions do not allow you to use recurring decimals.^{1 - It was an excellent primary school ...}^{2 - Either you try to remove common factors of the divisor and dividend (computationally expensive), or allow them to grow without bounds (expensive in space usage ... and computationally for later operations).}## @polygenelubricants 2010-05-01 11:29:31

How does

`BigDecimal`

detect infinite recurring decimal? It must keep track of and detect a cycle in the dividend. It COULD HAVE chosen to handle this another way, by marking where the recurring portion is, etc.## @polygenelubricants 2010-05-02 14:02:59

@Stephen: Really appreciated your investigation into how it detects infinite expansion. I went and did it too after I made the comment, but I thought I should give you a chance to answer it yourself =)

## @Raymond Cidad 2012-06-27 17:25:18

To divide save, you have to set the

`MATHcontext`

,`BigDecimal bd = new BigDecimal(12.12, MathContext.DECIMAL32).divide(new BigDecimal(2)).setScale(2, RoundingMode.HALF_UP);`

## @COME FROM 2010-05-01 11:31:14

If you want to work with decimals, not rational numbers, and you need exact arithmetics before the final rounding (rounding to cents or something), here's a little trick.

You can always manipulate your formulas so that there's only one final division. That way you won't lose precision during calculations and you'll always get the correctly rounded result. For instance

equals

## @Pacerier 2014-08-30 03:19:17

Oh what are all the engineers doing, We should cringe whenever we had to do

manualmanipulationforthe computer in this time and age.## @Kevin Brock 2010-05-01 17:09:47

The class is

`BigDecimal`

not`BigFractional`

. From some of your comments it sounds like you just want to complain that someone didn't build in all possible number handling algorithms into this class. Financial apps do not need infinite decimal precision; just perfectly accurate values to the precision required (typically 0, 2, 4, or 5 decimal digits).Actually I have dealt with many financial applications that use

`double`

. I don't like it but that was the way they are written (not in Java either). When there are exchange rates and unit conversions then there are both the potential of rounding and bruising problems.`BigDecimal`

eliminates the later but there is still the former for division.## @polygenelubricants 2010-05-02 01:19:45

+1. You nailed it right with "

`BigDecimal`

not`BigFractional`

". And your insight on`double`

for financial application is appreciated.## @tkr 2010-05-01 16:24:27

You should prefer BigDecimal for finance calculations. Rounding should be specified by the business. E.g. an amount (100,00$) has to be split equally across three accounts. There has to be a business rule which account takes the extra cent.

Double, floats are not approriate for use in financial applications because they can not represent fractions of 1 precisely that are not exponentials of 2. E.g. consider 0.6 = 6/10 = 1*1/2 + 0*1/4 + 0*1/8 + 1*1/16 + ... = 0.1001...b

For mathematic calculations you can use a symbolic number, e.g. storing denominator and numerator or even a whole expression (e.g. this number is sqrt(5)+3/4). As this is not the main use case of the java api you won' find it there.

## @Michael Konietzka 2010-05-01 13:01:43

Is there a need for

in financial systems? I guess not. In financial systems it is defined, which roundmode and scale has to be used, when doing calculations. In some situations, the roundmode and scale is defined in the law. All components can rely on such a defined behaviour. Returning b==1 would be a failure, because it would not fulfill the specified behaviour. This is very important when calculating prices etc.

It is like the IEEE 754 specifications for representing floats in binary digits. A component must not optimize a "better" representation without loss of information, because this will break the contract.

## @polygenelubricants 2010-05-01 13:08:49

Does

`double`

satisfy the finance sector contract? Can you not control the rounding mode etc for`double`

as well?## @supercat 2014-01-10 23:25:47

When working with quantities that must balance, the right approach for performing division is to keep both the quotient and remainder. Divide $1.00 among seven people will reveal that there's $0.14 for everyone, plus two extra pennies that can be allocated according to some policy.

## @stacker 2010-05-01 10:19:36

In financial reports we use alwasy BigDecimal with scale = 2 and ROUND_HALF_UP, since all printed values in a report must be lead to a reproducable result. If someone checks this using a simple calculator.

In switzerland they round to 0.05 since they no longer have 1 or 2 Rappen coins.

## @Adrian Mouat 2010-05-01 09:37:56

I accept that Java doesn't have great support for representing fractions, but you have to realise that it is

impossibleto keep things entirely precise when working with computers. At least in this case, the exception is telling you that precision is being lost.As far as I know, "infinite precision arithmetic with decimal numbers" just isn't going to happen. If you have to work with decimals, what you're doing is probably fine, just catch the exceptions. Otherwise, a quick google search finds some interesting resources for working with fractions in Java:

http://commons.apache.org/math/userguide/fraction.html

http://www.merriampark.com/fractions.htm

Best way to represent a fraction in Java?

## @Pacerier 2014-08-30 03:23:18

It is possible to keep things entirely precise. There is something called fractions. It's simply the case that the current libraries we have are limited.

## @Adrian Mouat 2014-08-31 09:47:20

@Pacerier - not really; consider irrational numbers.

## @Pacerier 2014-08-31 19:42:05

For irrational numbers the library would store the number in the form of an expression. E.g. sqrt 2 is stored as sqrt 2, not 1.4142135..... etc. That's exactly how we do it in high school maths; if pre-resolving would give us imprecise results, then we only

resolvethe number in the last step when we need to display it. There's no reason why a computer couldn't do this.## @Adrian Mouat 2014-09-01 20:36:16

@Pacerier given enough time, cpu and memory. It's just far too inefficient (although you may be able to blame computer architectures partially for this). Try it if you like; until then I wouldn't blame the libraries.

## @Pacerier 2014-09-01 21:46:47

BigInteger is also "far too inefficient" compared to primitive int. That's the whole point of a code library: writing "far too inefficient" code which people use when the use case can sacrifice speed for functionality. "far too inefficient" is not a reason against building a dedicated BigRealNumber library.

## @Adrian Mouat 2014-09-02 12:31:03

@Pacerier Agreed; I thought you were arguing that the current libraries were wrong rather than that there was space for a new library.

## @Pacerier 2014-09-03 13:03:09

I'm arguing for both. That there is a space for a BigRealNumber but Java currently doesn't provide one even after 20 years. And the same goes for many other languages.

## @Martijn Courteaux 2010-05-01 09:19:12

Notice we are using a computer... A computer has a lot of ram and precision takes ram. So when you want an infinite precision you need

`(infinite * infinite) ^ (infinite * Integer.MAX_VALUE)`

terrabyte ram...I know

`1 / 3`

is`0.333333...`

and it should be possible to store it in ram like "one divided by three" and then you can multiply it back and you should have`1`

. But I don't think Java has something like that...Maybe you have to win the Nobel Price for writing something doing that.

`;-)`

## @polygenelubricants 2010-05-01 09:25:58

"Maple supports both hardware (double) precision and infinite precision computations." maplesoft.com/products/maple/compare/numeric_computation.aspx

## @Bart Kiers 2010-05-01 09:32:16

I wouldn't expect anything less from a system like Maple! :) Looking at a more "general purpose" language (like Java), Python

doeshave built-in support for rational numbers: docs.python.org/library/fractions.html## @polygenelubricants 2010-05-01 10:43:15

@Martin: yes, the RAM is finite, but there are still ways to represent infiniteness symbolically. Just look at

`double`

: it has a`POSITIVE_INFINITY`

and`NEGATIVE_INFINITY`

.`double`

only has 64 bits. The computer could've done something like storing`.(3)`

, where`(number)`

is the repeating part. In fact, lots of implementations already do this (and no, they didn't all get Nobel Prizes for it).## @Stephen C 2013-12-03 10:51:21

No Nobel prizes for Maths, Computer Science, or any Engineering discipline. Sorry :-)