Show HN: Pi Approximation using Monte Carlo
montepie.herokuapp.com
montepie.herokuapp.com
I think the reset button should be smaller (you usually don't want to reset the simulation).
I expected that the number in the upper right corner is the number of additional simulations to do. For example, if n=1000 and box=200, the system makes 200 additional simulations and now n=1200.
Also, I'd like to see an advanced mode: (but perhaps I'm not a typical user)
I'd like to see a graph of pi_aproximation vs n, so I can see how the value "converges" to pi.
And I'd like to see an error estimation, for example, the expected variation is ~sqrt(n)/4 (I think that the correct constant is not 4, but it's a similar small number). So you can draw error bars or the pi+-sqrt(n)/4 "bounds".
This is a small hack that I created over the weekend. I learnt about the Monte Carlo method while doing Princeton's Functional Programming course[0] in OCaml[1] as one of the assignment problems. To get the first four digits consistently, I ran around 200,000 - 400,000 simulations - not quite possible in the browser!
[0] - http://www.cs.princeton.edu/~dpw/courses/cos326-12/
[1] - https://github.com/prakhar1989/ocaml-experiments/blob/master...
It's not the browser (or JS) that's slow, it's all the animations and stuff. If you write Javascript to do only what the OCaml code does, it runs fast enough: http://jsfiddle.net/qmw4d9p9/1/
Link: http://nbviewer.ipython.org/gist/pnegahdar/eb62475b28d5b394d...
Of course, there are more points with binary FP coordinates whose magnitude computed naively as sqrt(xx + yy) produces a rounded result of 1.0 in binary floating-point; (3/5,4/5) is one such example.
I would address this by using careful computation of the residual of xx + yy - 1.0 to determine which side of the circle the point lies on; something like the following sketch:
float residual = x*x + y*y - 1
if (residual == 0) {
/* x*x + y*y rounded to 1; we need to do a more careful check
to determine whether we're inside or outside. WLOG, assume
that |x| >= |y|. */
if (fabsf(x) < fabsf(y)) { float tmp = x; x = y; y = tmp; }
/* We know that 0.5 <= x*x < 1.0, from which it follows that
fmaf(x,x,-1) is computed without any rounding; we can then
do another fma to isolate the residual (this is also exact
because we know that y*y cannot be *too* tiny unless x is
exactly 1.0, in which case the first fma is exactly zero). */
residual = fmaf(y,y,fmaf(x,x,-1));
}
if (residual < 0) { /* inside circle */ }
else if (residual == 0) { /* on circle */ }
else { /* outside circle */ }
Even giving 50% probability at the line the result would be minutely biased because of many other things involving the discreteness of the floating point arithmetic. A less biased version would have to maybe increase the resolution around the boundary as number of steps progresses.
Practically, it might be fun to have a small library that artificially reduces the precision of floating point numbers. I've never heard about such a thing though.
edit: naturally you can also use this information to calculate the number of trials needed get a desired probability that the estimation falls within certain bounds from pi.
For 10x10 (100 iterations), I got 3.44
For 100x100 (10,000 iterations), I got 3.1796
For 1000x1000 (1,000,000 iters), I got 3.14552
For 10,000x10,000 (100,000,000 iters), I got 3.141990
For 100,000x100,000 (10,000,000,000 iters, 2m06s runtime), I got 3.141633.
So the deterministic version takes a long time to converge on the right answer too. Therefore, it seems that the Monte Carlo version appears less accurate than you'd think, not because of the stability of the randomness, but because your intuition (and mine) is way off about how good any kind of sampling is at converging on the right answer.
See @teisman's great reply for figuring out how many iterations you'd need for a given level of accuracy.
Edit: Looking back at the numbers, you need 100x as many samples to roughly get an extra digit of precision. That's 10x the iterations on each axis, which makes sense that that would give you an extra digit of precision in your answer. Therefore, after 10000 (100x100) iterations, you wouldn't expect better accuracy than 2 digits, or 3.1. Which is what we see.
Edit2: I'm an idiot. After converting my test from (sqrt((x * x + y * y)/(samples * samples)) < 1) to ((x * x + y * y) < (samples * samples)) and making the maths integer only, I got the 100,000x100,000 runtime down to 10.8s. (Same answer though.)
Why didn't you just pick the center of the square, use that to partition it into 4 pieces, and recurse for each subsquare?
Or just as easily do this? http://pastebin.com/ezi7S35N (Edit: just noticed a typo -- I should be initializing the numerator/denominator inside the loop, not outside, sorry.)
What's the point of adding randomness?
Regarding the randomness of the problem to solve: A practical application for Monte Carlo methods is integration over a high-dimensional space (with dozens or more degrees of freedom). Traditional deterministic methods have a runtime which is exponential in the number of dimensions, while for Monte Carlo integration, the error of the result decreases as 1/sqrt(N) (where N is the number of samples, which is proportional to the runtime), independent of the dimensionality of the integration space.
what I'm saying is that the entire point of illustrating an algorithm by example is to illustrate the power of the algorithm compared to a naive approach, regardless of whether or not there is a better way to solve the example problem.
i.e., the example should motivate the algorithm. But computing pi is one of the worst possible illustrations of why anyone would use Monte Carlo, because it's inferior to the naive approach. i.e., it doesn't motivate why anyone would want to use Monte Carlo.
Any suggestions for a simulation that does illustrate the use of Monte Carlo methods while still being explainable with 16+ age range non-specialist mathematics? I'm hacking around with two step simulations like a tree diagram...
http://sohcahtoa.org.uk/pages/maths_montecarlo.html
My crack at saying how slowly a monte-carlo simulation 'converges' to a value of pi (not really converging, just confidence intervals tightening around the value).
http://jakevdp.github.io/blog/2014/06/06/frequentism-and-bay...
I feel like you didn't read a single sentence of my comment, because that's exactly what I said I was not saying.
So, perhaps you can turn this around, and ask for a special visualization that would be better in your opinion. In that case you might be lucky and have a person like krat0sprakhar nicely visualizing your specific problem.
And just my two cents: most problems I encounter are integration (full Bayesian) and the detection of extremes (MAP). There is nothing random about these problems either, maybe even less than pi (which might be "normal", nobody knows yet)!
I'd be happy to see a visualization of another nice, simple problem, that is more up your alley!
As a way of demonstrating the utility of Monte Carlo algorithms in general, though, it's a neat and easily visualisable example, which is why it's used so often in elementary introductions of the concept.
Actual examples of how Monte Carlo algorithms can be useful involve the sampling of many-dimensional spaces via algorithms which sample points you're interested in more often than points you're not interested in -- check out the Metropolis-Hastings algorithm for an example of useful Monte Carlo in action.
That is exactly what makes Monte Carlo neat! There is nothing random about pi, yet using randomness we can arrive at pi.
In this case, the error would not necessarily go to zero as the number of points increases without bound.
In the particular case of a grid based deterministic probe, and a quarter-circle target, it seems clear that this would not happen.
But consider another example where the underlying target was "all points with rational coordinates". All the probes in a grid sampling scheme would hit the target, but the target has measure zero.
Incidentally, the idea of using a deterministic, low variability sequence for sampling is called quasi Monte Carlo (http://en.wikipedia.org/wiki/Quasi-Monte_Carlo_method). It can give almost order 1/n convergence, much better than the 1/sqrt(n) convergence possible with ordinary Monte Carlo.
And how exactly would the Monte Carlo version differ here? Every single random number generated is going to be rational isn't it?
Unless your fixed grid includes every single rational point that could be expressed by the (P)RNG.
Which no one cares about because (1) this isn't a probabilistic process in the first place, so "bias" itself is meaningless, and (2) there is now an exact bound on the error, unlike the previous case (I guess you can think of this as the "variance" if you want).
I really wish people would stop trying to find ways of calling their algorithms "Monte Carlo" just to make their work sound fancy. All it really achieves is it makes them avoid thinking about how to solve the problem. Monte Carlo isn't a universal hammer. First you're supposed to show randomness actually helps you gain something, then you're supposed to start using it.
I use that trick a lot, for instance with Euler problem 307 I could not find the answer easily in an analytical way, did the simulation, found an approximate answer (to within 6 decimal places or so), used that to figure out what I was doing wrong and then computed the real answer.
Some may see that as cheating, but it works wonders and not just on that particular problem.