Every 7 kittens born, 6 are normal size and 1 special size!

[Tad Carlucci]

A couple thoughts:

--

The absence of 'blips' is sufficient to prove non-random. Put another way: if there is NEVER a breeder who can show every Mega box they produced came exclusively from pairings of mega-to-teacup, and no other, then we should look for some bias in the system. True randomness will produce extremely surprising results. [A run of 5,000 males and no females? OK, but it's still random.]

--

There's a lot of smoke being thrown that computer-generated randomness is not true randomness. The implication is that, since a pattern may arise, it will arise. This is NOT the case. Yes, modern pseudo-random generators are THEORETICALLY capable of producing a pattern. But we're not concerned with that. All we care about is, over the expected useful life of the generator, we have a reasonable expectation that no pattern will arise. Remember, we're not talking about all possible sequences, here. We're talking about meaningful sequences, actually being used, in an actual implementation.

So, who cares if there is a THEORETICAL chance, that, after producing a series of 100 trillion numbers, the series repeats? We're talking about starting at a given point in that cycle, extracting a few billion values, then stopping.

In PHP (not MySQL, since PHP is the programming language and MySQL is only the database engine) we have three possible ways.

rand() is no good. Given any series of three sequential outputs, we can always produce the fourth. The only reasons rand() is offered is legacy support and, given the same seed, it produces the same sequence so it's good for quick-and-dirty, repeatable tests.

mt_rand() is not only far faster than rand(), it's far better. With mt_rand() we can't do repeatable tests since it's seeded from the system entropy source (/dev/urandom on most Unix-like systems). Other than that, mt_rand() is a drop-in replacement for rand(). mt_rand() is good enough for general application use where we need sequences of only a few (say, a million or two) values.

openssl_random_pseudo_bytes() is available on PHP if OpenSSL is installed (which is virtually all virtual hosting systems). It *IS* intended AND vetted for cryptographic use.

--

But, of course, we also need to examine in-world randomness. That means llFrand() in LSL/Mono. llFrand() has issues. Many of them come from the scripter not knowing (or forgetting) that it does NOT use the full range. llFrand() only produces random values in 20-bit chunks, but many forget that as assume it can be extended to 32-bit integers and remain "random" over the extended range.

llFrand() uses Mono. The random generator in Mono (and on .NET) is the System.Random class. System.Random is similar to PHP rand() (it is seeded by hand), but more complex [falling between rand() and mt_rand()].

llFrand() is good enough for short runs (say a few thousand) but, if you're looking for millions, you're best off shipping the problem over to your PHP backend.