card dealer

Dave Angel davea at davea.name
Sat Sep 28 08:56:15 EDT 2013


On 28/9/2013 06:31, Ned Batchelder wrote:

    <snip>
>
> I've thought that way about it too: there are so many shuffles any way, 
> it won't be a problem.  But think about it like this:  if you shuffle a 
> deck of 52 cards with a default Python random object, then once you have 
> dealt out only 28 cards, the entire rest of the deck is completely 
> determined.  That is, given the sequence of the first 28 cards, there's 
> only one choice for how the remaining 24 will be dealt.  Depending on 
> what you need from your deck of cards, that could be a complete disaster.
>
> Is it a problem for a card game simulation?  No.  Is it a problem for a 
> program that analyze correlations between the start of the deck and the 
> end of the deck?  Maybe.
>

Only if there is some correlation between the random number algorithm
and whatever properties you're checking between start and end of deck. 
And if there is, then you've just struck one of the limitations of a
*pseudo* random gen.

I have no idea what sheme is actually used in Python's generator, but
one approach that helps avoid such troubles is to keep a pool of the
"next" P random numbers (where P might be a few hundred).  Then use an
*independent* random number generator (which could be very simple) to
select which item of the pool to use next (followed by replacement from
the first).

it's kind of a local-shuffle of the very long stream of numbers.

Even fairly poor random number generators, if they generate close to
2**n values (for a int size of n) generally become very good when
shuffled this way.


-- 
DaveA





More information about the Python-list mailing list