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

Reply via email to