Well... a truly random number generator will have infinite period, so I assume you mean a pseudo-random number generator (PRNG). In that case, the period is limited by the algorithm used and by the number of bits in its internal state (which does not depend on the number of bits in the processor). Theoretically, the maximum period is achieved if all states lie in the same (maximum period) cycle, which implies a period length of 2^n (where n is the number of bits in the PRNG's internal state).

So, no, it does not depend on the "bits in the processor" nor on the programming language.

As for your last question... it depends on what you're using that random array for. Depending on the purpose of the random array, the most important properties should be stuff like:

1) Uniform distribution of symbols/digits;

2) Lack of correlation between symbols/digits;

3) Unpredictability of symbol/digit sequence without the "seed".

Common tests used to check if a certain sequence passes some of these criteria (mostly #1 and #2) include the monobit test, runs test, longruns test, poker test and autocorrelation test.

These criteria are not sufficient to ensure that a sequence of symbols is truly random, but probably enough to determine whether a certain sequence of digits was likely to be independently sampled from a uniform distribution.

Tome's answer is great.  As far as implementation goes, I have a lot of trust in Wolfram's Mathematica.

I am interested in this question, too, and plan to use Mathematica's functionality, described here:

http://reference.wolfram.com/language/tutorial/RandomNumberGeneration.html

If you guys don't have a license and want something tested, I can run it for you.

Thanks for reply Tomé Silva. Yes I was talking about PRNG.

1) What is the internal state?

2) To my understanding, in Linear Congruential RNGs

s(i+1) = (a*s(i)+b) mod M

.the period depends on 'M' which is largest number that can be stored in the computer and the sequence repeats after that if a, b and s(1) is selected properly.

3) Is it sufficient to say that unbiased selection of numbers (or digits in the numbers at any bit position) in the sequence should be Uniformly distributed

1) In your example, the internal state is basically the "s" variable, which is updated at every step with a function of its previous state.

2) The period depends on the size of the state (in this case, s), not necessarily on the size of that M variable. A simple example...

s(0) = seed1

s(1) = seed2

s(i+2) = ( a*s(i) + b*s(i+1) + c ) mod M, with M being the largest number that can be represented by the programming language.

So, here you have a PRNG that can generate a sequence with a period larger than M, since it stores its state as 2 numbers, rather than 1. So, in your example, the sequence period was limited by the size of s in bits; in my example, the sequence period is limited by _twice_ the size of s in bits. This example shows that even if your CPU (or programming language) is limited to 64-bit numbers (or 8-bit numbers), you can make a finite state machine (or PRNG) with an arbitrarily large internal state (assuming you have enough memory).

3) Again, it depends on what you want to do with those random numbers. Being uniformly distributed doesn't guarantee that there isn't a correlation between consecutive digits, for instance. Though uniform distribution might be enough for some purposes (e.g. simple simulations), it might not be enough for other purposes (e.g. generating a keypair for a assymetric encryption).

It is difficult to improve on Tome's answers. As to useful features or properties, I have two more suggestions.

1. The most pragmatic requirement today for a (P)RNG is to pass  a standard package of statistical tests like TESTU01 (especially, the "big crush" package). It is free software and fairly easy to install and use. The package is capable of discovering subtle flaws in an RNG design.

2. Linear generators often allow for "jump ahead" from one state to a state which is n steps away, where n is less than the period. The basic idea is that there is a natural way to describe successive states as "x^0, x^1,... x^{2^p-1} where p is the size of the state. Jumping ahead over a "distance" n amounts to computing x^n as a polynomial modulo the (degree p) characteristic polynomial (CP) of the generator. Once this "jump polynomial" is computed, the jump can be made in a fraction of a second, regardless of the current position. This works if the CP is a primitive polynomial. When the period is huge (like Mersenne Twister or worse), computation of a jump polynomial can take several minutes.

Jumping ahead is useful e.g., if you want to draw several uncorrelated streams from the same generator. The period should be large of course.

PS: I prefer RNG above PRNG as I believe that truly random generators are an unreachable ideal.

Marcel's suggestion is wise: when in doubt, running an appropriately sized amount of PRNG output through available statistical test packages can at least tell you whether a certain PRNG is clearly bad or not.

Regarding linear generators, I would advise against its use, unless you really need a high-volume of pseudo-random numbers and quantity is more important than quality. Though it's correct that they display the "jump ahead" property, this property is not restricted to linear generators. If you need this property, you can also use something like AES in counter mode, for which there are highly efficient implementations.

I will not defend them with my life, but I'm rather satisfied with linear generators. It is true that Mersenne Twister (MT) failed a few tests of TESTU01 (typically, the tests related to linearity) but that is because MT uses linear tempering. I prefer the xorgens (XG) generators, which are made non-linear by tempering with a simple Weyl generator. They pass all statistical tests and have an excellent initialization.

I have recently proposed a new RNG design mixing ingredients of MT and (mainly) XG to overcome that XG is available for restricted sizes only. It is as fast as XG but it has considerably more complex characteristic polynomials. For each involved size, it passed all statistical tests. I have nearly finished some rewriting of my paper following referee advise. I guess it will be finally accepted for publication in a few months.

Amusing as it may be, John von Neumann's opinion "Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin" [Wikiquote] is both memorable and a useful caution.  I have often wondered why PRNGs are so sought after, given that I find it not harder to randomize without recourse to strictly numerical methods.  In any case, such sequences are neither periodic nor should they exhibit seasonality, trend, or autocorrelation.  As distinct from a pseudo-random sequence; for example, one that is linear-congruentially generated, there is no pattern nor predictability to the random sequence; hence, no dependence known to me on processor architecture. However, I suppose that a performance dependency of PRNG algorithms might be expected, such as the time to compute a sequence of given length. 

The reasons for using (P)RNG's (which automatically fail to be truly random) are manifold:

1. The alternative of catching noise from the universe is not really better as it must be artificially purified from outbursts and other "regularities". Moreover, such a sequence cannot be reproduced for an experiment, unless it is kept in memory in its entirety. The production of such sequences is more expensive and relatively slow.

2. RNG output is cheap, fast, reproducible, and passes all state-of-the-art statistical tests.

3. Unsophisticated RNGs can be combined into more sophisticated generators by a variety of methods. One may "xor" the output of two or more generators. A second RNG may decide whether or not the next output of the first will be skipped. Or, the first generator's output goes into a large buffer, and the second RNG decides which buffered number becomes the next output (the emptied position is then refreshed).

There is an RNG for every taste.