What is the worth of AKQxxx?

by Matthew Kidd
December 26, 2011

In third seat at a matchpoint game I held ♠A5 74 AKQ974 ♣A93 and opened 1. Partner responded 1. Given the trick taking potential of the diamond suit and the two outside aces, 3 seemed like an underbid so I went straight for 3N which ended the auction. Dummy came down with a singleton diamond and the enemy diamonds split 1=5. On the actual defense which setup a heart in dummy, I could have made the contract by playing for a 3-3 club break and finessing against the king, a roughly 18% chance a priori. But I tried to losing a diamond to RHO late in the hand, hoping to endplay him in the black suits despite some evidence from the defense that LHO held the remaining high spade. Down two.

Partner wasn’t happy about my bidding or play. I was willing to concede on the play but I felt my 3N bid had been the percentage action. Since partner would carry on with 8+ HCP and was stylistically unlikely to respond with 5 HCP even with both majors, bidding 3N was an assertion that game was the percentage action even across from 6-7 HCP hands. Was I right?

Clearly the best hope for 3N is to take six diamond tricks. If that is possible, partner need only supply the A or a black king. But KQ, an onside K, ♣QJ, or an onside ♣Q would also work provided the defense can’t take five tricks before declarer can get nine. Failing any of these chances, partner might put down a thicket of intermediates that makes it difficult or impossible for the defense to take five tricks before declarer has nine. If a defender has four diamonds, partner will need to provide two tricks with the best hope being in clubs.

Will diamonds run?

It’s reasonable to start by asking how often partner will appear with each number of diamonds. We can do this with some high school math. Let (n,k) denote the number of different ways to choose k objects (cards) from n objects where the order of the objects is immaterial. Recall that:

(n,k) = n! / ( k! × (n-k)! )     where n! = n × (n-1) × … × 3 × 2 × 1

For example, if a suit splits 3-3, the number of different three card combinations a defender can hold is given by (6,3) = 6! / (3! × 3!) = 720 / (6 × 6) = 20.

For simplicity, first ignore the heart length implications of partner’s 1 response. Outside your hand, there are 7 diamonds and 32 non-diamonds. Partner can hold (39,13) hands. The chance of partner holding a singleton is thus:

(7,1) × (32,12) / (39,13) = 19.5%

More generally, the chance of partner holding m diamonds is:

(7,m) × (32,13-m) / (39,13)

Working out all the cases yields the following probabilities for partner’s diamond length: 4.3% (void), 19.5% (singleton), 33.3% (doubleton), 27.8% (tripleton), 12.1% (four), 2.7% (five), 0.3% (six).

If partner has a void, diamonds will not run. If partner has a singleton, the suit must break 3-3 or 4-2 if partner’s singleton is the jack. If partner has a doubleton, the suit must break 3-2 or 4-2 if partner’s doubleton is Jx, or 5-1 if partner’s doubleton is JT (rare). If partner has three, a 3-1 break is good enough, unless he has the jack in which case 4-0 is okay too. Partner might also have Txx in which case a 4-0 break can be discovered and handled if the jack is onside. But this requires an entry to dummy which is doubtful so this case will be ignored. If partner has four or more cards the suit will run. Note that the nine in AKQ9xx barely helps, picking up a 5-1 break if partner has Jx and the ten falls singleton. We’ll ignore this rare case too, treating AKQ9xx as the AKQxxx that it acts like.

The math for the previous paragraph is straightforward though a little lengthy. It is convenient to write a little program that takes a vector of probabilities p as the input and returns the probability that AKQxxx will setup for six tricks. My program is written in Matlab though it could easily be converted to C or another language. Matlab array indices are 1-based so p[1] is the probability of a void, p[2] is the probability of a singleton, etc.

Plugging our probability vector p into the code yields a 75.0% of taking six tricks with the diamond suit. This suggests 3N might be right.

What impact does partner’s 1 response have?

If we knew nothing about partner’s hand, we would play him for 3.66 (11/3) hearts on average because allowing for our two hearts there are eleven hearts among the other three hands. But since partner’s bid indicates four or more hearts, his average diamond length must drop a bit and that will hurt our chances of setting up the diamond suit.

Let’s start simple and assume partner has four hearts. This means there are 7 diamonds and 21 black cards outside your hand from which to populate the remaining 9 cards in your partner’s hand. Similar to the calculation above, the chance of partner holding a singleton diamond is:

(7,1) × (21,8) / (28,9) = 20.6%

As expected, this number has gone up slightly from 19.5% to 20.6%.

The following table is the results of performing a series of similar calculations:

Responder’s
Length
Unknown
Length
Given
4 Hearts
Given
5 Hearts
Given
6 Hearts
Given
1 Response
0 4.28 4.26 6.55 9.82 6.05
1 19.46 20.62 26.19 32.08 24.43
2 33.36 35.35 36.66 36.09 35.79
3 27.80 27.50 22.91 17.69 24.28
4 12.09 10.31 6.74 3.93 8.08
5 2.72 1.82 0.05 0.37 1.28

In principal responder could have six or seven diamonds but these cases are rare and therefore the corresponding rows are not shown; responder probably wouldn’t be bidding 1 anyhow. The final column gives responder’s percentage of holding each number of diamonds given a 1 response; it factors in the columns for seven or more hearts that are not shown in the table.

When the probabilities in the final column are fed into the program above, we find the probability of running six diamonds tricks falls to 70.0%, five percent lower than it was without the 1 response. Still the 3N bid looks promising.

The calculations were performed by another program that iterated over responder’s heart lengths to calculate the final column. It relies on the previous program. You can vary the number of hearts held by opener though it barely changes the result.

Careful readers may notice that the code as written rolls in cases where responder’s spades are longer than his 4+ hearts. Since responder would reply 1♠, those cases should properly be excluded. This is possible with more programming but it will not significantly change the result.

Running diamonds is not enough

If the result had been under 50% I could concede. But since dummy must also provide a trick and declarer must get it before the defense takes five tricks, the 70% chance of scoring six diamond tricks is too close to 50% to claim clear victory.

To get further we must leave the world of closed form calculations and switch to Monte Carlo style simulations followed by double dummy analysis. The idea is to deal out a collection of hands where the declarer’s hand is fixed and responder’s hand has 6-7 HCP and a 1 response. Then calculate the double dummy result for 3N with LHO on lead for each deal and see what percentage of the time 3N makes. A thousand deals should give reasonable confidence in the answer, say within a couple of percent.

There are multiple dealing programs but if you are serious about simulation you’ll eventually turn to Thomas Andrews’ Deal program despite the steep learning curve. To get the most out of it you need to learn some Tcl programming but you can get by with relatively little knowledge of the language.

The Tcl program defines the criterion for acceptable deals. We’ll fix opener’s hand and define responder’s hand as having 6-7 HCP, at least four hearts, hearts at least as long as spades, and fewer than six diamonds, reasonable criterion for a 1 response. The Deal program does not understand any bidding systems; instead you must define the bids in terms of strength, suit length, and hand patterns. The program has many internal optimizations that prevent it from wasting time generating random deals that can not possibly meet your criterion.

If we name our Tcl program akqxxx.tcl, the following command line will generate a 1000 deals and save them to a file called akqxxx1000.txt:

deal -l -i akqxxx.tcl 1000 > akqxxx.txt

This command executes very fast. The first few lines of the output file look like:

T2 QJT2 J83 QT54|98764 A953 T6 K7|A5 74 AKQ974 A93|KQJ3 K86 52 J862 8762 AQ963 JT53 |KJT3 K85 6 JT654|A5 74 AKQ974 A93|Q94 JT2 82 KQ872 QJT KT852 J82 87|8762 J93 63 QJ64|A5 74 AKQ974 A93|K943 AQ6 T5 KT52 87 AJ532 86 QT42|QJ964 QT98 T5 87|A5 74 AKQ974 A93|KT32 K6 J32 KJ65

Here the order of the hands on each row is North, East, South, West, i.e. responder, RHO, opener, LHO. The format is close to the Ginsberg’s Intelligent Bridgeplayer (GIB) format that is often used as input to double dummy solvers and also to record the double dummy results. To fix it we need to convert spaces to periods, and then the vertical bars (pipe symbol) to spaces. This can easily be done with a text editor, a simple program, or even the Unix sed command. For example:

sed -e "s/ /./g" akqxxx1000.txt | sed -e "s/|/ /g" > akqxxx1000.gib

The first few lines of the output akqxxx1000.gib look like:

T2.QJT2.J83.QT54 98764.A953.T6.K7 A5.74.AKQ974.A93 KQJ3.K86.52.J862 8762.AQ963.JT53. KJT3.K85.6.JT654 A5.74.AKQ974.A93 Q94.JT2.82.KQ872 QJT.KT852.J82.87 8762.J93.63.QJ64 A5.74.AKQ974.A93 K943.AQ6.T5.KT52 87.AJ532.86.QT42 QJ964.QT98.T5.87 A5.74.AKQ974.A93 KT32.K6.J32.KJ65 T9.AKT953.862.T7 KQ87632..J.J8542 A5.74.AKQ974.A93 J4.QJ862.T53.KQ6

Now we are ready to perform double dummy analysis. I used ddd, PM Cronje’s command line interface to Bo Haglund’s open source double dummy solver library. Bo Haglund’s fast double dummy library provides double dummy analysis for many popular programs, including ACBLmerge, BridgeComposer, and later versions of DealMaster Pro. On Windows, I had to compile ddd myself; on Linux it is available via the dds package, a slightly different name because the name ddd was already used by another package.

The ddd readme.txt and command line help are a bit confusing. If you want the double dummy result for each combination of denomination and seat for each deal, the following command line will do it:

ddd akqxxx1000.gib -giblib=1-3-all > akqxxx1000.solve.txt

This is how ACBLmerge uses ddd, after which it extracts the lines that look like:

tricks=53537777666633335353 (max=13)

where the black, blue, red, orange, green groups respectively are the number of tricks N-S can take in no trump, spade, heart, diamond, and club contracts respectively, when the lead is in each of the four seats.

But the double dummy analysis is fastest if limited to a particular contract by a particular seat. This command does the job for a single deal:

ddd akqxxx1000.gib -leader=s -trumps=n -sol=1 -deal=1 > akqxxx1000.solve.txt

The opening leader specified by the red command line switch look wrong. It turns out that the ddd program expects the hands to be in the order West, North, East, South. One can either handle this by further editing the GIB or by using it as is and rotating the opening leader a quarter turn counter-clockwise.

The output of the previous command is shown below. We are interested in the 5 shown in red, which indicates that N-S can take 5 tricks double dummy. The H 6 means the 6 is a lead that will achieve the optimal result. There may be other leads that also achieve the double dummy result but they will not be shown unless we set -sol=2, a slower program mode.

Double Dummy Driver (DDD) version 1.05 (25-Jan-2007) =========================================================================== deal: T2.QJT2.J83.QT54 98764.A953.T6.K7 A5.74.AKQ974.A93 KQJ3.K86.52.J862 tricks: ---- ---- ---- ---- ---- leader: S 9 8 7 6 4 A 9 5 3 T 6 K 7 T 2 A 5 Q J T 2 7 4 J 8 3 A K Q 9 7 4 Q T 5 4 A 9 3 K Q J 3 K 8 6 5 2 J 8 6 2 contract:notrump play:S -- sb completed: nodes=1,284 tgt=-1 sol=1 alt=1 elapsed=0.02 5: H 6

Rather irritatingly, ddd does not provide a way to loop over all the deals when the goal is to only compute the double dummy result for a single denomination and/or opening leader. This can be fixed with a driver program such as the one below which is written in Perl. While we are at it, the Perl program might as well tally up how often each number of tricks appears as the double dummy result.

For our case the Perl script is invoked as:

perl ddd.pl akqxxx1000.gib -l s -t n

with the following result:

Tricks Count 0 4 1 4 2 20 3 173 4 425 5 270 6 71 7 29 8 4 Total time: 2 min 40 sec

3N makes when the defense takes not more than four tricks, i.e. the green rows. In aggregate this is 626 of 1000 cases, or about 63% of the time. Our initial 70% guesstimate based on how often diamonds will run is holding up pretty well. 3N is shown to be the percentage bid.

The double dummy analysis required less than three minutes. That’s not bad. It would be practical to run a 10,000 hand simulation. And this result is from an older single-core laptop. Double dummy analysis scales well on multi-core machines and Bo Haglund has since improved his DDS library to take full advantage of multiple cores in addition to making other performance enhancements. Unfortunately DDD has not yet been updated to interface with the 2.x.x DDS versions which have multi-core support.

The Extra Trick Factor (ETF)

Real play does not always match the double dummy result because in part real players do not see all four hands. The double dummy result may well rely on dropping a singleton offside king, taking a deep finesse, playing for an anti-percentage endplay and so on. And double dummy, no one ever misguesses a two way finesse. But over a large enough number of deals, these quirks tend to cancel out between the defense and offense.

However there is still an important bias in favor of declarer because defense is harder than declarer play. Over the long haul if declarer’s result is compared the double dummy result, declarer will come out some fraction of a trick better on average. Ted Muller calls this the Extra Trick Factor (ETF). He claims his ETF is 0.41 tricks which is believable for a Diamond Life Master. Let’s be more modest and assume an ETF of 0.2 tricks. This means about 20% of the 270 double dummy down one results above will be made in practice. So the 3N bid might be more like a 68% chance.

Did I tell you LHO made a takeout double of 1?

When I played the hand, I didn’t remember LHO getting into the auction. My partner isn’t 100% sure either. But looking at LHO’s hand, ♠KQ97 AK932 T ♣K64, it’s hard to believe he passed. Since he didn’t overcall 1, he must have made a takeout double.

How does the takeout double affect your chances in 3N? Off the top it looks both good and bad. Good, because on average partner will have more diamonds for you; bad because the suit will break poorly more often.

To simulate this new auction we need a more sophisticated Tcl script for the Deal program.

It’s hard to define a takeout double exactly because styles vary. But let’s assume LHO will only consider making a takeout double with two or fewer diamonds, at least three cards in every other suit, and 13+ points where the points consist of HCP added to “dummy points” where a void=5, a singleton=3, and a doubleton=1. Moreover, assume that with 5-3 in the majors, LHO will overcall a major instead, and that with 3-3 in the majors, LHO will overcall a club or pass. The new code to implement these criterion is shown in blue. In principle LHO may also double to show a hand that is too strong for an overcall. This case is unlikely here and is not considered.

After this change, things proceed as before with this result:

Tricks Count 0 4 1 5 2 35 3 164 4 447 5 283 6 51 7 10 8 1 Total time: 3 min 01 sec

This time declarer makes 3N in 655 out of 1000 cases or 65% of the time, almost 3% better than without the takeout double. Allowing for the same 0.20 ETF, declarer should make 3N about 71% of the time in practice.

This improvement surprised me. Overall I had expected the takeout double to hurt declarer’s chance. But now I think I missed something. Dummy is likely to have a queen or two and their value is significantly enhanced if the kings are with LHO which is much more likely if LHO has the values for a takeout double. Even if declarer does not have an entry to score the queen directly, their presence may still serve to endplay LHO or at least freeze a suit or two so that declarer has more time to do his business, e.g. work on diamonds if they split poorly.

Final notes

It is possible to do the double dummy calculation and trick tallying from with the Deal program. However, this would involve more Tcl programming than I care to learn. Nevertheless, it may be a good approach.

The deals I used for the two simulations and the related programs are available for download in one ZIP archive.