Tue 09 Oct 2012 10:57:39 AM UTC, comment #2:
Thank you very much for your response. This clarifies matters a lot. I'll be using 'state' from now on.
I understood that the 'rand' and 'randn' functions have a separate seed. I'm not sure the reasoning behind this. Of course, one benefit is that statements with rand and randn now 'commute', as given in the documentation.
In practice this might not outweigh the confusion that some random number generators should be initialized, while others depends on these 'primitive' generators. In particular, in a large program, one might forget what kind of random number functions one is using.
For example, both 'randperm' and 'laplace_rnd' use 'rand', so these do not need to be initialized separately. 'rande' is using its own state, while 'geornd' depends on the initialization of 'rande' (there seem to be a typo in the documentation of 'rande'? 'randn' should be replaced by 'rande'?).
Regarding to the real case. The stripped-down example might sound artificial, not a show-stopper at all, and could be caused by bad programming, but I encountered it in the following way.
I'm running a server and several clients. Each client listens to the server and spams an Octave job. Each Octave job is then performing a Monte-Carlo-like simulation, which I hoped to be different between the jobs.
However, upon testing I saw that every client was actually doing exactly the same, caused by the same initialization of the random seed, as in the start-up script the clients are started all at once in the background, on several cores of the same machine. I guess this all happens within one microsecond and therefore each get the same seed.
At the end I solved it by using a seed provided by the server.
Another entropy source might be the current process ID. One can add this to the seconds of the date and the number of microseconds for initializing the seed. I think that this will solve it too for my case.
|