Regarding working with floating points...
When starting with an initial integer value, if you are strictly adding integers (e.g., -5, -4, -3, -2, -1, 0, 1, 2, 3, 4, 5), then you can use == all the time if the target can actually be reached.
If you start with an integer and are working with fractions which themselves have denominators that are a power of 2 (e.g., 1/4, 5/8, 17/16) then you can use == all the time if the target can actually be reached.
If you are working with fractions which cannot be written with a denominator that is a power of 2, you must use >= or <= (depending on which direction you are operating).
The number 1.5 can be written as 3/2 -- it has a denominator that is a power of 2 (in fact, it is 2). Now, if we were to write that value as a signed 8bit float (GM uses a lot more than that, but the point can be made with just 8), then 3/2 would be written in the computer as 0x0180. The left two digits are the whole value. In our number, the whole value is 1 and you can see that in the 8bit notation. So where does it get the .5? In 8bit notation, 0x80 is half of a full byte. If you divide 0x80 by 0x0100, the value is 1/2. So now let's look at the number again. The computer sees it as 0x0180; if we divide 0x0180 by 0x0100, we get 1.5 as the decimal notation.
All fine and dandy. Now let's look at a bad fraction. Suppose we had 0.2 for our value. It has a 2 in it, but not in the denominator. A value of 0.2 is equal to 1/5. No amount of straight multiplication will yield a power of 2 in the denominator. But why is that an issue? Let's take a look. This time around, we'll work backwards. 0x0100 multiplied by 0.2 is equal to 0x0033. Now let's multiply 0x0033 by 5.
0x0000 + 0x0033 = 0x0033
0x0033 + 0x0033 = 0x0066
0x0066 + 0x0033 = 0x0099
0x0099 + 0x0033 = 0x00CC
0x00CC + 0x0033 = 0x00FF
Oooh! So close! The result is 255/256 -- 1 bit away from a whole number! So what to do? Add it to itself one more time.
0x00FF + 0x0033 = 0x0122
Now the result is over 1, not equal to 1. What further complicates matters here is, assuming the value carried over, the next iteration will complete in 5 steps from there, not 5 steps after 5 steps.
0x0122 + 0x0033 = 0x0155
0x0155 + 0x0033 = 0x0188
0x0188 + 0x0033 = 0x01BB
0x01BB + 0x0033 = 0x01EE
0x01EE + 0x0033 = 0x0211
And then on the next run....
0x0211 + 0x0033 = 0x0244
0x0244 + 0x0033 = 0x0277
0x0277 + 0x0033 = 0x02AA
0x02AA + 0x0033 = 0x02DD
0x02DD + 0x0033 = 0x0300
OH MY GOSH! We have an integer result! This is one of the few times that adding 0.2 to something will ever equal anything (the other time is 1, and that's just because of how GM handles values close to 1). The rest of the time, as you see in the numbers above, you will rarely get an integer result.
But what about comparing a result to another improper fraction? Suppose you add 0.2 to a variable and want to check if it equals 0.4? Or 0.6? Surely that would work, right? Again, let's multiply 0x0100 by the values we're looking for.
0x0100 * 0.4 = 0x0066
0x0100 * 0.6 = 0x0099
So yes, that would work just fine, because each of those numbers is in our results above.
BUT WAIT! There's more! What about comparing to 0.8? To better understand why this isn't reliable, we'll go back to decimal. 0x0100 is equal to 256/256, so when we do 0x0100*0.2, what we're really doing is 256*0.2 in order to get 0x0033. This does not yield a clear result in decimal, though.
256 * 0.2 = 51.2
A value of 51.2 gets rounded down to 51, which is 0x0033. However, what if the value doesn't get rounded down, but rather it gets rounded up?
256 * 0.6 = 153.6
256 * 0.8 = 204.8
So what if those values got rounded up? Well, then their corresponding values in computer terms would be 0x009A and 0x00CD, neither of which are in the set of calculations above. So even though your rate of increase is 0.2 and your target is a direct multiple of your rate of increase, the values have the potential to not be the same once converted into floating point values.
So what is 50*0.2? Here's a hint: it's not 10.
And sometimes rounding algorithms use Gaussian rounding, so even if you increment by an integer value, if the initial value is a fraction it might round up one step and down the next.