I was thinking of how to represent this process graphically on a computer screen. Assuming one wanted to perform a demo of this algorithm (in the spirit of XTANGO, an algorithm animator that I had used for my senior project in 1994), in order to represent the square and the circle on-screen, one would need to represent the objects with pixels. Many desktop and laptop computer screens these days have a minimum resolution of 800x600 pixels; assuming this resolution, I wanted to see how this algorithm could be animated using a square with 100 pixels per side.
The problem is how to define "reasonable." As you stated, since the relative error falls as 1/sqrt(N), where N is the number of samples, and 100x100=10000 pixels, then for, say, even a relative error of 1/100, we would need to fill up the entire square (10000 pixels). I would really like a relative error of 1/1000, in which case we would need 1000x1000=1000000 samples, which would require filling up a square ten times longer per side.
This is unlikely to work in practice with most desktop and laptop computer screens; so, I'll lower my expectations slightly. I'll be very lenient and set my acceptable relative error to 1/10. Then, since the relative error falls as 1/sqrt(N), since sqrt(100)=10, N can be 100. The square has an area of 100x100=10000 pixels.
This would allow a very rough estimate of pi that could actually be demonstrated graphically using an algorithm animator.
Benjamin L. Russell
--- On Mon, 4/28/08, jerzy.karczmarczuk@info.unicaen.fr
Benjamin L. Russell:
Assuming the square had 100 pixels per side, on the average, approximately how many random pixels should be plotted in the square before obtaining a reasonably good estimate of pi?
Nothing to do with Haskell...
What do you mean by "reasonable"? This Monte-Carlo procedure is very inefficient anyway. The relative error falls as 1/sqrt(N) where N is the number of samples, so, several hundred thousands of samples may give you just three significant digits. And, at any rate, this has nothing to do with pixels, what, introduce one more source of errors through the truncation of real randoms?
Jerzy Karczmarczuk
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe