Shuffle - Comments

Comment by Rik Hemsley on "Shuffle"

Rik Hemsley — Sun, 02 Dec 2007 01:46:51 GMT

I found a well designed algorithm here: http://www.secureprogramming.com/?action=view&feature=recipes&recipeid=23

But for my toy card game, written in Ruby, I ended up using something very simple, but effective:

cards.sort_by { rand }

Comment by Julian on "Shuffle"

Julian — Sun, 02 Dec 2007 02:19:51 GMT

I use an algorithm that I learnt by studying a long-forgotten Commodore-64 BASIC program in the mid-80s.

create an array of 52 cards.
for X in 1..52
{
R = random number from 1..52
Swap card X with card R.
}

Advantages:
* Simple.
* Takes a fixed, short amount of time to run.
* Doesn't require two arrays; it's all done in place.

Comment by mike on "Shuffle"

mike — Sun, 02 Dec 2007 08:34:15 GMT

Julian, I added the Array Swap algorithm. Seems about in the same range, time wise, tho it is, as you note, simpler and presumably takes less memory.

One problem, of course, is that it's difficult to assign a degree of randomness to any one of the approaches. For me, anyway ...

Comment by Eric Lippert on "Shuffle"

Eric Lippert — Mon, 03 Dec 2007 11:26:00 GMT

Your original algorithm -- for each source card pick a destination slot at random, try again if it is already filled -- is O(n^2) on average for a deck with n cards. (Proving this is straightforward, you just have to solve a very simple probabalistic recurrance, email me if you want the details.) But yes, it is gross and the running time is probabalistic -- it could be arbitrarily long if you have bad luck.

Your next attempt -- for each destination slot, pick a random source slot, compact the deck every time -- is also O(n^2), but at least is bounded. There cannot be more than (n/2)(n+1) array moves during compaction.

Your third attempt -- for each slot, swap randomly with another member -- is efficient at O(n) but has the unfortunate property that some final configurations are more common than others, ie, this algorithm has bias. (Proof: do it with a deck of three cards. There are six possible shufflings. The algorithm does three swaps on three cards so there are 3^3 = 27 possible sequences produced. 6 does not go evenly into 27, so some of the 6 possbilities must be overrepresented in the 27 possible outcomes.)

The standard way of implementing this algorithm is: associate each card with a random real number between 0.0 and 1.0. Sort the list based on its associated number. That's O(n log n) and has no bias.

Note that the randomness source should be crypto strength. Otherwise it is possible to deduce the state of the entire deck from a portion of it. See my commentary on Greg's article here:

http://blogs.msdn.com/gstemp/archive/2004/02/23/78434.aspx

(Just substitute "cards in a hand" for "characters in a password".)

Comment by Julian on "Shuffle"

Julian — Sat, 08 Dec 2007 23:46:55 GMT

Jeff Atwood took up this challenge in two posts.

http://www.codinghorror.com/blog/archives/001008.html

http://www.codinghorror.com/blog/archives/001015.html

I was forced to admit that he was right and I was wrong.

http://www.somethinkodd.com/oddthinking/2007/12/09/shuffling-and-ownage/

Sorry.

Comment by mike on "Shuffle"

mike — Sun, 09 Dec 2007 00:44:11 GMT

Yeah, I followed up:

http://www.mikepope.com/blog/DisplayBlog.aspx?permalink=1858