A simple but big issue. I found that when subtracting or adding to a global variable by 0.2, that the sum jumps wildly and then corrects itself a lot. whether dropping by a random 0.00000000005 or when hitting 0 jumping to huge amounts of decimals, and not 0.

I spotted this when transfering the variable to a spritefont, and checked it with the debug to confirm the problem. It also occurs when telling the game to add 0.2 every second, eliminating player involvement.

The Capx is really simple. You can just use the keyboard commands at the bottom of the events to see the issue in the debug. I hope this is good enough.

Steps to Reproduce Bug

Create a global variable - number type

Create any method of trigger- keyboard trigger/set to timer

Run in debug and watch the variable when triggered over time.

Observed Result

A list of results from the most recent attempt to add by 0.2:

What Im saying is that if you need to have your value in the tens position multiply a whole number times 0.1

Or another method:

Which number of mine?

Did you download the capx? If one is added to the population the food rate must drop by 0.2 once. If a farmer is added the food rate increases by 0.4. On a click by click basis.

It's not a bug, it's a limitation of how floating point numbers are stored on a computer and some rounding.

What happens is 0.2 can't be percisely represented in floating point so numbers are slightly off when doing math. It's much like how 1/3 takes an infinite amount of decimal places in base 10. It happens that 2/10 takes an infinite number of binary bits and floating point only has maybe 50? I forget exactly.

Look at the accuracy problems section here for more of a read.

You probably can find some more explanations by using the forum search on the bugs forum with the keywords floating point.

All other software that uses floating point numbers experience the same result. The difference sometimes is when putting the number into text they often round the result to say six decimal places instead of the 15 or so seen there.

It's not a bug, it's a limitation of how floating point numbers are stored on a computer and some rounding.

What happens is 0.2 can't be percisely represented in floating point so numbers are slightly off when doing math. It's much like how 1/3 takes an infinite amount of decimal places in base 10. It happens that 2/10 takes an infinite number of binary bits and floating point only has maybe 50? I forget exactly.

Look at the accuracy problems section here for more of a read.

You probably can find some more explanations by using the forum search on the bugs forum with the keywords floating point.

All other software that uses floating point numbers experience the same result. The difference sometimes is when putting the number into text they often round the result to say six decimal places instead of the 15 or so seen there.

Thank you for the explanation <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile"> certainly difficult for me to get my head around lol. All i can do then is really round to the right decimal value (0.1) after each calculation is made.

You would only need to round it when you display the number. Another way is to just use whole numbers and convert it to a decimal only when you display it, that way no rounding is needed. I think newt was alluding to that above.

The inaccuracy happens in your CPU circuitry and affects all software on your computer. It's the same problem as saying one third times three when you only have 6 digits of accuracy: you end up with 0.333333 * 3 = 0.999999, not 1, except recurring fractions are different in binary (and 0.2 is recurring in this case).