[Octave-bug-tracker] [bug #36867] randn gives same number when rand is initialised with a random seed

[B]

Follow-up Comment #2, bug #36867 (project octave):

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. 

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36867>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/