On Thu, Apr 24, 2014 at 10:02 AM, Matthieu Brucher <matthieu.bruc...@gmail.com> wrote: > Yes. If several threads use the same RNG, you cannot ensure that they > are always accessing it with the same pattern. The only way to have > reproductible results is by using PRNG (real ones, because as Sturla > said, just changing the state of the same RNG won't ensure good > statistical properties).
The rand_r() function that Lars mentioned is like using different RandomState instances in each thread with their own seeds. It just happens to be of poorer quality than RandomState and *much* poorer quality than a CTR-mode block cipher, as you suggest, so it suffers more quickly from the independence problem. But the different threads aren't touching the same state, so it's a different set of problems than the one you cite. > My personal choice is using counter-based RNG like crypto functions as > the state is smaller than MT (a key per thread + a counter) and with > the inclusion of such functions in current processors, you get values > faster than MT. -- Robert Kern ------------------------------------------------------------------------------ Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ Scikit-learn-general mailing list Scikit-learn-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
