Properly Ordered Card Hands¶

The 538 Riddler presented this problem by Matt Ginsberg:

You play so many card games that you’ve developed a very specific organizational obsession. When you’re dealt your hand, you want to organize it such that the cards of a given suit are grouped together and, if possible, such that no suited groups of the same color are adjacent. (Numbers don’t matter to you.) Moreover, when you receive your randomly ordered hand, you want to achieve this organization with a single motion, moving only one adjacent block of cards to some other position in your hand, maintaining the original order of that block and other cards, except for that one move.

Suppose you’re playing pitch, in which a hand has six cards. What are the odds that you can accomplish your obsessive goal? What about for another game, where a hand has N cards, somewhere between 1 and 13?

Brute Force Versus Cleverness¶

The first thing to decide is how many N-card hands are there? If there are only a few, I could just enumerate them all and count how many are orderable. If there are a lot, I'll have to be more clever. The answer is (52 choose N), so we have:

• 6 cards: 20,358,520 hands
• 13 cards: 635,013,559,600 hands

That's a lot. Time for a small dose of cleverness.

Abstract Hands: Suits¶

I notice that the problem says "Numbers don’t matter," so I can abstract away from cards to suits: instead of saying that the first card in this hand is the seven of spades, I can just say it is a spade. Then there are only 4^N abstract hands (for N ≤ 13), so we have:

• 6 cards: 4,096 abstract hands
• 13 cards: 67,108,864 abstract hands

That's a big improvement!

Now let's start coding. There are two red suits and two black suits, so I'll represent the four suits as 'rRbB'. I'll represent an abstract hand as a string of suits: 'rrBrbr' is a 6-card hand.

Deals: Hands and their Probabilities¶

I'll define deals(N) to return a dict of all possible abstract hands of length N, each mapped to the probability of the hand.

With actual hands, every hand has the same probability, because every card is equally likely to be the next card dealt. But with abstract hands, the probability of the next suit depends on how many cards of that suit have already been dealt. If I've already dealt the 12 cards 'rrrrrrrrrrrr', then the probability of the next card being an 'r' is 1/40, and the probability of it being a 'b' is 13/40. So as I build up the abstract hands, I'll need to keep track of the number of remaining cards of each suit.

I'll use Fraction to get exact arithmetic and lru_cache to avoid repeated computations.

Is that right? Yes it is. The probability of 'BB' is 1/17, beause the probability of the first 'B' is 13/52 or 1/4, and when we deal the second card, one 'B' is gone, so the probability is 12/51, so that simplifies to 1/4 × 12/51 = 3/51 = 1/17. The probability of 'BR' is 13/204, because the probability of the 'R' is 13/51, and 1/4 × 13/51 = 13/204.

More Abstraction: Collapsed Runs¶

Now for a second abstraction: an abstract hand can be collapsed by replacing a run of cards of the same suit with a single card, so that 'BBBBBrrrrBBBB' collapses to 'BrB'.

From now on I'll just say hand rather than abstract hand for 'BBBBBrrrrBBBB', and I'll use the term sequence (or the abbreviation seq) for the collapsed version, 'BrB'.

Properly Ordered Hands¶

A hand is considered properly ordered if "the cards of a given suit are grouped together and, if possible, such that no suited groups of the same color are adjacent." I was initially confused about the meaning of "if possible"; Matt Ginsberg confirmed it means "if it is possible to separate the colors in any number of moves", and thus that the hand 'BBBbbb' is properly ordered, because it is not possible to separate the two black suits, while 'BBBbbR' is not properly ordered, because the red card could be inserted between the two black runs.

A hand is properly ordered if and only if its collapsed sequence is properly ordered, and a sequence is properly ordered if each suit appears only once, and either all the colors are the same, or suits of the same color don't appear adjacent to each other.

Moving Cards to Make a Hand Ordered¶

I won't try to be clever here; the abstractions got us down to a small enough number of abstract hands that I can use brute force from here on. I'll say that a collapsed sequence is orderable if any of the possible moves of a block of cards makes the hand ordered. I'll find all possible moves, by finding all possible splits of the cards into a middle block of cards flanked by (possibly empty) left and right sequences; then all possible inserts of the block back into the rest of the cards. I'll define orderable_probability(N) to give the probability that a random N-card hand is orderable. Since many hands will collapse to the same sequence, I'll throw a lru_cache onto orderable so that it won't have to repeat computations.

First Answer¶

Here's the answer for 6 cards:

And an easier-to-read answer for everything up to 6 cards:

Let's make sure that each deals(N) covers everything: that I got all 4^N hands, and that the probabilities sum to 1:

Getting to N = 13: Less Brute Force¶

So far so good, but if we want to get to 13-card hands, we would have to handle 4¹³ = 67,108,864 deals, which would take a long time. But after playing with sequences for a while, I discovered two key properties that can speed things up:

1. An orderable sequence can have at most 7 runs. We know that a properly ordered hand can have at most 4 runs. But a move can reduce the number of runs by at most 3: one run can be reduced when we remove the block (if the cards on either side of the block are the same), and two more can be reduced when we re-insert the block (if the left and right ends match the surrounding suits). Here's an example of moving a block [bracketed] to reduce the number of runs from 6 to 3:

   bRB[bR]B   =>   b[bR]RBB  =   bRB
   
   

2. Adding a suit to the end of an unorderable sequence can't make it orderable. To show that, take an unordered sequence, and see what happens if you take the extra suit and insert it anywhere in the sequence. If the sequence was unordered because it repeats a suit, adding a suit can't fix that. If it was unordered because suits of the same color are adjacent, then adding a suit of the other color could fix that: 'bBR' could be fixed by inserting a 'r' to get 'brBR'. But here's the catch: 'bBR' is not unorderable. And if we are going to insert a new suit between two others, that means that the original sequence must have had at most three suits (because when we add one, we can't get more than four suits in an ordered sequence), and every three-suit sequence is orderable. And if that argument doesn't convince you, below I look at all the sequences from deals(7) (which we know is the longest length we need to look at) and show that if a sequence is not orderable, then no matter what suit you add to it, the result is not orderable:

I'll redefine deals(N) to hold only orderable hands, redefine orderable(seq) to immediately reject sequences longer than 7, and redefine orderable_probability(N) to just add up the probabilities in deals(N), since they're all orderable now.

Final Answer¶

We're finaly ready to go up to N = 13:

Caches¶

Let's look at the cache for orderable(seq):

So we looked at over a million hands, but only 1540 different collapsed sequences. And once we hit N = 7, we've seen all the sequences we're ever going to see. From N = 8 and up, almost all the computation goes into computing the probability of each hand, and collapsing the hand into a sequence, not into deciding the orderability of each sequence.

We also save a lot of space in the deals(N) caches. Instead of storing all 4¹³ hands for deals(13), the report above says that just 0.3% of the hands are orderable, so we reduced the cache size by a factor of 300.

Unit Tests¶

To gain confidence in this project, here are some unit tests. Before declaring my answers definitively correct, I would want a lot more tests, and some independent code reviews.