PRNG: Modules/Testing

OverlordQ has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks,

Some friends and myself are venturing into the area of clusterKnoppix (CD-Bootable openMosix based *Nix Distro), were wanting to do some tests related to parallel computing.

My set of tests I was assigned was PRNG (Pseudo Random Number Generators). We are trying to implement all of our tests in perl using Parallel::ForkManager to take advantage of openMosix.

Currently to Generate the random numbers, I was going to use: Math::Random, Crypt::Random, and Data::Random. To test the 'randomness' were were going to use Statistics::ChiSquare and ent.

Now my question is, what would be the best way to implement this? Are there any other Perl Modules we could test and/or other ways to test for randomness?

Thanks,
Brent G

Comment on PRNG: Modules/Testing

Replies are listed 'Best First'.
Re: PRNG: Modules/Testing by hossman (Prior) on Jun 01, 2003 at 06:19 UTC
You might want to look into Math::TrulyRandom, or if you want someone elses computer to do all the work of generating the number, use Math::RandomOrg. (random.org is cool.)	[reply]
Re: Re: PRNG: Modules/Testing by OverlordQ (Hermit) on Jun 01, 2003 at 06:58 UTC
I've tried Math::TrulyRandom, but it seems to hang during the make test, I might just be impatient, but it takes a long time.	[reply]
Re: Re: Re: PRNG: Modules/Testing by hossman (Prior) on Jun 02, 2003 at 06:09 UTC
More specificly, it takes an obscenely long time. That's the price you pay to compute your own high quality psuedo-random numbers... BUGS The random numbers take a long time (in computer terms) to generate, so are only really useful for seeding pseudo random sequence generators. ...it would be interesting to see some statistical comparison of using Math::TrulyRandom vs Math::RandomOrg to see if Math::TrulyRandom was worth using (on machines that have net access)	[reply]
Re: PRNG: Modules/Testing by adrianh (Chancellor) on Jun 01, 2003 at 10:24 UTC
Sounds like a nice idea. You might also want to look at Math::Random::MT, Math::Random::TT800 and Crypt::OpenSSL::Random While not PRNG you might also be interested in looking at Math::RandomOrg and Math::TrulyRandom. Implementation wise, I would build it with Test::Builder so it can happily work with the rest of the happy band of Perl testing modules.	[reply]
Re: Re: PRNG: Modules/Testing by OverlordQ (Hermit) on Jun 01, 2003 at 22:28 UTC
I'll have to check those other 4 modules, but still I'm having problems with Math::TrulyRandom. I forced the install of the module, ignoreing make test not working, and when the `truly_random_value()` sub get's called, that's when it usually hangs, eats cpu, and does nothing.	[reply] [d/l]
Re^3: PRNG: Modules/Testing by adrianh (Chancellor) on Jun 01, 2003 at 23:15 UTC
Works fine on my box (Mac OS X, perl 5.8). I'm afraid I don't have enough XS-fu to offer any advice on getting it running. Might be worth submitting a bug report. May not be what you're looking for anyway... from the C source: /* * WARNING: depending on the particular platform, truerand() output ma +y * be biased or correlated. In general, you can expect about 16 bits +of * "pseudo-entropy" out of each 32 bit word returned by truerand(), * but it may not be uniformly diffused. You should therefore run * the output through some post-whitening function (like MD5 or DES or * whatever) before using it to generate key material. (RSAREF's * random package does this for you when you feed truerand() bits to t +he * seed input function.) * * Test these assumptions on your own platform before fielding a syste +m * based on this software or these techniques. * * This software seems to work well (at 16 bits per truerand() call) o +n * a Sun Sparc-20 under SunOS 4.1.3 and on a P100 under BSDI 2.0. You +'re * on your own elsewhere. */ [download]	[reply] [d/l]
Re: PRNG: Modules/Testing by wufnik (Friar) on Jun 02, 2003 at 07:45 UTC
hola; regarding the tests rather than your source of random numbers: there are other random number "tests" as well as chi-square you will probably want to consider: entropy: the greater the information density, the more 'random' deviation from simple arithmetic mean: if data close to random,this should be 256/2... approximation monte carlo value for pi given data: good estimates => more random data serial correlation coefficient: for random values, this will be close to zero. all of these are implemented in the small, readily compilable program ent: http://www.fourmilab.ch/random re: sources of random numbers, if math::trulyrandom is proving problematic, you might want to consider using an industrial strength cryptographic RNG such as Yarrow, from counterpane labs, full source available (www.counterpane.com/yarrow.html). best of luck, wufnik -- in the world of the mules there are no rules --	[reply]