Shuffle and deal a deck of card with constraints

Question

Here is the facts first.

In the game of bridge there are 4 players named North, South, East and West.

All 52 cards are dealt with 13 cards to each player.

There is a Honour counting systems. Ace=4 points, King=3 points, Queen=2 points and Jack=1 point.

I'm creating a "Card dealer" with constraints where for example you might say that the hand dealt to north has to have exactly 5 spades and between 13 to 16 Honour counting points, the rest of the hands are random.

How do I accomplish this without affecting the "randomness" in the best way and also having effective code?

I'm coding in C# and .Net but some idea in Pseudo code would be nice!

Answer 1

Since somebody already mentioned my Deal 3.1, I'd like to point out some of the optimizations I made in that code.

First of all, to get the most flexibly constraints, I wanted to add a complete programming language to my dealer, so you could generate whole libraries of constraints with different types of evaluators and rules. I used Tcl for that language, because I was already learning it for work, and, in 1994 when Deal 0.0 was released, Tcl was the easiest language to embed inside a C application.

Second, I needed the constraint language to run fairly fast. The constraints are running deep inside the loop. Quite a lot of code in my dealer is little optimizations with lookup tables and the like.

One of the most surprising and simple optimizations was to not deal cards to a seat until a constraint is checked on that seat. For example, if you want north to match constraint A and south to match constraint B, and your constraint code is:

 match constraint A to north
 match constraint B to south

Then only when you get to the first line do you fill out the north hand. If it fails, you reject the complete deal. If it passes, next fill out the south hand and check its constraint. If it fails, throw out the entire deal. Otherwise, finish the deal and accept it.

I found this optimization when doing some profiling and noticing that most of the time was spent in the random number generator.

There is one fancy optimization, which can work in some instances, call "smart stacking."

 deal::input smartstack south balanced hcp 20 21

This generates a "factory" for the south hand which takes some time to build but which can then very quickly fill out the one hand to match this criteria. Smart stacking can only be applied to one hand per deal at a time, because of conditional probability problems. [*]

Smart stacking takes a "shape class" - in this case, "balanced," a "holding evaluator", in this case, "hcp", and a range of values for the holding evaluator. A "holding evaluator" is any evaluator which is applied to each suit and then totaled, so hcp, controls, losers, and hcp_plus_shape, etc. are all holding evalators.

For smartstacking to be effective, the holding evaluator needs to take a fairly limited set of values. How does smart stacking work? That might be a bit more than I have time to post here, but it's basically a huge set of tables.

One last comment: If you really only want this program for bidding practice, and not for simulations, a lot of these optimizations are probably unnecessary. That's because the very nature of practicing makes it unworthy of the time to practice bids that are extremely rare. So if you have a condition which only comes up once in a billion deals, you really might not want to worry about it. :)

[Edit: Add smart stacking details.]

Okay, there are exactly 8192=2^13 possible holdings in a suit. Group them by length and honor count:

 Holdings(length,points) = { set of holdings with this length and honor count }

So

 Holdings(3,7) = {AK2, AK3,...,AKT,AQJ}

and let

 h(length,points) = |Holdings(length,points)|

Now list all shapes that match your shape condition (spades=5):

 5-8-0-0
 5-7-1-0
 5-7-0-1
 ...
 5-0-0-8

Note that the collection of all possible hand shapes has size 560, so this list is not huge.

For each shape, list the ways you can get the total honor points you are looking for by listing the honor points per suit. For example,

 Shape    Points per suit
 5-4-4-0  10-3-0-0
 5-4-4-0  10-2-1-0
 5-4-4-0  10-1-2-0
 5-4-4-0  10-0-3-0
 5-4-4-0  9-4-0-0
 ...

Using our sets Holdings(length,points), we can compute the number of ways to get each of these rows. For example, for the row 5-4-4-0 10-3-0-0, you'd have:

h(5,10)*h(4,3)*h(4,0)*h(0,0)

So, pick one of these rows at random, with relative probability based on the count, and then, for each suit, choose a holding at random from the correct Holdings() set.

Obviously, the wider the range of hand shapes and points, the more rows you will need to pre-compute. A little more code, you can still do this with some cards pre-determined - if you know where the ace of spades or west's whole hand or whatever.

[*] In theory, you can solve these conditional probability issues for smart stacking with multiple hands, but the solution to the problem would make it effective only for extremely rare types of deals. That's because the number of rows in the factory's table is roughly the product of the number of rows for stacking one hand times the number of rows for stacking the other hand. Also, the h() table has to be keyed on the number of ways of dividing the n cards amongst hand 1, hand 2, and other hands, which changes the number of values from roughly 2^13 to 3^13 possible values, which is about two orders of magnitude bigger.