Neal Becker wrote: > One thing missing from random is a mechanism to share a single underlying > rng with other code that is not part of numpy.random. > > For example, I have code that generates distributions that expect a mersenne > twister (the shared, underlying rng) to be passed in as a constructor > argument. > > numpy.random shares a single rng amongst it's own distributions, but I don't > see any way to share with others.
Are you talking about C or Python? In Python, just instantiate numpy.random.RandomState() and pass it around. All of the functions in numpy.random are just aliases to the methods on a global RandomState() instance. C is a problem because the module is implemented in Pyrex, and RandomState is an extension type. I've tried working on exposing the C API as a PyCObject like numpy does, but it is incredibly tedious and, furthermore, is unlikely to capture the higher-level methods like multivariate_normal(). I believe that Cython has a way to automatically expose the C API of a Pyrex/Cython module, but I haven't had the time to investigate it. For everything but the higher level methods like multivariate_normal(), we might be able to expose the pointer to the rk_state struct on the RandomState object as a PyCObject and punt on exposing the API. The C user can copy the randomkit.[ch] and distributions.[ch] files into their own code and operate on the rk_state pointer with those functions. We may be thwarted by symbol conflicts on some platforms, but I'm not sure. Contributions are, of course, welcome. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
