부동점은 어떻게 된 일입니까?

It's not a bold statement to say that computers need to store numbers. We store these numbers in binary on our phones, laptops, fridges etc.

An example should help here. Let's choose a random binary fraction: 101011.101

Floating point is exactly that, a floating ( fractional ) point number that gives us the ability to change the relative size of our number.

So how do we mathematically represent a number in such a way that we,

1. store the significant digits of the number we want to represent (E.G. the 12 in 0.00000012);
2. know where to put the fractional point in relation to the significant digits (E.G. all the 0's in 0.00000012)?

To do this, let's time travel (for some) back to secondary school...

So, we know what floating point is now. But why can't I do something as simple as add two numbers together without the risk of error?

Well the problem lies partially with the computer, but mostly with mathematics itself.

Recurring fractions are an interesting problem in number representation systems.

Let's choose any fraction $\frac{x}{y}$

This is why numbers like $1/21$ can't be represented in a finite number of digits; $21$ has $7$ and $3$ as prime factors, neither of which are a factor of $10$ .

Let's work through an example in decimal.

Say you want to add the numbers $1/3$ and $2/3$ . We all know the answer is 42 $1$ , but if we are working in decimal, this isn't as obvious.

This is because $1/3 = 0.333333333333...$

It isn't a number that can be represented as a finite number of digits in decimal. As we can't store infinite digits, we store an approximation accurate to 10 places.

The calculation becomes...

This exact same problem occurs in binary, except it's even worse! The reason for this is that $2$ has one less prime factor than $10$ , namely $5$ .

Because of this, recurring fractions happen more commonly in base $2$ .

An example of this is $0.1$ :

In decimal, that's easy. In binary however... 0.00011001100110011... , it's another recurring fraction!

So trying to perform 0.1 + 0.2 becomes

  0.0001100110011
+ 0.0011001100110
= 0.0100110011001
= 0.299926758

Now before we got something similar to 0.30000000004 , this is because of things like rounding modes which I won't go into here (but will do so in a future post). The same principle is causing this issue.

This number of errors introduced by this fact are lessened by introducing rounding.

The other main issue comes in the form of precision.

We only have a certain number of bits dedicated to the significant digits of our floating point number.

As an example, consider we have three decimal values to store our significant digits.

If we compare $333$ and $1/3 * 10^3$

This is because we only have three values of precision to store the significant digits of our number, and that involves truncating the end off of our recurring fraction.

In an extreme example, adding $1$ to $1*10^3$

This exact same issue occurs in binary with very^veryveryvery small and very_veryveryvery big numbers. In a future post I will be talking more about the limits of floating point.

For completeness, consider the previous example in binary, where we now have 3 bits to represent our significant digits.

By using base 2 instead, 1 * 2^3 , adding 1 to our number will result in no change. This is because to represent 1001 (now equivalent to 9 in decimal) requires 4 bits, the less significant binary digits are lost in translation.

There is no solution here, the limits of precision are defined by the amount we can store. To get around this, use a larger floating point data type.

• E.G. move from a single-precision floating-point number to a double-precision floating-point number.

Thank you so much for reading! I hope this was helpful to those that needed a little refresher on floating point and also to those that are new to this concept.