Infinitesimal numbers problem

This describes the infinitesimal numbers problem.


This is sub-layout for documentation pages

Top

1 Decimal numbers vs whole numbers

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\).

2 Machine numbers

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.

3 Decimals might not equal

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\)

4 Removing the decimal part

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:


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.