This is a bug I discovered while working on my game. I use a float as a factor in a damage calculation, and it ranges from 1 to 2 in intervals of 0.2. Everything works fine until that value reaches 1.6 from the addition of 0.2 onto 1.4. The events cannot register any "Global Value X = 1.6" events.
I attached a simple example that reproduces this bug.
THis is due to the accumulation of small errors in the calculation, and unfortunately there is not much that can be done about it...
In general you cannot compare floating point values to anything. Computers have a really hard time representing floating points values in binary numbers which all has limited precision. That means that values like 0.2 might in fact be more like 0.19999999999999 instead because it would be the closest it could come to 0.2
The reason why you cannot always compare two floating point values is that one value of 0.2 could be 0.19999999 while another could be 0.19999998 while still being displayed on your screen as 0.2 if it rounds them a little for prettier display.
As you can see those two values are different.
It also means that on computers, 1.7*0.2 - 0.3 is not always the same as - 0.3 + 1.7*0.2
What you then do is to test if the two values is within a small 'error' range.
To make it easier for you should try only to work with integers as they can easily be compared to each other.
You could just use values between 0 and 5. When you want your float value just use:
1+(myval/5.0)
Just for info this post has already been answered in this thread
The problem about floating points can also easily be fixed by multipling by 10, 100 or whatever it takes to get the decimals away and then when the actual value is needed, multiply by 0.1, 0.01 or whatever you multiplied with in the first place.
Hmm.. very useful info here.. thanks!
Actually; IEEE Single Precision ('c standard to FPV') will stay perfect up till 24 bit's... 'little rusty but around 7-8 decimal places'
...and there is an extension 'Double precision' extension allowing significant precision up till 16 decimal digits.
If you ever need more precision then that, then you may as well learn arbitrary precision(i "think" mmf could handle it..."think"..."maybe"...."actually"...."probably not"). hehe
WAIT....YES!
The problem doesn't lie within floating point precision calculations but mostly rounding floats to integer. Using FOR NEXT loops directly that uses floats could cause rounding miscalculations by the processor.
I understand that if 1.999999999 should be the same as 1.9 then it'd be useless as a calculation and you could use integers (IE. 19) in this particular case. Just my two cents.
Why is it so difficult for computers to handle decimals? There's an easy solution. Just store the value as an integer, and also store the number of decimal places to move the dot by, then when displaying it, put it together. e.g 1.9999999 goes to 19999999.0 and 7. Then on reload move the decimal back 7 places to get back 1.9999999
See what I mean?
Working as fast as I can on Fusion 3
Posting Permissions
