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

Submitter:  B <brt>
Submitted:  Wed 18 Jul 2012 05:34:29 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Wont Fix Assigned to:  None
Originator Name:  B Open/Closed:  * Closed
Release:  * 3.2.4 Operating System:  * Mac OS
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group Member
Wed 18 Jul 2012 05:34:29 PM UTC, original submission:  

If I have a script with the following contents

rand('seed',ceil(rand*1000))
rand
randn

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 Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-09-27 dbateman StatusNone Wont Fix
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code