Show HN: box2d-jquery - physics-engine for your DOM

    javascript:(function(){var%20s=document.createElement('script');s.setAttribute('src','https://raw.github.com/franzenzenhofer/box2d-jquery/master/js/lib/jquery.box2d.min.js');document.getElementsByTagName('body')[0].appendChild(s);window.setTimeout(function(){$("#main-nav,header").box2d({'y-velocity':5,'x-velocity':-0.05,'debug':false});},500);})();

Edit: And a working bookmarklet for HN that also injects jquery.

    javascript:(function(){var%20s=document.createElement('script');s.setAttribute('src','//ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js');document.getElementsByTagName('body')[0].appendChild(s);s=document.createElement('script');s.setAttribute('src','https://raw.github.com/franzenzenhofer/box2d-jquery/master/js/lib/jquery.box2d.min.js');document.getElementsByTagName('body')[0].appendChild(s);window.setTimeout(function(){$("td:first()").box2d({'y-velocity':5,'x-velocity':-0.05,'debug':false});},500);})();

this 2d world has no intrinsic random/chaotic forces (i.e. no wind) so everything behaves the same, always, forever. if you want your world to be more random you could write something like this (during the world initiation phase a.k.a. the first box2d-jquery call)

  $("h1, code, .box2d").box2d({'y-velocity':5, 'x-velocity':Math.random()}

It's my impression that it's always easier to add randomness to such an engine. So if you have a deterministic engine you can always sprinkle on some randomness afterwards if you want it more interesting.

But I'm not very experienced in physics engines so I might be on thin ground.

In theory you would expect a physics engine to always behave exactly the same every time (as long as there are no random forces in the simulation, obviously). In practice, I can think of some ways that would influence the result. For example, x86 can use extended (80-bit) precision for intermediate floating point calculations internally, but will always store them as 64 bit in registers or memory. Depending on the timing of thread context switches, you can imagine subtle roundoff errors caused by going from extended precision to double precision. When using SSE math you get similar effects but even more pronounced, because SSE is not always fully IEEE compliant.

Usually the introduced error is infinitely small and most algorithms are robust enough to cancel it out. Stuff like non-linear regression or a physics simulation are notable exceptions, because the calculations they do are iterative and progressive, meaning any introduced error can propagate and get amplified along the way. I've seen deterministic non-linear fit algorithms go in completely different directions for unstable problems on different machines, just because of CPU differences (64-bit vs 32-bit, x86 vs. sparc, etc).

javascript:(function(){document.body.appendChild(document.createElement('script')).src='https://raw.github.com/gist/4257861/bf99710923dc4512338a9f19...;})();

The code can be found here: https://gist.github.com/4257861