You really want to play with physics/math with ECMA 262? O_O (hint JS knows nothing of integers)
Floats are way to slow (and faulty when div/mul are called) compared to int to do anything serious.
All 3D engines tricks are about doing complex math with integers (EDIT: or other tricks http://en.wikipedia.org/wiki/Fast_inverse_square_root#Overvi...)
Why would you post a link to an example using floats then? I mean sure, part of the trick involves treating the float as an integer but the number is still meant to be interpreted as a float.
Your assumptions about speed might be true for something like a Nintendo DS which doesn't have a floating point unit but a 3DS does, a vectorised one no less. Also in Javascript integers that can fit into 32 bits are actually integers nowadays.
All in all, I believe your information is outdated.
Not to mention that most modern games and physics engines all use floating point numbers these days. We're not in the 90's anymore - gpu's all support floats natively and are very fast at processing them, cpu floating point units are as fast as integer units, SIMD (eg SSE) supports fast floats and doubles. There's really no reason to avoid floats unless you're doing something very very special (hint: if you're arguing about these things, you're probably not).
Havok, Bullet, PysX - as far as I know they all use floats.
Well, I would discourage playing with math if accuracy was important.
Just open firebug and multiply
>>> 10*1.1198
11.197999999999999
This limitation is intrinsic to IEEE 754, and no alternative are in the pipe (IEEE854 seems stalled).
I have been working for the web ads industry and canvases were pretty disappointing in terms of performance when the number of sprites were growing up.
The funnier part was the inconsistency in result amongst the browsers.
So simulate as much as you want, just don't expect to beat flash or native client in terms of performance...
But for physics, that result is great! An inaccuracy of just one part in 10^12 would be better than practically every physics experiment ever performed. That's like being off by the size of an atom when measuring the distance from LA to New York. (I'm speaking as a physicist rather than as a programmer here, mind you. But my limited experience programming physics would suggest that this is a perfectly acceptable level of error.)
You're totally correct. And honestly, when you're doing numerical simulation like I am in the article, your error stems from the fact that you're only simulating 40 steps a second with only a first-degree solver.
Simulating physics for realsies takes a lot more than that.
The solver algorithm I used is called Euler's method, or ODE1 for short. It's the least accurate numerical ODE solver there is! When people do real physics simulations they use the Runge-Kutta (ODE45) or Adams-Bashforth-Moutlon (ODE113) solves, and they'll have 100,000 steps per second.
So while it's important to be cognizant of these things, it's also best not to stress to much about what's going on in the first of a series of educational articles :)
Unless you have a sensitivity to the initial conditions, hence you have a chaotic system. Which happens as fast as n body interactions in a gravitational field (but how many bodies/iterations do you need, which initial conditions makes the error a problem?)
But as I stated earlier, I think I have to check first because I am not that convinced any more on the performance point of view that JS has a problem, and float representation is not a JS problem, but a problem global to all CPUs.
Well it can be more than 10^-12 sometimes and the problem is not in physics but in trading when errors stack up. That's why I prefer when e-commerce solutions are based on fixed point arithmetic.
Even though canvases are still not homogeneous in terms of performance from browsers to browsers, some works fairly well.
Right, chaotic behavior is a valid issue. But in any realistic situation, you'll have lots of effects that inevitably get left out of simulations that contribute larger perturbations/errors than this rounding error would. (Heck, I suspect that even the thermal motion of the individual atoms in an object would have a larger effect.)
So no simulation will ever get exactly the "right" answer at that level. For practical purposes, all we care about is getting an answer that's within the ensemble of reasonable outcomes for initial conditions like ours.
These articles are not about developing video games or getting performance. They're about learning physics through a common language that most developers know: Javascript. It's ok that it won't beat flash or native client. It never intended to.
If you can read an article, understand what's going on and immediately open up Firebug and start playing with the equations, then Javascript has cut out 10 unnecessary steps (buying Flash, installing, learning actionscript, etc) or your path to playing with physics and numerical models!
All that happened there is you entered your factors in a strange base (albeit the same one the output humors you with) and then didn't like the appearance of the answer.
