On 6/4/06, Robert Kern <[EMAIL PROTECTED]> wrote:
I'll take a look, though like you I am pretty busy these days.
Chuck
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 ;)
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
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
