# Why did we stop using double/float in automation for financial systems?

--

Usually, double/float is used to represent floating-point numbers. But we encountered a problem when we used to double/float. Let’s have a look at the below code. This is a simple subtraction of two numbers.

Output :
Double: 0,3–0,2 = 0.09999999999999998
Float: 0,3–0,2 = 0.10000001

Aren’t these results we didn’t expect? But very close. If we made them assertion with 0.1, we would get an error.

There is a reason for that, computer face to a problem when it has to use floating-point numbers. That is called a “Floating-Point Rounding Error”.

Although there is a negligible difference between the result we expect and the actual result, this difference is enough to significantly impact the financial and business systems.

## Why do we get such unexpected outputs with double?

1. Double/float data type follows IEEE754 specifications.
2. Floating-point numbers cannot precisely represent all real numbers

For a more detailed overview of the particular cases where errors and inaccuracies can be introduced, see the accuracy section of the Wikipedia article.

If you want to compare two floating-point numbers that should in theory be equivalent, you need to allow a certain degree of tolerance. So, are we going to perform our tests by giving tolerance? Of course NO.

## What should we use instead of double/float?

So you should never use floating point types where you need 100% precision. A Big Decimal is an exact way of representing numbers to avoid floating point errors during calculations.

Output :
BigDec: 0,3–0,2 = 0.1

Yes! This is the result we expected. With this result, we can make a definite assertion in our cases. But I must say something. Big Decimal has the drawback of being slower, and more challenging to write algorithms with.

Big Decimal is immensely suited to calculations where a high level of accuracy is needed. If you are dealing with financial calculations, currency, prices or precision is a must, use BigDecimal. Otherwise, Doubles tend to be good enough.

--

--

Senior Software Quality Assurance Engineer @openpayd