Dear Milo, I was not making the case for jumping ahead, it was just a report of the common reasons why that technique has been perceived in the literature as an improvement over the pre-2006 situation, as had been asked. Among others Mascagni was of such opinion, together e.g. with L'Ecuyer and Matsumoto. Again, we're happy if you contribute code for random initialization, which is just as useful. No parallelization method is perfect for what we know (talking of MT-like generators). But the better you know the assumptions and the risks, the better one can hedge them. E.g. in the random initialization case I would suggest using a source of real random numbers for seeding, instead of an LCG, or atleast use a nonlinear generator (mixing two linear generators is way too risky).QuoteHowever, there is still no guarantee that streams are uncorrelated. There is the well-known danger that by splitting up the cycle, long-range correlations become short-range correlations which are vastly worse. Sure, you might get inter-stream correlations, that's aknowledged in all jump-ahead works afair. But the same holds for leap-frog, *in addition* to other problems. On the other hand random init IS risky for sure, we just dont know how much. Choice is a matter of taste and it all depends on environment and constraints. Moreover there are reasons (related to the way MT works) to believe that long range correlations - if any - would not be significantly different than those just beyond the state size limit. For other PRNGs it's a different story.Anyway we cant compare a surely existing but not measurable risk and a hypotetical but non measurable risk, there's not enough data. I could not really favour any of the two in such uncertainty, so better keep the choice and provide both options.QuoteIf the streams are overlapping frequently enough to affect the results then this will be revealed with proper testing. It is similar to serial random number generation, where you cannot prove that there are no intra-stream correlations (apparently even a suitable mathematical definition of pseudo-randomness is unknown) but must rely on tests. Why should a problem be revealed by testing already? and what is "proper" testing anyway? There's no way to know in advance how much a test guarantees, especially in a "random" setting where 1) test results can vary by definition
and 2) simulation outputs are confidence intervals that may well hide a bias even when they're consistent with eachother (and analytical values). We hope that QFCL will be used in a much larger amount of ways and longer times than any testing can compare to!See the Ferrenberg affair, where testing didnt discover any PRNG problems in time and issues came up later only on the field, on an actual application. Besides, if you're worried of long range interactions, then you should be even more so of the quality of MT itself in a serial setting already, which is known to have low diffusion speed and fail various statistical tests!Quote(1) There are even more methods: They recommend parallelization by what they call "parameterization", rather than the 3 cycle division methods above. For many RNGs (MT is not discussed there), the state space naturally divides itself into a number of disjoint cycles. Alternatively, it may be possible to parameterize the iteration function for obtaining the next state from the current one.This is the approach taken e.g. by a variant of MT, which is also implemented in Intel's MKL. It has similar drawbacks to jumping ahead with the classical MT, but might be preferable in some situations. We might code this too, it's just a matter of time and priorities.Quote (2) Application based tests as opposed to statistical tests (I don't think this was mentioned in this thread).Sure, the more testing QFCL gets the better! It is also more practical for us even though in various ways not as powerful as modern RNG test batteries.