Double suit symbols are used in BidBase files to indicate that either of two bids is made:
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.
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.
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.
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.
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|
suit letter (c, d, h, s) or |
t for total or
"q" for "quantity" (# in suit) or|
"p" for "points" (HCPs) or
"b" for "bid" or
"c" for a specific "card"
comparison type: "<", "=", ">"|
(1 figure only. Can't have "=<", for example.)
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.
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.
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.
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
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.
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.
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:
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:
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 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 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.
"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.