What is the Reason behind the Inaccuracies in Floating Point Arithmetic?

In most programming languages, Floating Point Arithmetic is based on the IEEE 754 standard.

The crux of the problem is that Floating-point representations have a base b (which is always assumed to be even) and a precision p, where b and p are always a whole number.

Example: Let us try to store 0.1 in two bases – base 10 and base 2

• If b = 10 and p = 3, then the number 0.1 is stored as follows:

0.1 = 1/10, so

• numerator 1 will be represented in 3 digits (precision p) as 1.00
• denominator 10 will be represented in the exponential form of base 10 (b) as 10^-1

Therefore, 0.1 is represented as 1.00 × 10^-1.

• If b = 2 and p = 24, then the number 0.1 is stored as follows:

0.1 = 1/10, so

• numerator 1 will be represented in 24 digits (precision p) as 1.10011001100110011001101
• denominator 10 cannot be represented exactly in the exponential form of base 2 (b). So instead an approximation value is used by Rounding off to the base 2 as 2^-4

Therefore, 0.1 is represented approximately as 1.10011001100110011001101 × 2^-4.

As a result of these approximations, Floating Point Arithmetic results in following errors:

• Rounding Errors
• Precision Errors
• Relative Error and Ulps
• Guard Digits, etc.

Have you ever tried to work with Floating Point Arithmetic in Computing? If yes, then have you ever tried to do 0.1 + 0.2 == 0.3 or some other operation on the precision of Floating point numbers? Yes, you guessed it right, the above expression evaluates to False even though it is mathematically correct. It seems like Floating-Point Arithmetic is broken, but is it so?

In this post, we will deep dive into the Precision and Rounding Errors of Floating Point Arithmetic, explain and justify floating point inaccuracies, and help you understand why “Floating Point Arithmetic is NOT BROKEN”.