It has been shown that QB's RND repeats after a certain number of entries (65536?), which means it has very limited capacity to produce more than that many random points. Since the points are (ideally) randomly distributed, the accuracy (number of decimals that will probably be correct) goes as the square root of the number of points; so to get 3.141, you need about a million points; to get 3.141593, you need a trillion (which can't even be counted by QB's LONG datatype). Your best bet is to implement a much better performing generator, such as the Mersenne Twister. Considering the number of calculations, it would be worthwhile to write both the generator and the tester (x*x + y*y < 1) in assembly, though it will still take hours to complete, even taking full advantage of modern processors (up to parallel processing, which is completely impossible in QB; SIMD instructions might be possible, however).
Speaking of optimizations, this is an embarassingly parallel problem, so you could just spawn a million threads (using, say, Java, which is the most accessible multitasking language, but C++ will run faster) and have them all calculate the same thing, piling on more iterations seperately. A million threads of course wouldn't be too useful on a desktop machine (maybe 16 threads tops), but that's essentially how they do it with the supercomputers, which are all huge parallel setups.
Tim
|