bugGNU Octave - Bugs: bug #53300, rand('state') at Octave start is...

 
 

bug #53300: rand('state') at Octave start is not correct

Submitter:  Mike Miller <mtmiller>
Submitted:  Thu 08 Mar 2018 12:15:45 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 09 Mar 2018 10:00:02 PM UTC, comment #8: 

Agree, this works for me now, thank you for digging into the initialization.

Mike Miller <mtmiller>
Group Member
Fri 09 Mar 2018 04:55:03 PM UTC, comment #7: 

Indeed, I meant bug #50256

Avinoam Kalma <avinoam>
Group Member
Fri 09 Mar 2018 04:08:57 PM UTC, comment #6: 

Okay, closing report.

The wrong data type bug is actually #50256.  The transposition to 50526 turns out to be a bug about GRUB bootloader which was momentarily confusing.

Rik <rik5>
Group administrator
Fri 09 Mar 2018 08:08:37 AM UTC, comment #5: 

@Rik, after fixing this bug, could you please look also at bug #50526 - "Wrong data type for rand ('twister')"

Avinoam Kalma <avinoam>
Group Member
Fri 09 Mar 2018 12:18:04 AM UTC, comment #4: 

Okay, I found the problem.  During initialization we repeatedly initialize the random number generator using entropy, and then store the created state vector for each random number generator.  We do this 5 times for rand, randn, rande, randp, and randg.

What we were not doing is restoring the state vector after all this initialization.  When you query rand ("state") you were getting the state vector for the rand generator, but the generator itself was still using the last configured value which happened to be randg.

This cset seems to fix it (http://hg.savannah.gnu.org/hgweb/octave/rev/53db3b152397).  I applied it to the default branch, but we could consider backporting it to stable as well.


Rik <rik5>
Group administrator
Fri 09 Mar 2018 12:05:07 AM UTC, comment #3: 

This also works


tmp = randn ("state");
init_state = rand ("state");
x1 = rand (4,1);
rand ("state", init_state);
x2 = rand (4,1);
isequal (x1,x2)


I can sort of trace what is happening, but don't have a solution yet.  The situation seems to be connected with a variable rand_state which holds the internal state for each of the random number generators.  By using any function which switches the distribution away from the default rand, and then switching back, the behavior works.

I also get things to work by changing the default value of the current_distribution in the constructor.


octave_rand::octave_rand (void)
  : current_distribution (normal_dist), use_old_generators (false),
    rand_states ()


By making the default randn, rand will work.  But this just kicks the problem down the road because now the randn state does not work correctly at startup.



Rik <rik5>
Group administrator
Thu 08 Mar 2018 02:45:31 PM UTC, comment #2: 

Mike said: And if a throwaway call to rand is made at the beginning, the state is correct

This works for me and appears to be the only reliable
way to recover a previous sequence from randn.

At least, this should be clearly documented, including the need
to save the 'init_state' vector.

It is essential that users can reproduce results that were
previously computed. This is fundamental.

After this documentation, it would be good to put together
a better solution. It is reasonable to expect the generator
to use a default starting seed in any case.

Michael Godfrey <godfrey>
Group Member
Thu 08 Mar 2018 12:18:12 AM UTC, comment #1: 

And if a throwaway call to rand is made at the beginning, the state is correct


>> format long
>> rand ();
>> init_state = rand ('state');
>> x = rand (4, 1)
x =

   1.651948679287887e-01
   8.401639052217452e-01
   3.216938522577400e-01
   9.753170943097341e-01

>> rand ('state', init_state);
>> y = rand (4, 1)
y =

   1.651948679287887e-01
   8.401639052217452e-01
   3.216938522577400e-01
   9.753170943097341e-01



Mike Miller <mtmiller>
Group Member
Thu 08 Mar 2018 12:15:45 AM UTC, original submission:  

The vector returned by rand('state') when Octave first starts up is not correct. It is either wrong, it does not reflect the actual initialized state of the random number generator, or maybe full initialization of the random number generator is deferred until later.

By way of example, Octave has just started:


>> format long
>> init_state = rand ('state');
>> x = rand (4, 1)
x =

   8.509328575211026e-01
   2.406711138915200e-01
   5.562248016813642e-03
   1.887156618452461e-02

>> rand ('state', init_state);
>> y = rand (4, 1)
y =

   7.838035791867421e-01
   2.776541083181831e-01
   6.340473989655361e-01
   8.594205509389307e-01

>> rand ('state', init_state);
>> z = rand (4, 1)
z =

   7.838035791867421e-01
   2.776541083181831e-01
   6.340473989655361e-01
   8.594205509389307e-01



Once the state is set by a call to rand('state', sv), it is possible to recreate a previous sequence of random values. But when Octave first starts, the vector returned by rand('state') doesn't match up with the random values that are actually returned.

Mike Miller <mtmiller>
Group Member

 

(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 avinoam (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by mtmiller (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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-03-09 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2018-03-09 rik5 StatusIn Progress Ready For Test
    2018-03-09 rik5 StatusNone In Progress

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code