[Haskell-cafe] approximating pi
Benjamin L. Russell
dekudekuplex at yahoo.com
Wed Apr 30 01:12:28 EDT 2008
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 at info.unicaen.fr <jerzy.karczmarczuk at info.unicaen.fr> wrote:
> 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,
> one more source of errors through the truncation of real
> Jerzy Karczmarczuk
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe