Comments on: Floating-point errors got you down?

By: John Mark Isaac Madison

John Mark Isaac Madison — Wed, 20 Mar 2013 10:01:13 +0000

Seriously? Do I just not know trigonometry?
var m:Number = Math.asin( Math.sin(1.888) );
//m = 1.253

By: Alex

Alex — Tue, 22 Jan 2013 05:35:22 +0000

i suppose the best solution is:

function fixPointFloat(x:Number, negativeERoundTo:int):Number
{//if negativeERoundTo is 2 you are rounding to hundreths place.
const figure:int = Math.pow(10, negativeERoundTo);
return int(x*figure+.5)/figure;
}

By: Alex

Alex — Tue, 22 Jan 2013 05:00:45 +0000

oops. i meant

return int(x*10+.5)/10 + addend;

By: Alex

Alex — Tue, 22 Jan 2013 04:59:47 +0000

this is my solution.

private function realPlusEquals(x:Number, addend:Number):Number
{
        return int(x/10+.5)/10 + addend;
}

By: Alex

Alex — Tue, 22 Jan 2013 04:23:45 +0000

This error has become an absolute nightmare for my game. A unit’s walkable range in my rts game is about 8000 pixels, and to keep them in an isometric layout, a frame when the unit is walking looks like
x += .9*speed;
where speed equals 2.

sadly, if the unit’s starting x is 0, the first error is on the 19th frame when I try and add 1.8 to 32.4. Tracing the calculation by itself gives 34.199999
and on my game it turns to 34.15. As the walking progresses, the unit is walking in unwalkable territory before not too long. I could readjust the entire ratio so an integer will be added to the x, but then all of the other units’ speeds must respectively adjust meaning there will just be new instances of this. FUCK YOU FLOATING POINTS.

By: Josh Tynjala

Josh Tynjala — Fri, 06 Jul 2012 17:41:13 +0000

I suppose it could cause further errors. I’ve never seen it happen, though.

By: Martin

Martin — Fri, 06 Jul 2012 16:05:22 +0000

Wouldnt the part where you divide with the correction:
” / 10000 ”

be nondeterministic in itself? IE the division causing further possible floatpoint errors?

By: Josh Tynjala

Josh Tynjala — Thu, 26 Jan 2012 02:20:22 +0000

Edit: I see you fixed your issue. Leaving this explanation here in case it may help someone else.

I’m not sure if you have collision detection involved in your calculations, Felps, but that kind of reminds me of a common issue. Sometimes an object can be moving so fast that it never actually can be detected in a direct collision. You need to also check to see if the object hasn’t overshot a barrier without actually touching the barrier. Even if it’s not collision detection, if your vector based approach (I’m not sure what that means, exactly) is something like a lookup table, I could see it losing accuracy as you add in increased power values.

You may be right, though. I’m not as familiar with your code as you are. However, for visual positioning, it’s rare that floating point errors will throw an object extremely far away from where it should be. Usually, it’s much less than a pixel for each error, so you would need a great deal of errors accumulating to see a problem.

By: Felps

Felps — Thu, 26 Jan 2012 02:12:34 +0000

Whoops, false alarm… It’s my hard-limit on the speed objects can travel.

By: Felps

Felps — Thu, 26 Jan 2012 02:04:37 +0000

I’m working on a game in flash, in it I’m having the player fire objects towards objects with gravity as if they were all in outer-space, long story short, I believe my nice, efficient vector-based (as opposed to trig-based) calculations for finding the angle of the trajectory proposed by the player (via mouse click, power designated by length of time the mouse was held) are running into this issue.

At low speeds the trajectory is spot on, hits the mouse cursor every time, but as the speed increases, it flies off course! I might just have to use somewhat less efficient trig functions for it.