[Haskell-cafe] approximating pi

[Benjamin L. Russell]

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,
> introduce
> one more source of errors through the truncation of real
> randoms? 
> 
> Jerzy Karczmarczuk 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe