CardShark BidBase
Bidding Simulator

By Nelson Ford

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


Related Help Files:

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


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. BidBase is intended primarily for recording hand specifications for bids for conventions. Before specifying auctions in BidSim, you should check in the BidBase Editor to see if it contains the desired bids with the hand specifications you want.

One way is to click File - Enter Your Own Hands to enter the kind of hands you are looking for and see if the Editor gives you the desired bid.

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; whereas, if you specify a four or five rounds of bidding, it may require millions of deals just to get a couple of hundred matches, and that's assuming that BidBase has entries for such lengthy bidding sequences which most likely it does not.

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.

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.


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: "<", "=", ">"
(One 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
2:hc=K -- player 2, Heart King

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

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 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 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).

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.





In addition, I have done some simulations in response to questions raised on, 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.