CardShark BidBase
Bidding Simulator

By Nelson Ford

Hold Shift while clicking on a link
to view linked file in a new window.

Contents:


Related Help Files:

Note:
Double suit symbols are used in BidBase files to indicate that either of two bids is made:
= Diamonds or Clubs.
= Hearts or Spades.



Introduction

The CardShark BidBase Bidding Simulator, or BidSim for short, generates random deals, looking for deals which match specifications which you have entered in the Specifications grid.

When BidSim finds a matching deal, it uses BidBase to bid the hands. At present, bidding is limited to two rounds, and at this time, only one round of bidding is in BidBase, so unless you make entries for the second round of bidding, it would be pointless to specify a second round of bids (unless you start with 2 or 3 passes).

When a deal matches the specs and bids in the Specifications grid, BidSim then analyzes the hands and increments the counters where matches are found to your entries in the Count grid.

Maximum Deals & Matches

Entering maximums is a way to control the time the program takes to run a simulation. And of course, without maximums, the program would just run the sim forever.

Experience has shown that 1000 matching deals is an adequate sample size, and even as few as a couple of hundred may do. If you find that a simulation runs quickly, you might want to up the maximum matches to see if it increases the accuracy.

The longer the sequence of bids you specify, the more deals must be generated to find deals with hands which match those bids. For example, if you specify only that player 1 must open 1C, you could get 1000 matching deals in a few minutes or less; whereas, if you specify a full round of bidding, it may require 20 million deals just to get a hundred or two matches, and that's for fairly normal types of bids (e.g.: 1C-Dbl-1H-1S). For oddball bidding, BidSim may have to run overnight or longer.

Entering a specific hand for even one player greatly reduces the amount of time required to find matching hands.

Suit Lengths & HCPs

The primary purpose of specifying suit lengths and HCPs is to eliminate non-matching entries without having to go through the more time-consuming bidding routines. For example, if you specify only that the hands must be such as to match the bidding 1C-P-2H, it will take BidSim quite a bit of time to find a large number of matching deals, but if you also specify that player 3 must have 6 Hearts, then BidSim can quickly eliminate deals in which player 3 does not have 6 Hearts, going to the bidding routines only for the hands which do.

On the other hand, you have to be careful in your specifications. If you require an opening bid of 1H, but say to screen out hands without 5+ Hearts, you'll miss hands which BidBase might open 1H with only 4 cards, such as 32-AKQT-KJ432-32.

Suit specifications can be entered in the Hand/Suit Specifications (top) grid or in the Specify Data To Count (bottom) grid, depending on what it is you are trying to count.

If you want to know how often the program will make a certain bid given a hand of certain specifications, enter the suit specifications in the top grid and the bid to count in the bottom grid and vice-versa if, instead, you want to know how often a program will have a certain distribution given a certain set of bids

Suit Length and HCP specifications can be entered as 6+, <10, and 5-9.

The last HCP column is for total HCPs for the hand, preceded by columns for HCPs for each suit.

Bids

The last two columns are for up to 2 full rounds of bidding. (But see comments above about how bid specs make it harder and longer to generate matching deals.)

You can enter all bids in a sequence, such as 1C-P-1H, but if you wish, you can substitute "?" for any position where any bid would be acceptable, such as 1C-?-5C. You can also use "x" to indicate "any suit" at a specified level, such as 1C-1x-1N.

Count Specifications

The Count grid is where you say what you want counted.
An entry must be exactly this format:

1st two characters:
player number 1-4 followed by a colon
3rd character:
suit letter (c, d, h, s) or
t for total or
4th character:
"q" for "quantity" (# in suit) or
"p" for "points" (HCPs) or
"b" for "bid" or
"c" for a specific "card"
5th character:
comparison type: "<", "=", ">"
(1 figure only. Can't have "=<", for example.)
6th+ characters:
number or bid. A number must be a specific number
rather than the usual variables or range of numbers.
For example, rather than "2:hq=6+", enter "2:hq>5".
To enter a range like 5-7, enter "2:hq>4" AND "2:hq<8".

In the image below are 4 specs for hand 3 (overcaller's LHO) and 8 for partner.
The first one, 3:sp>6 AND 3:sq<3, means LHO having more than 6 HCPs in Spades and less than 3 Spades.

More Examples:
2:hq>4 -- player 2, more than 4 Hearts
3:sp<5 -- player 3, less than 5 HCPs in Spades
1:tp>10 -- player 1, more than 10 total HCPs
4:b1=1H -- player 4, first bid of 1H
2:hc=K -- player 2, Heart King

The next-to-last line above (4:b1=1H) is used to count different bids a player might make when no bid has been entered for him in the Specifications grid. For the line above, you might have entered bidding of 1C-D-P, wanting to know the frequency with which responder to a takeout double makes various bids.

The last line (2:hc=K) lets you count specific cards; in this example, the Heart King.

The "And" columns are for making compound Count specifications. For example, after bidding of 1C-Dbl-P, you may want to count the number of hands in which doubler's partner has both the number of Clubs and HCPs in Clubs to justify a penalty pass of the take-out double. To get this count, you would enter "4cq>5" AND "4cp>4", looking for hands in which player 4 has more than 5 Clubs and more than 4 points in Clubs.

If you put these two specs on separate lines instead of the same line, you would get a count of hands with Clubs >5 -or- Clubs with 4+ HCPs.

Likewise, if you want to know, in the last example, how often advancer will have 4+ Hearts OR 4+ Spades, enter "4hq>4" on one line and "4sq>4" on the next line; don't put them on the same line.

# Found & Percent

As the simulation is running, the "# Found" column will be constantly updated. When the run is done or stopped, the "Percent" column will be calculated and displayed.

The Percent is calculated by dividing the count for each line in the bottom grid by the total number of hands matching the specs in the top grid. This tells you the odds of getting whatever you are counting, given the hand and deal specifications you entered.

Other ways of calculating percentages may also be of interest, but you will have to calculate them manually. I tried to give an example here, but it became too complicated for what is a simple situation, so just wing it.

Log Files

Use the check boxes at the bottom of the screen to generate log files. The Matching Deals log is a list of deals which matched the general specifications in the top grid, but did not match the bidding. The actual bid made for a hand is shown beside the hand. Looking over this list is a good way to spot hands for which the entries in BidBase are not resulting in a desired bid.

If you wish, edit the entries as necessary in the BidBase Editor, then use the Enter Hand function (Ctrl-Y) to enter the same hand and see if the desired bid comes up for it. Repeat the procedure until satisfied.

The Hands Counted log is a list of deals which met the bidding specs, as well as one or more of the specification lines in the Count grid.

The *.Sim and *.Log files are saved in the Sim subfolder in the main BidBase folder. The Log files are automatically loaded into the BidBase File Viewer when the simulation has completed running or when you click Abort

Save/Load Sim Files

After entering the specs for a simulation and before running it, you may wish to save it, although this is optional. If you want to create Log files, you definitely must save first so that the program has a file name to use for the Log files. Log file names are created by adding _hands_counted.txt or _matching_hands.txt to the .Sim file name.

After you run a simulation, you can save the Sim again and it will also save the results. The next time you load the Sim, it will also load and display the results. If you wish to run the Sim starting from those results, click the Continue button. To start from scratch, click the Run Sim button.

Run, Abort, Continue Buttons

After you have entered specs for a sim, click the Run Sim button. While it is running, you can stop it at any time by clicking Abort. The Abort button will change to Continue. To continue building on the same results, click Continue. However, if you add or change any of the specs, you must start the sim over by clicking Run Sim.

Any time you stop a run and want to start it with fresh counts, even if you didn't change anything, just click the Run Sim button rather than the Continue button.

The Art Of Simulations

A simulation is only as good or meaningful as a person's ability to design the specifications and to interpret the results.

For example, a discussion on rec.games.bridge involved a player with AJT32-AT92-Q-T32 hearing his RHO open 1D. He asked whether to overcall 1S or to make a takeout double.

I ran a sim with those specs and counted player 4's number ("quantity") of Spades, Hearts, Diamonds, and Clubs as well as the number of times he got 6+ Diamonds with 6+ HCPs.

The results were as follows:

    Number of deals: 15251
    Number of matches: 2000

    4:sq<3 = 747 times or 37%
    4:sq=3 = 683 times or 35%
    4:sq>3 = 570 times or 28%
    4:hq<4 = 1224 times or 61%
    4:hq=4 = 485 times or 24%
    4:hq>4 = 290 times or 14%
    4:dq=5 = 300 times or 15%
    4:dq>5 = 105 times or 5%
    4:dq>5 AND 4:dp>5 = 8 times or 0%
    4:cq<5 = 1645 times or 82%
    4:cq=5 = 252 times or 12%
    4:cq>5 = 102 times or 5%
First, notice that it only took 15,251 deals to find 2,000 matching hands. This is a result of having specified the exact cards for one hand. Without this, it would have taken about 2 million deals!

Second, notice that the first 3 lines, which count various Spade holdings, total 2000 -- equal to the total number of matching hands. That is because the specs cover every possible Spade holding, so each deal matching the parameters in the Specs grid had to have one of the Spade holdings listed.

The same is true for Heart holdings, but look about half way down the list, starting with "4:dq=5". The entries which count Diamonds only total 405. That is because not all possible Diamond holdings are counted. Missing is "4:dq<5". If you wish you can simply subtract 405 from 2000 to find out how many times player 4 has <5 Diamonds.

Third, look at how I almost screwed up the interpretation of these results:

  • It looked like if you overcall 1S, pard will have 3+ Spades for an 8-card fit 63% of the time
    (35% for exactly 3 plus 28% for more than 3), and

  • If you double, partner will bid you to an 8+ card fit 83% of the time via 1H (38% for 4+ Hearts),
    1S (28% for 4+ Spades) or 2D (17% for 5+ Dimaonds and

  • Thus you should double (83% chance of a fit) rather than overcall 1S (63% chance of a fit).
Wrong!!

Upon further reflection, I realized that there is overlap that I had not counted where responder has 4+ Spades as well as 4+ Hearts, or Spades and Diamonds, or Hearts and Diamonds, meaning that I was overcounting the number of DIFFERENT hands where a fit would be available after a TOX.

To adjust for this, I ran the sim again, adding the following Counts:

    1). 4:sq=4 AND 4:hq=4 AND 4:dq=5
    2). 4:sq>3 AND 4:hq>3 AND 4:dq<5
    3). 4:sq>3 AND 4:hq<4 AND 4:dq>4
    4). 4:sq<4 AND 4:hq>3 AND 4:dq>4

#1 counts 4-4-5-void
#2 counts 4-4+ majors. Note that if "4:dq<5" were not added, you could double-count the 4-4-5-void hands.
#3 counts hands with 4+ Spades and 5+ Diamonds. Again, "4:hq<4" is added to prevent double-counts.
#4 counts hands with 4+ Hearts and 5+ Diamonds with "4:sq<4" added to prevent double-counts.

Then I subtracted these percentages from the 74% that I originally calculated for a fit after a TOX. When I did this, that percentage dropped all the way down to 28%.

So then did I have an analysis to be proud of? Not really. I had a count of fits and non-fits, but no idea how often advancer might actually have to bid them. That depends in part on what advancer's RHO bids.

A better approach would be to specify bidding of 1D-D-?-? and 1D-1S-?-? and count the actual bids made by advancer over various bids by his RHO, and count how many of those result in 8+ card fits.

When I did this, I got the following results. The "TOX" column are results after player 2 makes a takeout double. The "1S" column is when player 2 bids one Spade.

Specs:

3:b1=Any
3:b1=P
3:b1=D
3:b1=R
4:b1=1S
4:b1=1H
4:b1=1N
4:b1=2C
4:b1=2D
4:b1=2H
4:b1=2S
4:b1=2N
4:b1=3C
4:tb>3C
4:b1=P
4:b1=D
4:b1=R
Over
TOX

38%
27%
---
10%
6%
7%
2%
8%
4%
10%
2%
1%
1%
6%
47%
2%
---
Over
1S  

64%
54%
9%
---
---
---
1%
5%
1%
17%
2%
2%
1%
25%
41%
1%
0%

In addition, I have done some simulations in response to questions raised on rec.games.bridge, but pretty much posted the results without comment because I wasn't sure how to interpret them.

Despite all this, I think that a bid simulator is an extremely useful device for analyzing bids. Experts tend to have opinions about what works based on a lifetime of experience. While such experience is extremely valuable, it can easily be proven that this approach to evaluating bidding alternatives is not foolproof. That proof is that very, very little bidding theory is agreed on by all experts. Since they all should have had similar experience over the long decades of play each has had, if experience were the best teacher, the pro's would have all learned the same lessons and come up with the same conclusions.


"Logic" versus "Judgment"

"Judgment", "gut feeling", and "instinct" are all the same thing, and we tend to think of this as being the opposite of "logic" performed consciously, but the fact is that it is ALL logic, even when done subconsciously.

If judgment, etc., were not logic carried out by the subsconsious, then it would just be random thoughts with no connection to the conclusion arrived at.

The advantage to logic performed on a conscious level is that you are aware of the steps you have gone through and if any of those steps can be shown to be faulty or can otherwise be improved upon, then it should be easy for the "logician" to accept changes to what they believed to be true.

Since by definitions, those relying on logic performed on a subconscious level are NOT aware of all the indiviual steps in the thinking process, they are less able to accept changes to the process and thus are not as open to having their minds changed.

Unfortunately, conscious logic is not always correct. All logic is only as good as the "facts" that go into it. So if a logician is wrong and the subsconscious-logic ("gut") thinker is right, it is difficult, if not actually impossible, for the gut thinker to convince the logician because the gut thinker can't really say WHY he believes what he does.

The logician may actually be able to present arguments to the gut thinker which seem logically sound and gets frustrated when the gut thinker won't accept them while the gut thinker gets frustrated and even angry because he may strongly believe he is right but since, by definition, he is not not aware of the subconscious logic leading to his belief, he has no way of refuting the logician's arguments.

Applying this to bridge judgment: the most expert of bridge experts say that they "know" based on many years of experience what to bid in certain situations, but would rebel if asked to translate the subconsious knowledge into quantifiable data which could be used in a bidding database.

Experts would argue against hard-and-fast rules about what to bid in certain situations, saying that you just have to use your judgment. Part of the problem is that there is often not just one absolute best bid for any situation. This can be seen in bidding panels where experts disagree about what to bid. That is why in BidBase, we allow entering a % for an entry so that the same criteria can result in alternative bids.