# Calculation Errors and Mistakes in Java – How to calculate correctly

This is a real world example on which money was lost by client. This was not explicable, but I managed to analyze and reconstruct the problem.

The Code you are about to see is NOT the production code, but my own reconstruction of it, with a means to show the problem.

`````` @Test
public void testWrong() {

// GIVEN
final Integer price = -595;
final Integer someUnit = 90;

// WHEN
int multiplicationResult = price * someUnit;
// = -53550

Integer resultAmount = multiplicationResult / 100;
// = -535
// …Division failed,
// decimal places ignored...

// THEN
assertTrue(resultAmount == -535);
// Wrong. Correct: -536.
}``````

The specification on which the primitives and float are defined do not allow a correct calculation (mistake 1).

Although primitives cause the most trouble in calculation programming for many people, this example would have worked, if the return type of „multiplicationResult“ would be a double (mistake 2).

But experience shows that even these basics are quite often the main reason for calculation mistakes in Java, so I always recommend a certain way of calculating to avoid them, which I will show below.

``````@Test
public void testCorrect() {

// GIVEN
final Integer price = -595;
final Integer someUnit = 90;
// WHEN
BigDecimal priceBD = new BigDecimal(price);
BigDecimal someUnitBD = new BigDecimal(someUnit);
BigDecimal hundred = new BigDecimal(100);

BigDecimal multiplicationResult = priceBD.multiply(someUnitBD); // = -53550

// = -535.5 - looks great.
BigDecimal resultAmountBD = multiplicationResult.divide(hundred);

final int noDecimalPlaces = 0;
// rounding mode is vital to get a correct result
final RoundingMode roundingMode = RoundingMode.HALF_UP;

// do not forget to define the decimal places...0
BigDecimal result = resultAmountBD.setScale(noDecimalPlaces, roundingMode);

// THEN
assertThat(result.toBigInteger().intValue(), equalTo(-536)); // Correct!

}``````

The Big Decimal is calculated by using a String representation. Calculation is done piece by piece. Thus, the specification of float and primitives in general cannot interfere and cause calculation mistakes through number spaces, computing practices of the CPU etc..

Standard IEEE 754 defines Exception Handling and number spaces. It defines, how float and double is processed. Floating Points are meant to approach a certain precision, but without being 100% accurate. It is equivalent to Math/Analysis lambda, which is marking a barrier to come close to, which is never really reached (infinite lambda for instance).

In Summary:

• Division, multiplication must be done by using a wrapper like BigDecimal.
• Decimal Places have to be defined
• Rounding modes have to be defined
• In case that multiple systems are calculating together (e.g. bank or any other financial institution or software), a contract has to be agreed on. The contract must state how many decimal places are to be used (retail does often use 3 decimal places but only shows 2 on the displays in the shelves). Also the rounding mode plays a vital role in calculation.
• Never use primitives, even if you are sure that in ‚your specific case‘ it is sufficient
• Also experienced programmers make these mistakes, which is why I am posting this in my Blog.