Re: Why you don't want to use /dev/random for testing

On Wed, Nov 11, 2009 at 01:04:49PM -0600, David Nicol wrote: there's always http://fourmilab.ch/cgi-bin/Hotbits?nbytes=128fmt=hex although I don't know what their massively parallel availability is. Not much. There's also Net::Random that provides a vaguely reasonable interface to it. --

Re: Why you don't want to use /dev/random for testing

I should note, I wrote an article on this awhile back. Take it with a grain of salt, as I'm not an expert in the area; I just wrote bindings for the ISAAC algorithm to Perl. http://jawnsy.wordpress.com/2009/06/04/performance-of-mathrandomisaac/ It compares the performance of multiple different

Re: Why you don't want to use /dev/random for testing

Dear Jonathan, thanks a lot for the link to this very interesting article! However, a more useful graphical representation of the quality of PRNG’s would be to take consecutive pairs of random numbers as the (X,Y) coordinates of a point to plot. Non-uniform distributions are then easily visible

Re: Why you don't want to use /dev/random for testing

The next version of NYTProf supports profiling some 'slow' perl opcodes. I've included the rand opcode for exactly this reason. Tim. On Tue, Nov 10, 2009 at 07:01:38PM -0800, cr...@animalhead.com wrote: Many of you know that the random number generator /dev/random is subject to delays when it

Re: Why you don't want to use /dev/random for testing

On Wed, Nov 11, 2009 at 10:22:23AM +, Tim Bunce wrote: The next version of NYTProf supports profiling some 'slow' perl opcodes. I've included the rand opcode for exactly this reason. I meant srand (though rand is also included, just in case). Though having just looked at the Configure code

Re: Why you don't want to use /dev/random for testing

there's always http://fourmilab.ch/cgi-bin/Hotbits?nbytes=128fmt=hex although I don't know what their massively parallel availability is. Probably less than google charts. -- http://twitter.com/HankSwap tweets approximately every 36 hours using random delays. Promotional excerpts are fair use!

Re: Why you don't want to use /dev/random for testing

On Tue, Nov 10, 2009 at 10:01 PM, cr...@animalhead.com wrote: Many of you know that the random number generator /dev/random is subject to delays when it has not accumulated enough entropy, which is to say randomness.  These delays are said to be longer on Linux /dev/random that on some other

Re: Why you don't want to use /dev/random for testing

I'm not sure how many of these modules use it -- in particular, I know Math::Random::ISAAC only mentions it in POD. Using /dev/random isn't very portable -- what happens when you're on Windows? On Wed, Nov 11, 2009 at 2:15 PM, David Golden xda...@gmail.com wrote: On Tue, Nov 10, 2009 at 10:01

Re: Why you don't want to use /dev/random for testing

On Wed, Nov 11, 2009 at 2:40 PM, Jonathan Yu jonathan.i...@gmail.com wrote: I'm not sure how many of these modules use it -- in particular, I know Math::Random::ISAAC only mentions it in POD. Using /dev/random isn't very portable -- what happens when you're on Windows? Some things may check

Why you don't want to use /dev/random for testing

Many of you know that the random number generator /dev/random is subject to delays when it has not accumulated enough entropy, which is to say randomness. These delays are said to be longer on Linux /dev/random that on some other Unices. They occur particularly after a system is booted, which I

Re: Why you don't want to use /dev/random for testing

There are other options too, depending on your needs. The Math::Random namespace has tons of these, including one that I've worked on (Math::Random::ISAAC) and some others I've toyed with, notably the Mersenne Twister (Math::Random::MT) and TT800 algorithms (related to the Mersenne Twister;