Double-Dummy Analysis Problems

This document discusses problems with using Double-Dummy Analysis for computer bidding. For more background information, see the BidBase Background file.

1. It can take a very long time for the program to come up with and analyze enough sample hands to get a meaningful estimate of which bid is best. This makes playing against the program slow and boring. The alternative is to limit the amount of time it may use to "think", which speeds up the bidding, but seriously degrades the quality of the bidding because the software doesn't have enough time to generate a statistically valid number of hands which match the criteria of the bids already made.

In the May 2002 issue of Bridge World, page 47, for the bidding P-2-P-P, Dbl-P-?? and the hand QJ2 AQ743 K73 63, the magazine says that its DDA program: had a significant amount of trouble generating a sample. This translates to a very long wait for a bridge-playing game to bid this hand using DDA, not to mention that without a statistically valid sample, the results are meaningless.

2. Using randomly generated hands may not result in the same bid each time a similar hand (or even the exact same hand) comes up due to statistical anomalies in DDA, so the bidding sequence may not be repeatable. (I have personally run across this problem in trying to point out bidding errors to the publisher of GIB, which relies most heavily on DDA.)

3. The longer the bidding goes, the less accurate (and more time-consuming) DDA becomes. This is because in each random deal, the program must re-perform DDA on earlier bids in the bidding sequence which it did before to get to the current point in the bidding. The inherent inaccuracy in computing each bid is cumulative, resulting in less and less accuracy. Also, as noted in #2, above, the DDA may not get the same bid for an earlier bid, causing a valid deal to be rejected, even though the hands are virtually identical.

4. DDA does not generate bids, only hand/contract evaluations. At best, DDA can tell you what the optimum contract might be (and not even that, in every case), but it does not tell you the best bid to make to get there.

Programmers historically have used hard-coded algorithms to decide what to bid based on the DDA results.

Programs which use hard-coded algorithms, even with the use of DDA, are limited in the extent to which they can support different bidding systems and conventions. If you like to open 1NT with (14)15-17 HCP (defined as normally 15-17, but occasionally 14), but the program only supports 15-17 point NT openings, there is nothing you can do about it.

In fact, at any point in the bidding, no matter how good the DDA is, if the programmer specifies a bid to make which you don't like, or is simply a gross error, there is nothing you can do about it.

5. DDA used with hard-coded algorithms cannot remember past analysis, bids, or results. So if it takes several minutes to make a bid in a particular situation, it will take the same length of time every time it faces the same situation.

6. DDA is not reliable for high-level contracts. This falls from the next point.

7. DDA doesn't play exactly like humans would. For example, if there is a 2-way finesse, DDA will always take it the correct way. Another example, on defense, DDA can, for example, see whether or not a ruff will be forthcoming by leading a singleton, or whether it is safe to cash A-K in a suit when either partner or opener may be the one to ruff the 3rd round, etc., etc.

People have talked about creating a Single-Dummy Analyzer which would not have these problems because it wouldn't look at the cards in the other players' hands, but so far, none has been forthcoming (as of 2006).

From The Horse's Mouth...

Long after the above was written, we received a brochure advertising a bridge program by the name of Bridge Buff. Ironically, the brochure highlighted almost all of the above problems in its own program:

Bridge Buff might find another bid if it bids the same hand a different time. On some auctions, it might decide to bid, or pass, or double depending on the sample of simulated deals. The auctions are much more cluttered, the opponents more active, and some bids might seem unusual or aggressive, but most [emphasis ours] are not so goofy that you wouldn't see them in a typical matchpoint game. The bidding will not be instantaneous.

The disclosure that most bids are not so goofy means that some of them are so goofy. We appreciate the brochure's candor, but it seems a little strange to actually be advertising the quirkiness of DDA.

We should not embrace DDA's goofiness, but look for alternatives. One method is to use database lookup of hand specifications for bids. However, a lot of entries may be required to cover every possible type of hand with which you would want to make a particular bid.

An alternative is to use a hand evaluation system which takes into account many factors such as distribution, honor upgrading and downgrading, and more, rather than specifying each of these factors individually,

It should be noted that the brochure says that Bridge Buff comes with a System Builder module which lets you design your own conventions, bidding treatments, or modify Bridge Buff sequences [bids] to suit your preferences! This is a database lookup system; however, the conventions directly supported by the program still use hard-coded algorithms, for some reason. Perhaps its database structure is not robust enough to handle the job.

We have studied the bidding databases of several programs which offer them in conjunction with their hard-coded algorithms, and have found them to lack either the flexibility or the error catching necessary to make them worthwhile.

The fact is that all of these programs offer the DB lookup as an adjunct to their hard-coded algorithms. We think the proof of the DB-lookup's quality should be the programmer's willingness to put their own basic bidding systems in it rather than hard-coding them.