numpy.random inconsistency of random numbers from other implementations

Hi everyone,

I would like to point out something that could either be called a feature or bug. For a science analysis I want to use the deterministic nature of the Mersenne Twister algorithm in order to produce the same set of random numbers using different languages and libraries. I decided to try the Mersenne Twister generator MT19937ar. I test three libraries that (I think) implement this algorithm, the GNU Scientific Library gsl_rng_mt19937, gsl_rng_uniform and ROOT’s TRandom3 .Uniform() in C++, and numpy.random.RandomState, numpy.random.random_sample() with numpy. Given the same input seed, gsl and ROOT give the same outputs a[i]. However, numpy gives output b[i]=a[2i], in other words it produces every other number produced by the C++. It is as if the MT has two state changes in python for every one in gsl and ROOT.

Here is my python code

#!/usr/bin/env python

import numpy
import random
seed=1969
prng=numpy.random.RandomState(seed)
random.seed(seed)
for i in xrange(10):
  print prng.random_sample(), random.random()

and my C++ code

#include <iostream>
#include <gsl/gsl_rng.h>
#include "TRandom3.h"

int main(int argc, char* argv[])
{
unsigned long int seed=1969;
    gsl_rng* rng = gsl_rng_alloc( gsl_rng_mt19937 );
    gsl_rng_set(rng, seed);

    TRandom3 root(seed);

    for (int i=0; i<10; i++){
        std::cout << gsl_rng_uniform( rng ) << " "<<root.Uniform()<< std::endl;
    }
    gsl_rng_free(rng);
    return 0;
}

[pv]

FWIW, Numpy produces the same random number stream as matlab:

>> s = RandStream('mt19937ar','Seed',1969)
s = 
mt19937ar random stream
             Seed: 1969
  NormalTransform: Ziggurat
>> s.rand()
ans =
    0.5990
>> s.rand()
ans =
    0.5777
>> s.rand()
ans =
    0.9256
>> s.rand()
ans =
    0.1372

vs

>>> from numpy.random import seed, uniform
>>> seed(1969)
>>> uniform()
0.5989977136290761
>>> uniform()
0.5776863658432689
>>> uniform()
0.9256443316932297
>>> uniform()
0.13716928036018283

[charris]

Closing this. @AlexGKim You might check the outputs for random unsigned int32.