Computers and Bridge
By: Fred Gitelman

BASE IX informs you that both lines of play will succeed if diamonds are 3-2 and both lines of play will fail if diamonds are 5-0. BASE IX will make 3NT whenever either defender has a singleton Q. BASE IX now amazes you by stating that your line of play will never pick up any 4-1 diamond break unless either defender holds KQ doubleton or a singleton heart honour (RHO will block the diamonds and kill dummy's heart entry).

Since the odds of either opponent having a singleton Q are 5.65%, and the odds of hearts being blocked are 3.39% (not to mention that even if hearts are blocked, when diamonds 4-1 your line only works when RHO has singleton Q or Qxxx), BASE IX played the hand properly. Nicely played.

Science fiction? Maybe not. Bridge software has traditionally not been very impressive. Advances are being made. I am currently working full time on developing intelligent bridge playing software. The product described above is not yet available, but it represents the goal towards which I am working. In this article, I will discuss some of the strategies I am using and some of the problems I am facing in developing this product.

Let us first think of how an expert human bridge player solves a problem like the one above. The human expert has acquired a great deal of knowledge about bridge through study and experience. For example, a good human player would know the correct way to play the diamond suit for five tricks without even having to think about it. A good player knows the fundamental properties of most suit combinations. If he comes across a suit combination he is not familiar with, he has the means to come up with at least an approximate answer.

If this is all there is to playing a bridge hand, declarer play would be easy (and computer programs would never make an error). The concept of context is what makes declarer play such a challenging exercise. The diamond suit in the above deal can only be properly analyzed by taking into account the properties of the other three suits.

My current product, BASE III, is able to solve out-of-context suit combination problems. It can also handle some suit combination problems with limited context (for example, you can tell it how many entries exist to both hands and/or how a side suit(s) is/are known to be breaking).

In a functional sense, BASE III actually "knows" more about suit combinations than any human bridge player. BASE III actually knows only one thing about suit combinations. It knows how to solve them. It contains an algorithm, a step-by-step set of instructions, for solving these types of problems. It is never wrong. Unlike the human expert, however, BASE III does not accumulate knowledge. If it saw the same question ten times in a row, it would have to figure out the answer each time. BASE III's avdvantage in speed and accuracy compensates for its lack of permanent knowledge.

The human expert still has a huge edge. Although he does not have access to quite as much "suit information", he knows how to apply the information he does have and how it can change in the context of a hand. Although BASE III essentially "understands" each of the four suits in the current hand, it does not understand how their properties affect each other. It does not understand the entire deal. The whole seems to be greater than the sum of its parts.

Nevertheless, BASE III can be used to solve just about any declarer play problem. The process involves the user asking BASE III a lot of questions. The user has to know which questions to ask. Knowing which questions to ask amounts to having a good understanding of card play (you essentially describe the context of the hand to BASE III). I am currently working on getting BASE III to be able to ask itself the right questions. At that point, I will have created the hypothetical machine described at the beginning of this article.

BASE IX will be designed to model human bridge thinking. There are many domains of problems (besides suit combinations) that act as first principles in planning a declarer play problem. Knowledge of the end game, inferences from the bidding, calculating odds, knowledge of tactics (the holdup play, the loser-on-loser play etc.) and many other factors contribute to the "clues" needed to solve a declarer play "mystery". My product can do many of these things with great speed and accuracy. It cannot however, use the information it discovers. Maybe one day.

Many people think that a computer will never be able to play a good game of bridge. One of their most valid objections is that computers will never understand the "human side" of bridge. It is difficult to describe what exactly is meant by the "human side" of bridge. The hand we have been studying contains a good example of why bridge reasoning is not a strictly technical exercise.

Imagine you took the line of play originally suggested (A, diamond towards the J). Imagine that RHO has singleton Q or four diamonds to the Queen and that the hearts are unblocked. Will RHO always know he can beat you by returning a heart? He will have the critical diamond/heart holdings about 14% of the time. What if he goes wrong half the time? Then BASE IX's suggested line is inferior.

Several factors influence how often RHO will go wrong. His ability is the most important one. If RHO looks like he will just return his partner's suit without thinking, then you should give him a chance to make an error. If RHO is a good player, he still may not return a heart. He could have the K without the Q. From his point of view your five points in clubs and hearts could be the Q and the Q and J. In this case, not returning a spade could be fatal.

The odds of RHO making an error is at the heart of this problem (no pun intended). I would call this quantity an intangible. It is not a number that you can compute accurately. My programs have solved this problem by assuming that the defenders' never err. This is a practical, but unrealistic, solution. By 1997, BASE III may be advanced to the point that it will understand how context shapes a bridge problem. It probably still won't understand how human factors can contribute to context.