"Intentional" is putting it strongly. We'd all be super happy if computers could get exact answers to arithmetic on real numbers.
We could easily improve the situation by representing real numbers inside the computer in base 10. Then problems such as 0.1+0.2 would come out exactly right. (If that sounds like an absurd idea, bear in mind that for a long time there were two kinds of computers: business computers, which used decimal arithmetic, and scientific computers, which used binary. The IBM System/360, which came out around my senior year of high school, so I guess 1964 or -65, was introduced with great fanfare as a revolutionary new design, because it included both binary and decimal arithmetic hardware, so you could use it for both kinds of problems! Of course this just meant that the IBM management didn't understand the idea of abstraction, which in this case means that the internal representation of data doesn't have to be the same as what the user sees.)
Another way to improve our ability to do arithmetic correctly is to avoid real numbers whenever possible, instead using exact rational arithmetic. So your example becomes 1/10 + 2/10, which gives an exact 3/10 as the result.
Alas, sometimes you want to know the circumference of a circle, and there's no exact rational representation of 𝜋. Nor of √2. Etc. So we have to find a way to do arithmetic on real numbers in computers.
There are different degrees of infiniteness. Strangely, although there are as many integers as rational numbers, there are way more real numbers. (Look it up.) As a result, even if we could represent infinitely many digits in the computer, that wouldn't be good enough to represent all the reals exactly. The problem is fundamental, not a bad design of any particular approach, such as floating point.
Edit: I was wrong about that. I should have said, we still couldn't get all the reals in our infinite computer. But also, it would take infinitely long to compute all those digits of even one irrational number.
This problem isn't really about floating point, but about the resolution of sprite positions. If you do the same CHANGE BY using variables X and Y instead of X POSITION and Y POSITION, you get the answer you're looking for.
This works:
But if you say
then
I'm not actually sure why sprite positions lose precision, but if you want repeatable computations you can't use them as variables. :~)
Hadda look it up. :~) Thank you! I really appreciate the compliment.
What I am is a teacher. I love teaching people stuff. That's why I'm here.
