[Numpy-discussion] Random number generators.

[Charles R Harris]

On 6/4/06, Robert Kern <robert.kern at gmail.com> wrote:
>
> Charles R Harris wrote:
> > For generating large
> > arrays of random numbers on 64 bit architectures it looks like MWC8222
> > is a winner. So, the question is, is there a good way to make the rng
> > selectable?
>
> Sure! All of the distributions ultimately depend on the uniform generators
> (rk_random, rk_double, etc.). It would be possible to alter the rk_state
> struct
> to store data for multiple generators (probably through a union) and store
> function pointers to the uniform generators. The public API rk_random,
> rk_double, etc. would be modified to call the function pointers to the
> private
> API functions depending on the actual generator chosen.
>
> At the Pyrex level, some modifications would need to be made to the
> RandomState
> constructor (or we would need to make alternate constructors) and the
> seeding
> methods.



Heh, I borrowed some seeding methods from numpy, but put them in their own
file with interfaces

void fillFromPool(uint32_t *state, size_t size);
void fillFromSeed(uint32_t *state, size_t size, uint32_t seed);
void fillFromVect(uint32_t *state, size_t size, const std::vector<uint32_t>
& seed);

So that I could use them more generally. I left out the method using the
system time because, well, everything I am interested in runs on linux or
windows. Boost has a good include file, boost/cstdint.hpp, that deals with
all the issues of defining integer types on different platforms. I didn't
use it, though, just the stdint.h file ;)


Nothing too bad. I don't think it would be worthwhile to change the
> numpy.random.* functions that alias the methods on the default RandomState
> object. Code that needs customizable PRNGs should be taking a RandomState
> object
> instead of relying on the function-alike aliases.


I'll take a look, though like you I am pretty busy these days.

--
> Robert Kern


Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20060604/1e0222a4/attachment-0001.html>