bugGNU Octave - Bugs: bug #36867, randn gives same number when rand...

 
 

bug #36867: randn gives same number when rand is initialised with a random seed

Submitted by:  B <brt>
Submitted on:  Wed 18 Jul 2012 05:34:29 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: Wont FixAssigned to: None
Originator Name: BOpen/Closed: Closed
Release: 3.2.4Operating System: Mac OS

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Tue 09 Oct 2012 07:36:23 PM UTC, comment #3:

You're right that having different seeding behavior between the primary and derived generators might seem odd. The discussion about the reason for this choice was about 5 years ago on the developers list but I can't remember why off the top of my head the reason for this choice.

Effectively the process id could be used as additional entropy. Though there is probably another corner case where using it as entropy doesn't help. I suppose this should be added to the initialisation of the generators, but till then you could add something like

s = rand ('state');
s(end) = getpid ();
rand ('state', s);

to get the behavior you want

D.

David Bateman <dbateman>
Project Member
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.

B <brt>
Thu 27 Sep 2012 02:15:09 AM UTC, comment #1:

Firstly please note that the octave rand and randn functions are seeded seperately and so the "seed" doesn't affect the randn. Also please note that the use of the "seed" keyword forces the rand function to use the old and terribly slow randlib function rather than the newer Mersenne Twister generator. So use "state" instead of "seed" (something similar is true with Matlab as well)

Now for the "bug": When Octave first calls rand it initializes the "state" vector of the random generators in an attempt to have different random sequences between instances of Octave. If the "/dev/urandom" device is available and has sufficient entropy it is used to set the state vectors. If there isn't sufficient entropy in /dev/urandom it falls back to using the seconds of the date and the microseconds of the cpu time of the current process.

Running in the manner you are, the entropy pool in /dev/urandom is exhausted in the first call to rand (ie the call "rand*1000") and then when randn is called to initialize the state vector of the randn generator Octave is forced into falling back on the date and the cpu time to set the state vector of randn. Guess what if you run your command fast enough randn gets the same initial state.

This seems like a really artifical case, and I don't see another entropy source we can use to set the state vectors. So I'm flagging this as "Won't fix". Can you give a real case where this behavior causes an issue?

D.

David Bateman <dbateman>
Project Member
Wed 18 Jul 2012 05:34:29 PM UTC, original submission:

If I have a script with the following contents
then it will output two random numbers. However, if I run this
script twice from the command line with 'octave --eval
script.m', very quickly after each other, then the second random
number of the first run is the same as to the second run. The
first random number does differ between the runs. If one waits a
bit longer, then the two second random numbers are different.

From my point of view the expected behaviour would be that the
second random number should be different between different runs,
as is with the first random number.

That is the reason I though this could be considered a bug.

B <brt>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by dbateman (Posted a comment)
  • -unavailable- added by brt (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 27 Sep 2012 02:15:09 AM UTCdbatemanStatusNone=>Wont Fix
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1