News for hackers. Stuff that matters.
Re:Show HN: Ball falls on the teapot in WebGL by edvinbesic on Thursday August 18, 2016 @11:58AM (#12313520)
Probably due to rounding errors (multiplication precision)

[1]: http://floating-point-gui.de/

Re:Show HN: Ball falls on the teapot in WebGL by chc on Thursday August 18, 2016 @12:01PM (#12313555)
Why would the results of floating point math be inconsistent between consecutive runs of the same program?
Re:Show HN: Ball falls on the teapot in WebGL by edvinbesic on Thursday August 18, 2016 @12:10PM (#12313676)
Hmm, good point. Probably rules that out you're right.

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.

Re:Show HN: Ball falls on the teapot in WebGL by sevenless on Thursday August 18, 2016 @01:15PM (#12314411)
This is a ridiculous question, but could quantum mechanical uncertainty be interpreted as a rounding error?

Say the universe only stores a certain number of bits of information for each particle...

Re:Show HN: Ball falls on the teapot in WebGL by SiVal on Thursday August 18, 2016 @05:28PM (#12316449)
That's not a ridiculous question. It's a perfectly reasonable thing to ask. Most likely, the answer to your question is no.

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.

Re:Show HN: Ball falls on the teapot in WebGL by devopsproject on Thursday August 18, 2016 @01:52PM (#12314770)
Aren't the number of particles the deciding factor? If you had 100 particles, you couldn't give me exactly 1/3 of them.