Sorry your browser is not supported!

Hi! So to make a long story short, I have a global variable that I declared as a float, called "Game_state" and in my main loop, I have a series of if/else statements for what to do depending on what the game_state is set to., and in various other places, the Game_state variable is set to specific values depending on what the user does.



I was having some trouble with certain code not getting executed inside one of these if statements, and I couldnt figure out why. I add a PRINT command to have the program print the current value of Game_state in the top corner so I could see what it was at all times, and to my surprise, when game_state SHOULD be set to 0.41, it was instead displaying as "0.409999996424"

This is very odd, as Game_state is only ever set directly with a "game_state = " and never changed via, like, any math or variables, so the only way it should be able to equal 0.409999996424, is if I explicitly typed in "if CONDITION then Game_state = 0.409999996424" and obviously I know for a fact Ive never done that. I know for a fact that, at the time Im encountering this issue, Ive just done "Game_state = 0.41" so it should just... BE that value. It should be "0.41" and not anything else.

Ive never had this issue before despite having other sections using Game state as 0, 0.1, 0.2, 0.3, 0.21, 0.22, 0.23, 2, 4, 6, 6.4, etc. I cant figure out why 0.41 is an issue and somehow changes itself to be ever so slightly less than that, but 0.21 and 0.22 and such stay their correct values just fine.

Any ideas? Is this just some inherent weirdness of Floats or am I missing something obvious?

I get the same results you did, only all of the floats I used did the same thing as the 0.409999...... number. It seems like I remember someone explaining it years ago that it was due to the way floats are calculated. I would suggest using integers for that you are doing, or perhaps even the SELECT / CASE commands. Floats are typically used when you need precision, such as in 3D angles, 3D position, etc.

1. You can try and declare the value as a DOUBLE FLOAT instead. Precision is 15 digits according to the first principles documentation.

2. This is normal for floats. Your CPU will chat the math and processing of floats (especially for digits after 5 or 6 decimal places). So you can never trust floats completely.
Your typical desktop calculator app is specially written to avoid these kinds of rounding errors.

3. I don't want to be a jerk here, but if you take a step back you are probably using floats wrong. Your game state variable probably should be an Integer, or a DWORD (positive integers only). Getting really specific, possibly a BYTE (0 to 255) or a WORD (0 to 65535).

I suspect you could represent your logic (at least at the level where you are comparing very specific numbers) with integers instead.

Single-precision floating-point format
https://en.wikipedia.org/wiki/Single-precision_floating-point_format

So Just Use Integers. Rather than 1.02 use 102

You can use STRINGS for your states. Than write a routine parse (tokenize) out combinations of states that your game might need.

Thank you everyone for the info! I had originally planned on using integers but for various reasons ended up needing "sub states" that were basically just more specific instances of certain "parent" states and didnt feel like going and changing EVERY instance of the game_state variable in my code, so I figured just add decimals. Had I known floats would cause this issue, I wouldve just put in the leg work back then and changed all the game state values. Ill have to just bite the bullet and do that now.

You could put your game states into strings instead of actual numbers.

Another easy option could be to put it into an array such as DIM GameState#(n,n,n)
Then you could define each state like GameState#(0,4,1)=0.41 but use a loop to easily fill them all in.