Rod Pemberton <do_not_have@[EMAIL PROTECTED]
> wrote in part:
> :-) Thank you. Did you look at it enough to understand how it cuts the
> deck with an inexact cut without under/overflow from each half of the
deck?
iAs this is ALA, I plead the 5th: I refuse to confess any fluency in C
:)
> First, human shuffling isn't random.
Agreed. But humans also don't start with a new ordered deck
of cards for each hand. The gathering of played cards and
reshuffling adds entropy.
> Second, rand() is usually implemented as pseudo-random number generator
> (PRNG). So, there's no way (AFAIK) to get random results from it no
matter
> how you use it. From plots I've seen, it seems the first, second, third
> order combinations of typical rand() values are still non-random. So,
you
You can sometimes do better than others. Knuth has quite a
bit on this.
> Edition, Addison-Wesley, 1998, p. 106 (line 26) & p. 108 */
> next = next * 6364136223846793005LL + 1;
> /* was: next = next * 0x5deece66dLL + 11; */
> return (int)((next >> 21) & RAND_MAX);
A very standard linear-congruent PRNG.
> The compilers doc's recommended losing the lower bits of it's
> rand() function - too static.
And the upper bits aren't too great either. This is where RAND_MAX
has to be well-chosen.
> And, since the results didn't look quite natural on my
> machine with rand(), I randomized the range also on the
> flutter (i.e, two rand()'s). With the dual rand()'s, output
> looked from my compiler looked slightly more natural to me
> after three shuffles.
Looks are very deceiving. There are specific tests (Chi square IIRC),
and good-quality randomness is necessary for machines moreso than
humans since there usually are many more trials for any non-random
bias to exert itself.
-- Robert
|
