If you want to generate transaction numbers for online bank transfers that you give your customers, using any kind of pseudo random number generator is probably a bad idea (there are hardware devices that generate truely random numbers based on optical quantum effects).

If you want to write some simulations for which the correlation length of the build-in PRNG in Perl isn't sufficient, the Mersenne Twister is a probably a very good alternative.

Generation of pseudo random numbers is a big area of research, and I'm not very familiar with it; but my impression is that if you are willing to trade speed and/or memory, you can get even better PRNGs. But you should only bother if your use case requires it.

You could rely on the cosmos instead: Random.org: HTTP Interface Description.

Wow, interesting. Thanks for the link : )

It very much depends upon your use.

Mersenne Twister provides a very good PRNG, but it is, with sufficient samples, predictable. So, they say, this is no good for cryptographic purposes.

For other purposes, the CPAN implementation is excellent, but slow. It is also limited to 32-bits.

There is a 64-bit C version.

^†Things you may want: speed, repeatability, hard to predict, etc.

Updated! Does my question make more sense now?

Not at all. In fact, it even makes less sense. What do you mean by "breaks down in its ability to be random"? Note that for every PRNG, given the algorithm, seed and sequence number, the rest of the sequence is 100% predictable.

as people above mentioned you have to know for what you need the generator for. my personal opinion is as far as the software type random number generator goes, all of them are a joke if meant to be used for some real cryptography. rand() function in perl is inhereted from libc that has a RAND_MAX from 2**15 - 2**31 which is also interesting because since perl doesn't handle big integers very well by default, you need to use bigint.

also i read somewhere that the authors of rand() function guarantee that the number you get is a random but they don't guarantee that more of them are random - which implies that there is a pattern within the whole system.

to me regular MT with a period of 2**k-1 , k = 19937, is more than enough for my simulations. but i can't say if it will satisfy your requests. my former coworker had this problem with MT and some other algorithms (the period wasn't enough for him), so he turned to QRBG. now, this is a machine based generator that is nothing like software generators and it guaranties the randomness of one number or more of them. so my advice is : start worrying when the problem emerges, until then use rand() build-in function.

cheers