Show HN: Ball falls on the teapot in WebGL

Maybe it's the way the timer is handled when computing the physics, since they would have to compute the deltas based on previous step and the timers in JS are not exact maybe they are producing slightly different deltas between frames accumulating to the difference.

The reason is that without having some randomness to begin with, even rounding errors are deterministic: you get the SAME rounding error each time from the same inputs. Rounding itself isn't random. You can MAKE it random by including a random value as one (or more) of the inputs, but then it's not the rounding that is creating the randomness but the inputs. You could argue that this or that system design (roll a ball between 3 and 4 meters/sec so that 3.5m/s is just barely fast enough to reach the top of a hill, where it rolls over half of the time, rounding measured speed up to 4m/s and comes back half of the time, rounding down to 3m/s) creates a random rounding system around 3.5, but that's just sensitive dependence on initial conditions, which are inputs (barely detectible variations in push speed, direction, breeze, friction on different parts of the ball....)

No, the randomness you get out of rounding errors is the randomness you put into the rounding system, so you're still left with having to explain where it came from BEFORE the rounding errors happened. So rounding errors are very unlikely to explain quantum mechanical uncertainty.

And that was a good question.

in computers, yes and no.

read: https://randomascii.wordpress.com/2013/07/16/floating-point-...