February 6th, 2012, 3:51 am
I haven't been following this thread. Apologies in case I am repeating things ...I built a PRNG library at work. The MC methodology is like this:Every path in a MC simulation is assigned its own seed, and the path is generated from this seed by the primary RNG. The seed for each path is generated with a secondary RNG. The library was generic, but MT19937_64 (64-bit Mersenne Twister) was used for the primary RNG, and a 64-bit LCG was used for the secondary seed generator. This is fully scalable: The MC simulation will be identical regardless of how many parallel processers are used. The U(0,1) variates generated by this scheme passed all of the tests in L'Ecuyer's BigCrush test suite (i.e. both intra and inter-path correlations were tested for).The implementation of the MT and LCG was largely copied from boost. However, one article I read claims that the new 128-bit version of MT gives the best U(0,1) generator for multicore platforms. It takes advantage of some SIMD instruction set (I think, I know little on this), and would be worth implementing.There is also the following issue with generating N(0,1) and other variates from U(0,1). There are obviously many different methods, and which one is best depends on the application. For example, quantile (i.e. inverse CDF) has certain optimal properties for MC simulations, while apparently ziggurat is the fastest N(0,1) generator for multicore processing. A good design would allow for multiple methods, whereas boost only allows one method for each variate (e.g. boost uses the slow form of BM for generating normal variates from U(0,1) ). Even if the client decides on the quantiile method, I would assume there are different normal quantile algorithms with different speed/accuracy trade offs, and thus ideally multiple algorithms should be available for a given method as well.We also used the Eigen library to make multivariate generators.Please let me know if anything I have mentioned would be of use to the QFCL project.