@halley: What 8 bit processing are you talking about? All the small modulus operations? I just threw those in because people earlier in the thread were noticing unpleasant patterns with those. They're superflous as it turns out, because the real unpleasant pattern is the series of raw numbers returned by the stdlib random() function itself (in Linux):

0(!), 31031784, 26852320, 4242000, 842292, 453960, 211932, 84160, 0(!!), 31031784, ...

It appears that there are only 8 "random" numbers before the series repeats! Something is badly wrong. Here is the source to avr-libc 1.6.2's random():

`static long`

do_random(unsigned long *ctx)

{

/*

* Compute x = (7^5 * x) mod (2^31 - 1)

* wihout overflowing 31 bits:

* (2^31 - 1) = 127773 * (7^5) + 2836

* From "Random number generators: good ones are hard to find",

* Park and Miller, Communications of the ACM, vol. 31, no. 10,

* October 1988, p. 1195.

*/

long hi, lo, x;

x = *ctx;

/* Can't be initialized with 0, so use another value. */

if (x == 0)

x = 123459876L;

hi = x / 127773L;

lo = x % 127773L;

x = 16807L * lo - 2836L * hi;

if (x < 0)

x += 0x7fffffffL;

return ((*ctx = x) % ((unsigned long)RANDOM_MAX + 1));

}

long

random_r(unsigned long *ctx)

{

return do_random(ctx);

}

static unsigned long next = 1;

long

random(void)

{

return do_random(&next);

}

void

srandom(unsigned long seed)

{

next = seed;

}

As you can see, assuming you don't call srandom(), the first random number generated should be 16807, which it is in both yours and my sequences. Why not Linux as well?

Mikal

EDIT: Is there anyone using 32-bit Linux experiencing this problem?