Turbodog posted a question on this in the Official Answers Discussion, but I couldn’t respond there, so I am responding here.
For those of you who haven’t read his post, basically, Turbodog was getting decimals ending in .999 when he tried to increment a variable by one. As I use variables quite often, I decided to investigate. Here are my findings and my work-around
Yep! Does the same thing on mine. Although the errors occur consistently for the same values during repeated runs of the same code, the pattern appears non-repeating and unpredictable, occurring at 12.999, 13.999, (call these 13 and 14 for simplicity) and again at 18, 21, 23, 26, 28, 31, 36,
56, 57, etc.
The grouped numbers in the block above got me thinking… There IS a pattern. Okay, the first number error occurs at 13. That error occurs again at 26, but not 39, suggesting a rounding error of less than .333. Other pairings can also be seen with 14 and 28, 18 and 36, 21 and 41/42, 23 and 46/47, etc.
Why is Modkit doing this? No clue But, there IS a mathematical pattern.
I tried relating it to the nth digit of pi… (because we all have the first 100 digits memorized, right?) as well as a few other curiosities, before just building a work-around. If anyone finds the real cause, please post it!
Anyway, since the errors are mathematical / rounding errors, I decided to simply move the decimal. Multiply everything by 1,000,000 and the output error nearly vanishes. Strangely, multiplying by 10,000,000 produced more errors, so I’m guessing that Modkit can only handle 7 place values.
Anyway, for those curious, the new code only produced 8 errors between 0 and 600. Six notable errors appeared at 202 and 404, 227 and 454, 252 and 504. The other 2 errors were at 252 (227 + 25) and 479 (454 + 25). Coincidence? I think not!
Best of luck, Turbodog! Hopefully, you can live with only 8 errors in 10 mintues. Else, you can always simply reset the variable. For example, when it reaches 200, set it back to zero and add 200 to the new counter.