This describes the **infinitesimal numbers problem**.

This is sub-layout for documentation pages

Decimal number is number containing decimal number separator. Such a number is not whole (or non integer), such as
\(0.054\)
From now on, such a number will be adressed as **decimal**. In code can be adressed as **float**, **real
number** or **non integer**.

**Whole number** (or **Integer**) is number that does not contain the decimal number separator. Example:
\(15\).

Computer has limited memory and disk space. Therefore, it is not (yet?) possible to store infinite amount of
digits.

If you imagine number as PI, it is not known how many digits are behind the decimal separator. Therefore, all of
them just can not be placed into computer memory.

Machine numbers and floating point arithmetic is more complex, so this will be very simplified explanation.

There exists set of numbers (call them \(\{A, B, C \}\) ) that can be represented by computer.

Numbers such as \(\mathbb{R} - \{A, B, C \}\) can not be represented by computer. If such number
needs to be represented, closest number that can be represented is chosen.

Example:
Let \(A=0.00000000004\) be non machine number.

Let \(\alpha=0.00000000009\) , \(\beta=0.00000000000\) be machine numbers.

We want to represent \(A=0.00000000004\), in which case \(\beta\) will be chosen. So \(A=0.00000000004\) will be
represented as \(\beta=0.00000000000\).

The difference is so small so it might not matter, but if \(A\) was solution for some equation then \(\beta\) is not
solving it.

This means, that even if correct movement vector is computed, the numbers can be *rounded* and the movement
vector might cause collision with the object, EVEN THOUGH the vector was computed correctly!!!

This results in many other beautiful problems, such as: You calculate intersection point. Then you check if that
point really is on the line. And...it is not...because of rounding error discussed above.

Moreover, this might result in problem where the numbers will just not equal, unless you aproximate them.

Imagine two numbers, \(\alpha=0.000000001\) and \(\beta=0.000000000006\).

Now these numbers are quite close to zero, however, if you try to compare them (in C++, C, or Javascript), the
result will be that they do not equal.

\(0.000000001 \neq 0.000000000006 \)

That is a problem, as if you want to check whether discriminant equals zero (and therefore you have exactly one
solution for some polynomial),
The result will be that you will get 2 solutions, but both will be close to each other. That is, in some situations,
unwanted.

The way how decimals shall be compared, is that \(\epsilon\) is chosen. Then:

\(\alpha=\beta \iff |\alpha-\beta| < \epsilon\)

For sake of vectors and collision resolving, if final movement vector would be having eighter \(x\) or \(y\)
decimal, it would cause problems (the movement would cause collision anyway in some cases!).

Therefore, if the decimal part is removed completelly, then:

- Vector will be moving the object to touch wall at one exact spot anyway
- Vector will be moving the object close to wall, but not to touch the wall at all

Technically, the second case does not matter, as the difference would be few pixels (if so), and the collision will not occur, which is the main objective.