The contents of this file are in the same order as the
Input Boxes at the bottom of the BidBase Editor screen.
are used to indicate that either of two bids can be made:
= Diamonds or Clubs.
= Hearts or Spades.
Links to web pages for more information are sometimes given, followed by an archived page link, similar to the way Google does. The purpose is to provide the web link to the site of the person who created the page, but also to provide a backup to a local copy of the page in case the original link is no longer valid.
To be able to define any convention in a database, you must be able to enter all the criteria, such as points and distribution, which a hand must meet to make a specific bid. For example, to reply 1 to an opening bid of 1, a hand might be required to have 6+ points and 4+ Spades, but you cannot just make one entry with those specifications (a.k.a.: "specs").
Many hands will come up which have 4+ Spades and 6+ points, but with which you will not want to simply bid 1. For example, with 6-9 HCPs and 3+ Hearts, you are too weak to bid a new suit; you should just raise partner's Hearts.
For each of these different types of holdings, we must have entries to state more specific criteria. And each of those entries will have exceptions to their specs which also require other entries.
BidBase has a lot of different spec fields for defining entries because we considered it better to have too many than not enough. The more spec fields, the better able you are to define a bid, and you can always ignore the ones you don't need. The vast majority of entries need only the HCPs and some suit specs (in addition to the entry identifying and disclosure fields).
Some of the fields allow you to specify the same requirements in slightly different ways. For example, in addition to High Card Points ("HCPs"), the quality of the points in a hand can be specified using KNR Points, Custom Points (e.g.: 6-4-2-1, A=2,K=1, etc.), Winners, Quick Tricks, Suits Stopped (total or by suit), Intermediates (total or by suit), and by entering specific HCP requirements for each suit, the latter of which allows you to specify for each suit a range of points, # of stoppers, first or second round control, and more.
Another example is specifying the distribution of the hand by entering distribution points required or the number of cards by suit or any of the alternatives in the Shape drop-down list.
Obviously, you do not have to enter the same information in each of these alternative fields. Which ones you use depend on exactly what you are trying to require. Or if you are a casual user, you can use whichever field(s) you understand best, which is usually HCPs for the hand and by suit.
In later rounds of bidding, you do not have to (but you can if you wish) respecify the same specs you entered for a hand for an earlier bid in the Prior Bids. For example, if an entry for the first-round bid for a hand specifies 2.5 Quick Tricks, you do not have to specify 2.5 Quick Tricks in bidding specs for the same hand for subsequent rounds after making that first-round bid.
But the bottom line is that you only have to enter data in the fields you wish/need to, so an entry can be made pretty quickly. Also, we have done everything we could to make entering bids and specs as fast and efficient as possible. There are also many features designed to insure that the data entered is correct.
Following are the criteria which a hand may be required to meet in order to use the current entry to make a bid. Also included are fields which are not hand requirements, but are present to further describe the entry for a player or to make the database easier for a user to edit. Examples are the Convention Name and Disclosure fields.
The fields are discussed below in the order of the input boxes at the bottom of the screen.
(Cnv, Sub and Pct):
All bids, conventions, etc., in BidBase are stored in a single database. You select the ones you wish to use and deselect the others.
There are three levels for selecting which entries will be used in bidding and which are deactivated. Leave all three of these fields blank to use an entry, or enter "0" in any of them to deselect it.
First you have the root Convention Names, such as Splinter for showing a singleton or void or 2C Strong for a forcing opening bid (as opposed to Precision, for example).
Next comes subcategories , such as Splinter in "2C Strong: Splinter" or in "2C Strong: 2D Waiting: Splinter". Notice that while 2D Waiting is a subcategory specific to 2C Strong, a Splinter can be a convention by itself or a subcategory to other conventions.
For example, the entry for 1S-P-4C is identified as a Splinter, while 2C-P-2D-P-2H-P-4D is 2C Strong: 2D Waiting: Splinter.
Let's say you have the following conventions and subcategories with Precision deselected (by putting "0" in its convention name field):
||Strong 2C: 2D Waiting
||Strong 2C: 2D Waiting: Splinter
If you de-select Splinter, which is not part of SAYC, you end up with:
||Strong 2C: 2D Waiting
||Strong 2C: 2D Waiting: Splinter
If you select Precision by removing the "0" from its Cnv field and deselect Strong 2C, you would have:
||Strong 2C: 2D Waiting
||Strong 2C: 2D Waiting: Splinter
Note that you can deselect individual subcategories via the Subcategory selection field.
Also note that when you deselect 2C Strong via the Cnv field, all 2C Strong subcategories are deselected, even though their individual Sub fields do not change. This allows you to select and deselect whole conventions without losing your preferences for treatment of the individual subcategories.
The final method for selecting bids is the Pct.Used field. This lets you choose among alternative bids for the same situation within a convention or subconvention.
For example, say that for opening 2N Balanced: 2 Doubletons, we have three alternative entries which specify --
- Both doubletons are stopped, or
- At least one doubleton is stopped, or
- Neither doubleton is stopped.
To select which alternative to use, you could set up a subcategory for each option, such as
Then you could assign the appropriate subcategory to each of the three entries and use the Sub field to select which entry to use.
- 2N Balanced: 2 Doubletons: Both Stopped,
- 2N Balanced: 2 Doubletons: One Stopped and
- 2N Balanced: 2 Doubletons: Neither Stopped.
However, the main reason for setting up Bid Names and subcategories is to be able to select and deselect an option throughout the database with a single click. In this case, you will probably have only one entry for each of these, so it is easier just to use the Pct field than to set up several new subcategories.
So if you want to use #1, above, leave its Pct field blank and put "0" in the Pct field of the other two entries.
The use of the Pct field will be discussed in more detail below.
The following codes can be used for Cnv, Sub, and Pct:
- W indicates that We are using this option, but not the opponents.
- T in this field indicates that the opponents (They) are using this bid, but not us.
- When the field is left blank, it indicates that both sides are using the bid.
- When the field has a "0" (zero) in it, it means that neither side is using the bid.
In addition to the codes above, the Pct field accepts the following codes:
NOTE: Up to 3 codes can be entered in the Pct field. For example, if an entry is for use only when using IMPs scoring, but you wish to deactivate it, you would need to enter "0I".
M indicates an entry to be used only for MatchPoints, not IMPs. (If link doesn't work, see the archived page.)
I (as in IMPs) says the entry is for IMPs only.
D indicates a Double Dummy Analysis ("DDA") entry. When a bid is not found in BidBase matching a particular hand's specs, DDA is used to determine the best contract based on bidding by all players plus the current player's actual cards.
However, while DDA may determine the best contract, DDA does not actually make bids. To find the bid to make, after DDA is done, another call to BidBase looks for an entry with D in the Pct field whose Best Contract field matches DDA's.
If no DDA entry is found for the DDA contract, then the DDA will bid whatever contract it computed as being best. Example: If the bidding is 1S-P-2S-P and DDA determines that 4S is the best contract, it will just bid 4S if no DDA entry is found with 4S in the Best Contract field and some other bid specified.
A number from 1 to 99 in the Pct field can be used to randomly make different bids with hands of the same criteria.
For example, bridge magazines have panels of experts who each vote on the best bid in a particular situation. The fact that they frequently disagree indicates that there is often more than one good bid available, so you could create entries for the two alternative bids and give each a 50% use factor, or 80%-20%, or three alternative entries with 60-20-20 or whatever percents you wish (as long as they add up to 100%).
You could also put in psychic bids with a low percentage such as 1%. For example, if you might sometime psych by opening 1 with a hand like Q5432 2 6532 432, then you could make such an entry and put 1 in the Pct field. This doesn't mean that you will psyche an opening bid 1% of the time, only 1% of the time that you get this specific hand type.
If you want to disable an entry which uses a Pct, put an "x" before the number. This allows you to retain the percentage rather than replacing it with a zero so that when you do want to use it, you can simply remove the "x".
R (Bidding Round #):
The Bidding Round Number starts with the first non-passing bid and can be only one digit. This limits you to 9 rounds of bidding (1-9), but that already goes well beyond the intended scope of BidBase.
Ignoring beginning passes holds down the size of the database and for most bids, a player's being a passed hand does not affect the bidding. If it does affect the bidding, there is a field to specify if the bidder is a passed hand or not.
For example, if you are a passed hand and your partner opens 1N, all of your responses will have the same meaning as if you were NOT a passed hand. But if partner opens 1C, a response by you of 2H will have one meaning if you are a passed and another meaning if you are unpassed, in which case you should use the Position field to show which entry is for a passed or unpassed hand.
P (Player #):
The Player field is the number of the player, 1-4, starting with the first non-passing player. If being a passed hand is a factor in making a bid, you can specify that in the Position field (discussed later).
THIS IS CONFUSING. Sorry, but it is necessary. The next section will explain why.
The technically correct terminology is "Prior Calls". Only calls of some number of a suit or notrump are "Bids". Thus Pass, Double, and Redouble are "Calls", not "Bids". But since most people use "Bids" to refer to all Calls, so will I. (I don't remember ever hearing anyone ask "What did you Call?")
Bids are indicated by the bidding level number followed by the first letter of the suit bid, such as 1H. For BidBase database purposes, N is used for a notrump bid, such as 1N, rather than the commonly used 1NT. Likewise, P = Pass, D = Double, and R = Redouble. If you enter Double or Dbl, neither would be recognized by the program, only D. (While we're on the subject, BidBase uses "T" for the Ten card, not "10'. To me, JT73 is more readable than J1073.
In the Prior Bids field, all Bids/Calls are separated by dashes ("-").
Any time you are required to enter a set of Prior Bids, the program provides these shortcuts and aids:
- Letters, such as suits, are automatically uppercased.
- Pressing the space bar inserts a dash ("-").
- Invalid letters and numbers are not accepted.
Prior Bids start with the first non-passing call. For example, whether the real bidding has gone
the Prior Bids field would simply be "1C". The initial passes are ignored (except when entering a hand and bidding for which you wish to find a bid in BidBase, in which case something like P-P-1H is okay).
Pass-1C, or just
Ignoring beginning passes allows us to cut the number of entries in the database by about 75% since for most bids, it doesn't matter if the first non-passing call is made in 1st, 2nd, 3rd, or 4th seat. For the times that it may matter, such as whether or not to bid Drury when partner has opened in 3rd seat, you can indicate the opening bidder's position in the Position field.
Here is how the Prior Bid field is used by the BidBase Bidding module:
||Lets say that the bidding has gone "1C-1S" and now it is the 3rd player's bid.
||The bridge program passes over to BidBase the hand (e.g.: AQ3 T87 K6432 T4), the Prior bids (1C-1S, in this example), and other game criteria.
||BidBase looks at the first entry (in bid number order) with prior bids of "1C-1S".
||BidBase then examines the hand criteria (points, etc.) for that bid to see if it matches the current hand.
||If it matches, BidBase passes back to the bridge program the selected entry's bid, along with any disclosures to be made to the other players (human or the bridge program's computer players).
||If the hand's specs do not match the first entry's specs, BidBase looks at the next bid in the database with the same prior bids of 1C-1S. If there is one, then the program reverts to step 4.
||Few entries specifying a call of "P" (Pass) are in BidBase, and those few are just for when we want to be certain that the calling bridge program passes rather than coming up with another bid. If there are no more entries, including a passing bid, a blank entry would be passed back to the bridge-playing program which can then use its own methods, such as double-dummy analysis, to determine if/what it should bid. However, if BidBase finds a matching entry with "P" as its bid, the calling program should pass. Only if no bid is returned should the calling program keep trying.
In the first round, a blank should normally result in a Pass since all except the most freakish hands should be covered in BidBase for the first round of bidding. Once bidding has gone past the first couple of rounds, fewer bids will be found in the database. This is because the purpose of the database is to provide support for any and all bidding agreements (conventions and systems).
There are over 125 trillion, trillion, trillion possible unique bidding sequences. Regular partnerships have at most a few dozen bidding agreements. At the outset, this database is only designed to cover the latter group. However, it seems inevitable that the longer the database is in use in the world, more and more entries will be added to it, both by users and by double-dummy analyzers, so that eventually, bidding done by the database will become much more extensive and not just for conventions.
Prior Bid Sort Order:
(The following is technical information which needs to be documented, but is not needed by users of the program unless you see entries not correctly grouped by Prior Bids. That should never happen, but if it does, see the last paragraph in this section; otherwise, you can skip to the next section.)
When sorting the database by Prior_Bids in alphabetical order, Microsoft's database engine does not support alternative alpha-numeric sorting sequences, so, for example, it puts 1N ahead of 1S, as well as creating other problems.
To get around these problems, the PB_Sort_Order field contains a coded form of the Prior Bids which will result in correct bridge-suit sorting. When you specify sorting by Prior_Bids, which is the normal method, the program doesn't really do so; instead, it sorts on the PB_Sort_Order field. If you unhide all columns on the grid (or do a Show All), you will see this field to the left of the Prior_Bids field. To get the grid to sort correctly, the PB_Sort_Order entries are padded with blank spaces on the left of the code. You can see the entry, but when you click on the field, the cursor starts on the first blank space, which moves the code off to the right where you may not be able to see it.
This field is not used for finding a bid for play, it used solely for displaying the database in the correct order on the grids in the BidBase Editor.
Whenever you save an entry in the Input Boxes, the program automatically calculates the PB_Sort_Order number. Users do not have to do anything with this field, and it is best left hidden to avoid accidentally messing up an entry.
If you see an entry out of place on the grid, such as 1C-1H prior bids being in with the 1C-1S entries, it is because the sort order field is wrong. To fix it, just double-click the line to put it in the Input Boxes, then save it. Just re-saving it will fix it.
The Bid Frame
This section explains the input boxes and buttons located in the Bid frame at the top of the input boxes below the grids.
Bid Order Number:
The Bid Order Number ("BON") is for specifying the order in which the bidding program compares entries to the current hand. The reason for considering bids in a specific order can best be understood by looking at two opening bids: 1N (#132000) and 1D (#634000), as discussed below:
Each entry filters the specifications for the entries which follow it.
When a program searches the database for an opening bid, it looks at each entry (matching the actual prior bids) in Bid Order Number order, stopping with the first entry whose specifications match the current hand's. For those of you with some programming knowledge: the database listed in entry number order is like a huge IF-THEN-ELSEIF-ENDIF statement where IF the specs in the first entry match the specs for the hand, the bid is used, ELSEIF the specs for the next entry match, it is used, ELSEIF... etc.
Since the Bid Order Number for 1N is lower than the one for 1, the program looks at the 1N entry first. Say that the current hand is AQ2 K32 KJ32 K32. Since the specs for entry #131000 specify a balanced hand with 15-17 points, this entry will be accepted and its bid (1N) made. The program does not look at any more entries (unless there is a number greater than 0 in the Pct_Used field).
Now look at the 1 entry #634000. It specifies only that the Diamond suit has 4+ cards, that Clubs must be shorter or equal, and that the hand must have 11+ HCPs and 13+ Total Points. Note that the AQ2 K32 KJ32 K32 hand also meets the criteria for bidding 1. If the 1 entry came before the 1N entry in the database, then the program would stop looking, never getting to the 1N entry. The program would bid 1 rather than the preferred 1N.
By putting the 1N entry before the 1 entry, we screen out any hands which might meet the 1 bid criteria, but with which we would rather bid 1N. You might be able to do this by making the specifications for 1 more restrictive, such as less than 15 HPCs and more than 17 or an unbalanced hand, but this actually gets to be a lot more complicated and thus harder to manage. It's easier to just get out of the way any balanced hands with 15-17 HCPs.
With the 1N entry before the 1 entry, if a hand had 3-3-4-3 shape but only 14 HCP, it would not match the 1N entry. The program would keep examining entries until it found the first one with specs matching the current hand, which would be the 1 entry.
Also notice that entry #634000 does not mention Spades or Hearts, only that Diamonds must be 4+ and Clubs must be shorter or equal. That is because the entries above #634000 specify hands on which Spades or Hearts could be bid, so entry #634000 no longer has to worry about those suits.
In effect, every entry defines what every other entry following it is not. Without this approach, then for each entry, you would have to try to specify everything that the current entry is not, which would be very difficult, at best.
For example, the 1 bid would have to say not only that the hand must have 11+ HCPs and longer Diamonds than other suits, but also that it must NOT have 15-17 and a balanced hand, nor a 5-card major, nor any other combination for which there are other entries.
And every time you added a new entry, other entries would have to be changed to specify that they do NOT include the new entry's specs. This would be a horrible mess which would clearly be unmanageable.
Bid Order Numbers are meaningless for bidding.
Other than setting the order in which the program considers alternative bids, the Bid Order Numbers are meaningless for determining what bid to make. Entry #634000 could just as well be numbered 634001. Or it could come before or after some of the other 1 entries, since logically, an entry cannot screen out another entry which has the same bid. (If it does, then the second entry is redundant and should be changed or deleted.) However, the numbers can be useful when viewing, editing or comparing entries in the database.
Notice that the Bid Order Numbers start over for each specific set of Prior Bids. That is because when a program searches for a bid, the search is only done of those entries which match the Prior Bids made to that point. Therefore, the numbers only have to keep the entries in order which match the Prior Bids made.
Again, the exact numbers used do not matter for finding bids, other than for establishing the order in which entries are considered.
At present, the Bid Order Numbers are six digits. So for each specific set of Prior Bids (e.g.: 1C-D), the database can have up to a million different bid entries (#000000-#999999). Only 29 different possible bids can be made after 1C-D, from 1D, 1H, 1S, 1N, 2C to, 7S, 7N, R(edouble), P(ass), but the database allows for up to a million different hand specifications for each of those 29 bids. And if necessary, we could easily increase it to a billion, or a trillion. (Entries are limited only by disk space.)
(Actually, the Bid Order Numbers may also include letters, so the number of possible entries for each set of Prior Bids is many multiples of millions.)
Entries with the BON:
When there are alternative bidding agreements for the same bid, such as 2C over 1N being either natural or a one-suited hand, the entries are normally given the same number and one or the other made inactive by entering "0" in the Pct field. Giving the entries the same number lets you easily see that these are for alternative bidding agreements for the same bid.
In addition, there may be alternative bids which may be made for the same hand specs, such as when a panel of experts vote on which is the best bid to make. If one bid gets 60% of the votes and another bid, 40%, you can enter those percents in the Pct field and give the two entries the same number. Over time, Double Dummy Analysis ("DDA") or experience may determine which is actually better and the other entry could be deleted.
When a system is chosen, such as 2-Over-1 ("2/1 Forcing"), all the entries which have the system name in their Cnv.Name field are activated and those with other system names are deactivated. That leaves entries which have no names in the field or have names of bids which are not part of specific systems.
To avoid having to make the user go through thousands of entries in the database deactivating entries which have the same hand specs as system entries with the same BON, the bidding software (BidBaseDB.DLL) will look at all entries with the same BON and if an entry with the chosen system name in its Cnv Name field has the same hand specs as another entry, the system entry is used.
Having entries with alternative bids for the same hand specs should not be confused with having entries which have different criteria for the same bid, but which are for the same bidding system.
For example, after an opening of 1H-1S, a bid of 4H may be made with 6-10 HCPs and 4+ Hearts, but it could also be made with no points with 5+ Hearts. It requires two entries to show these different sets of specs. Since the bids are not mutually exclusive alternatives, they should be given different numbers.
In contrast, after 1H-1S, a bid of 2C could be played as either weak or strong, depending on your agreements. These are mutually exclusive alternatives, not part of the same system, so they should be given the same numbers and one of them made inactive (by entering "0" in the Pct field).
The best way to see how the sequence numbers are used is to examine the numbers of the entries in the database. In particular, compare the numbers for similar bids, such as for bids after Prior Bids of 1C-1H-P and 1D-1H-P.
Mixing conventions' entries together:
BidBase combines all different conventions and bidding methods into a single database, generally mixing entries together for different systems.
This is because many systems share many entries which have the same bidding criteria, and it would be a waste of space to try to segregate all the entries for every different convention, method, or system into separate sections of the database or even worse, into separate databases, each with their own copies of the entries which they share in common.
This would make it very difficult to keep every section or database updated every time a new entry is added or updated, especially since the new entry or update may not apply to every different convention, method, or system the same.
That said, there are a few sections in this database where the bids for a particular system or convention are so unique that they would be unlikely to share entries with any other system or convention. An example is the set of responses for Precision to prior bids of 1C-P-1D-P. As a result, we have grouped those responses into a separate set of numbers starting with the letter P.
Numbering new entries:
Notice that the Bid Order Numbers are something like 100000, 200000, 210000, 220000, 300000, etc. This leaves plenty of rooms for new entry numbers between two existing entries, such as 110000, 120000, etc.
You should avoid using sequences of consecutive numbers such as 100001, 100002, etc., because that would create a problem if you should need to insert new entries between them.
In the last paragraph of the previous section, it is mentioned that some Precision system entries have "numbers" which start with "P". As mentioned before, the Bid Order Number field can, indeed, have letters in it, and not just at the beginning, either. For example, 100M00 is a legal "number". All you have to remember is that when sorted, letters come after numbers, and lowercase letters come after uppercase letters.
Finally, you should be aware that the Edit - Compare function compares entries which have the same numbers (and only those with the same numbers) to make sure they have similar specifications. So if you do not want an entry compared to a similar entry in another section, give it a different number.
Maintain consistent numbering for different Prior Bids:
Several features are built into BidBase to help insure that specs for similar bids are consistent. For these features to work, similar entries for different Prior Bids must have the same Bid Order Numbers.
For example, the entry for a standard raise to 2H after Prior Bids of 1C-1H-P and the entry for a standard raise to 2S after 1C-1S-P are both 510000. If you should add a new entry for a raise to 2H with different specs, and if you gave that entry the number 512000, then you should duplicate that entry for other similar sets of Prior Bids, including 1C-1S-P, and give each of them the same number of 512000.
Again, for purposes of bidding, the numbers would not matter, but for purposes of comparing entries to maintain consistent entry specifications, the numbers do matter.
The Plus Button:
A button with a plus sign is above the Order input box. This is used to increment the Bid Order Number. This is particularly useful when you are entering a series of bids which you want numbered sequentially.
When you left-click on the Plus Button, you will be prompted to enter an amount with which to increment the number. The default will be the last increment number entered, if any. If you right-click the button, the last increment number will be used without prompting.
When you use the Plus Button, it also puts a check mark in the New Entry box so that the entry will be saved as new instead of overwriting the original entry. If you just wanted to renumber the current entry without saving it as new, uncheck the box.
You can decrement the Bid Order Number by entering a negative number. It's hard to think, offhand, of why you would need to do this, but the function is there if needed.
The Bid field contains the call the program will make when this entry's criteria match the current hand, and the Prior Bids match the actual prior bids.
If the bid is some number followed by "x", such as "2x", it means that the criteria is the same for more than one suit. Obviously, the bid returned by the BidBase bidding module will be whichever suit meets the criteria, not something like "2x". This will be explained in more detail later.
Sometimes we refer to this field as Bid Name and other times, Convention Name, depending on the context of the discussion. There is no good, concise term which encompasses both of these, unfortunately.
The Bid Name field allows you to identify the convention (or bidding treatment) of which the current bid is a part, such as Stayman or Takeout Double.
Each bid/convention name has a Selected field (which will be described in detail later). When you choose a bid name from the drop-down list, its Selected field is displayed in the Cnv box.
You can select or deselect a convention by changing the Cnv box contents. This selects or deselects a convention for all entries in the database which include this bid name. It also selects or deselects any entries whose Use Against field reference this bid name.
This is how you choose which conventions you and your opponents will be using.
The Subcategory name allows you to select bidding options within a convention, such as Takeout Double: Resp.Dbl - Unbids or Takeout Double: Resp.Dbl - Minors where Takeout Double is the convention name and the text after the colon is the Subcategory name. These are alternative treatments. When you select or deselect one it affects all entries which reference that specific subcategory in its Bid Name or Use Against fields.
The subcategory code is displayed in and can be changed in the Sub box. which is the 2nd box on the left in the Bid frame.
The Pct field allows you to, among other things, select or deselect one, specific entry. We often come across conflicting opinions about the best bid for a particular hand specification. We usually put different entries in for each bid and show them as alternatives by giving them the same Bid Order Number and deselecting one of them.
When this happens in one set of Prior Bids, such as 1C-D, it likely happens in similar sets of Prior Bids, such as 1D-D, 1H-D, and 1S-D. If you decide to change the Pct field in one of these sections, you normally should make the same change to similar bid entries in the other sections. You have to do this by looking up each bid, one at a time, and making the change.
You could avoid having to make multiple changes for the same type of bid by giving that bid a more specific subcategory name. Then you could make one change to the subcategory's Sub code which would affect all entries using that subcategory name.
It's up to you whether you choose to select and deselect entries by changing their individual Pct fields or by giving them a subcategory name (or even a whole new bid/convention name) and just changing its Sub or Cnv field.
where the first two affect all entries in the database with the same name while the last one only affects the current entry.
- Overall Bid/Convention selection - use the Cnv box.
- Bid Subcategory selection - use the Sub field..
- Specific bid entry selection - use the Pct Used field.
A final note on this subject - although the bid/convention name and the Cnv and Sub fields appear in the Input Boxes with an entry, as well as in each line of the grid boxes with each entry, the actual names and selection codes are not part of each entry.
The bid/convention names and selection codes are stored in a separate table, each with a unique ID number. Each bid entry has a field for its convention's ID number, and this is what is used to look up and display the name and selection fields. As a result, when a name or code is changed, the change is automatically seen in the bid entries grids.
Convention/Notes Y/N Button:
This button displays a black N or a red Y and is located next to a "G" button at the top of the input fields in the Bid frame.
Most bid/convention names have a help file for them, stored in the Notes subfolder in BidBase's folder. The file's name is whatever text comes before a colon (":"), if any, in the Bid/Conv. Name field. The optional subcategory, which comes after the colon, would never have its own file. It would be a section in the Convention Name's file.
When the button above the Conv. Name field shows Y, clicking it will display a document with information about the bidding system. If the button shows N, clicking the button starts a new file in which you can enter notes of your own.
If you click on N to create a new file, then decide not to create one, you must click on Delete File in the File menu in the document viewing window to remove the file, even if you have not added anything to it. Otherwise, the blank file will just remain on your hard drive, cluttering things up.
Once in the BidBase File Viewer, if you click File - Open to open a new file, it will be displayed in place of the file you brought up by clicking the Notes button. You can use the Web navigation buttons in the viewer to go backwards and forwards if you have opened multiple files. The viewer can also be used to edit note files so that you can add your own notes to the file or create new files.
Many note files are just summaries of more extensive files on the Web. In that case, the summary file will contain a link to the Web file, as well as a link to a local (downloaded) copy of the Web file. However, you must actually make the Web link and download the page before the local link will work.
In the Notes folder is a folder named Archives. When you have brought up a Web page, do a Save-As to the Archives folder and give it the same file name as is used in the local link. If the local link doesn't work, press F11 to bring up the HTML source and make sure you saved using the same name as in the local link.
Double-click a Convention Name on a grid to bring up the file while scrolling the grid. Some names in the Convention Name fields do not have system note files, normally because the names are just there to identify the type of entry and don't rate a note file.
When double-clicking the grid to bring up a note file, you have to click once on the field to select it, then double-click to bring up the file. (This is a "feature" of the grid which is outside of our control.)
Adding to or changing the convention name list:
You should check the drop-down list when entering a convention to avoid having multiple names for the same convention. When looking for an existing entry name, you should be aware that we have tried to use names which group alternative or related names together.
For example, most notrump related bid names start with "NT". However, if a convention is very well known, such as Stayman or Jacoby Transfers, they are listed without the beginning "NT".
Other groupings are
- NT, Strong and NT, Weak
- 2C, 19-HCP and 2C Strong
- Tons of Overcall names and Takeout Double names
Regarding the line above -- names starting with Raise, Jump-Shift, Cue Bid, Free Bid, etc., are responses to opening bids. You will also see these same names as subcategories under Overcalls and Takeout Double.
If you already have a convention name entered for the current entry and then you type in a new convention name, the program will ask you if you want to add the name to the list as a new convention name, change the old name to the new name, or revert back to the original name.
If you do add a new convention name to the list, you usually will want to add some notes about the convention by clicking the "N" button above the Conv.Name field. If you already had a note file with the name of the convention, the button will show a red "Y", and you can click it to see the file.
The "G" Spot:
Click the G button to Google the web for more information about a convention. If the Convention Name field contains a colon (":"), only the text before the colon is Googled.
If the Convention Name field is blank, you will be asked for text for which to search.
BidBase adds "bridge+convention" to the search text to make sure the search is related to bridge conventions; however, once the Google web page is up, you can search for whatever you want.
Obviously, you must be connected to the Internet for this feature to work.
(Google is a trademark of whoever owns Google, is not affiliated with this program, etc., etc. All we are doing is bringing up the Google web page for you in a browser.)
Bid/Convention Used Against:
The Use_Against field specifies which system to use a bid against.
For example, if your partner opens 1 and your RHO bids 2, you might want to bid a major suit if 2 is natural, but not if it is Michaels (showing 5-5 or more in the majors).
When you edit a bid, it will not show you if the convention which it is Used Against has actually been selected for use by the opponents, but when BidBase searches for a bid, it will not make a bid if the opponents have not selected for use the convention which the bid is to be Used Against.
Before playing a bridge game which uses BidBase, you should select the conventions to be used by your side and those for the opponents.
For example, if you do not select Michaels to be used by your opponents, Than BidBase will not use an entry, such as a cue bid of Michaels, which is only to be used against the opponents bidding Michaels.
Standard High Card Points ("HCPs"):
A=4, K=3, Q=2, J=1.
The P prefix for responding to 1N:
The P signifies that the points required for the entry's bid is total partnership points. To come up with the points in partner's hand, he must have made a bid which requires a specified minimum number of points. Those points are added to the bidder's points to come up with the minimum total combined partnership points.
A variety of opening 1N ranges can be used: 16-18, 15-17, 14-16, 12-14, 11-13, 10-12, and even lower. A quantitative raise to 3N would normally have a HCP spec such as 9-13 opposite a 16-18 NT, but 10-14 opposite a 15-17 NT, etc.
Rather than making separate sets of entries for all possible reponses for all possible ranges of opening NT bids, you can enter a spec which is computed from the opening NT bid's specs, allowing BidBase to have one set of responses for all possible opening NT ranges.
(Click here for a more in-depth discussion of this feature.)
Here are the steps to follow:
First, enter your desired HCP range for 1N and 2N. The Bid Order Number for the 2N entry is #110000 and for 1N, #130000. No modifications should be made to these entries and no other entries should be given those numbers.
To be able to open 1N or 2N with other than a balanced hand within the specified HCP range, add new entries with different numbers. For example, if your opening range is 15-17 but you sometimes open 1N with good 14-HCP hands, create a new entry for that. Do not put 14-18 in entry #130000 for your 1N range unless you want to open all balanced 14-HCP hands 1N.
Second, create entries for responses: In the entry for making a quantitative raise to 3N, the hand's HCP field would normally be 10-14, as previously mentioned, but with the "P" prefix, we put the total minimum, which is opener's minimum (15, in this case) added to the 10-14 range, resulting in a HCP spec of P25-29.
So when entering specs for a response to 1N, first come up with the HCP range you would like to specify, then add the minimum HCP spec for the opening 1N bid you are using. The spec does not have to be a range of points. It could be something like 10+ or <8. which, opposite a 15-17 1N, would be entered as P25+ or P<23.
Say that the requirement for making the entry's bid for a response to an opening 1N is P25+. As we've seen, if the HCP range for 1N is 15-17, then responder must have at least 10 points, or 25 minus 15. If the bid requirement is P25-29, then responder must have 10-14, or 25 minus 15 to 29 minus 15.
But if the HCP range for 1N is 12-14, then responder must have at least 13 points, or 25 minus 12. Or a bid requirement of P25-29 would convert to 13-17.
Notice that P25-29 is not the full range of combined HCPs. It is the range of total points assuming that opener has a minimum.
The "Min" spec for rebids by 1N/2N opener:
"Min" has a purpose similar to the "P" spec, except that it is for rebids by opener. Responder may make an invitational raise, which asks opener to bid on if he is at the top of his range or to pass if he has a minimum.
Again, rather than having a different set of entries for each possible set of opening NT ranges, we use "Min" in the spec to tell BidBase to use the original minimum for the opening NT bid.
Here is how to use "Min" in the HCPs field:
||the specified opening NT minimum|
||anything more than the minimum|
||the middle value for 1N
the maximum for 2N
||the maximum for 1N;
1 over the max for 2N (i.e.: for a "bad" 22 assuming 2N shows 20-21)
||1 over the max for 1N (i.e.: for a "bad" 18)|
||1 less than the minimum (for a "good" 14-point 1N or 19-point 2N)|
The "HCP1N" and "HCP2N" Specs:
Enter "HCP1N" for the HCP spec to use the specified opening 1N range and "HCP2N" for 2N. You will see this mostly in the opening bids section for different bid specs which apply to all opening NT ranges.
Entries which apply only to a specific HCP range of opening NT will have the actual HCP range specified and must be manually activated and deactivated when used or not used.
Rebidding/Responding-To Strong vs. Weak NT:
A response to or rebid following 1N may be appropriate for a strong notrump but not for a weak notrump, or vice-versa, even with the HCP range adjusted.
When this is the case, such entries can still use the "P" or "Min", but they will have to be activated or deactivated manually when a change is made to/from weak/strong NT openings. To make this task easier, include the HCP range in the Convention Name field to make the entries easier to spot, such as Weak NT: ... or Strong NT:..., or even NT 12-14.
Distribution Points and Total Points:
Total points for distribution where
- doubleton = 1
- singleton = 2
- void = 3
To use this field to specify Total Points for a hand (HCPs + Distribution points), put a "T" before the number, such as:
It is not necessary to specify distribution points if you specify a singleton or void in the Shape field or in the suits' Num fields, but you can do so if you wish.
For example, a preemptive raise of 1 to 4 might be described as 8-10 HCP, 4+ Hearts, plus...
- an unbalanced hand (in the Shape field) or
- singleton/void (in the Shape field) or
- "<2" in one of the suit Num fields or
- "2+" points in the Distrib.Points field.
Hand Evaluation Systems
Hand evaluation adjustments are made in the bottom left two boxes on the screen under the heading of Hand Strength.
A novice's first hand evaluation system consists of counting honors for 4-3-2-1 HCPs for A-J and 3-2-1 distribution points for voids, singletons and doubletons.
Eventually, we learn to adjust for other factors, such as intermediates, hand shape, controls, HCP concentrations, and other players' bidding.
When creating an entry in BidBase, you can manually specify these factors, but doing so may require several different entries to cover many different types of hands which have the same playing strength.
A worthy alternative is a hand evaluation system which takes as many of these factors into account as possible, assigning Valuation Points to (or in some cases, deducting them from) the hand's total VPs.
The advantage of this is you can pick the hand evaluation system you like best (or create your own) and simply specify a number of VPs for that system. This is much easier and more consistent than trying to manually specify all the same factors in each of your entries.
In the Val.Sys. drop-down list box, select the valuation system you wish to use, then specify the points required in the Suit Val and NT Val boxes. (Most systems compute different values for a hand for a suit contract and for a NT contract.)
See the BidBase Hand Evaluation Program documentaton to learn more about the valuation systems.
The BidBase Evaluation system is based on Zar which I consider to be the best of these hand valuation systems, but with changes based on valuation adjustments made by other systems. So naturally, I consider the BidBase (nee: Zar) system to be the ultimate best.
Click File - Hand Eval.Pgm. in the editor program to run the Hand Evalution Program with which you can create new systems or change existing ones.
Note that if you specify Valuation Points, you usually should not specify other factors in the Hand Strength section unless you want them to override the VP specs. That is because the VPs often include the other adjustments.
You can define the number of points you would like assigned to each honor card. For example you might want to assign the usual 4-3-2-1 points to the A-K-Q-J, but also assign .5 to the Ten. Or you can use the 6-4-2-1 point count method.
Another common count is for A-K points (or 2-1 points) where A=2 and K=1. This can be used to assure that a 10-HCP hand is not all Queens and Jacks, for example.
Custom points are (optionally) in addition to the other counts. In other words, you can still specify regular HCPs, Total Points, etc., as well as your custom points, but if you do so, a hand must meet all the point requirements entered, not just one.
Enter the minimum total custom points in the Cust.Points box, and enter the points assigned to each honor in the boxes below.
Let's say that you want just a minimum number of Aces in a hand and you're not concerned about any other honors. To assure having at least 2 Aces, enter 2 in Cust.Points and 1 in the Ace box.
The number of winners in a hand (Playing Tricks) is based on the first four cards in a suit, plus one winner counted for each card more than four in a suit.
AKQJ=4, AKQT=3.5, AKJT=3.5, AQJT=3.5, AKQ=3,
KQJT=3, AQJ=2.5, AK=2, KQJ=2, QJTx=2,
AQ=1.5, A=1, KQ=1, QJT=1, Kx=.5
Running Winners - Sometimes you need to have some number of winners which you can take immediately. For example, if RHO opens 3S and you have a single stop in Spades (e.g.: Ax), and a strong hand, you can probably only make 3N by taking 9 tricks off the top (the AS and 8 more) since the opponents will run Spades if they get in again after the opening Spade lead.
To specify Running Winners (or "cashable" winners), put an R in front of the numbers, such as "R9".
The number of Winners specified is treated as a minimum requirement, so you can just enter 3, for example, and not 3+.
The number of losers (Losing Trick Count) is based on the first 3 cards (if that many) in a suit.
AKx=1, AK=0, AQx=1, AQ=1, AJT=1, Axx=2, Ax=1, A=0,
KQx=2, KQ=1, Kxx=2, Kx=1, K=1,
QJT=2, QJx=2, QJ=2, Qxx=2.5, Qx=2, Q=1
Because of the way Winners and Losers are calculated, they normally do not add up to 13, as the names might suggest.
Losers may be specified as either some minimum number (e.g.: "6" is the same as "6+") or less than some number (e.g.: "<5").
LTC should just be used as a way of deciding what to do with borderline hands. We have rarely, if ever, used it as an entry specification, but when BB calculates and displays a specific hand's specs, we may look at the LTC spec to help decide how to tweak other specs.
The number of Quick Tricks, where AK=2, AQ=1.5, Ax=1, A=1, KQ=1, Kx=.5, K=0.
In a 6-card or longer suit, half a quick trick is deducted from any quick tricks in the suit because of the odds that the suit will not survive two rounds without being ruffed. If you don't like this idea, you can offset it by reducing your QT requirements by a half trick.
Some sources talk about "cashing" quick tricks. They are not using the phrase "quick tricks" in the same way as it is used in hand evaluation, since if you try to "cash" the Q from AQ or K from Kx, the opponents will overtake you. (See "Winners", above, for specifying "cashable" tricks.)
Other sources may say that AKQ is 3 quick tricks and that QJT is 1, but standard usage is to only count the likely winners in the 1st two rounds of play of a suit under the assumption that the 3rd round is likely to get trumped.
Most players say that "quick tricks" are "defensive" tricks and that "winners" are for evaluating offensive hands. Therefore, it may be confusing when they say that you need at least 2 (or 2.5) quick tricks (i.e.: defensive tricks) to open 1 of a suit and 5 to open 2C (offensive bids), but the reason is that a 1x or 2C opening bid should have some defensive, as well as offensive, strength.
The number of Quick Tricks specified is treated as a minimum requirement (i.e.: "2" has the same effect as "2+").
This field specifies the number of suits in which a hand has sufficient high cards and length to keep the opponents from running more than a few tricks.
This number of suits normally excludes a suit bid by partner. Otherwise, the suits stopped are unspecified. To require specific suits to be stopped, indicate that in the suits' Points fields.
A Stopper is a suit holding which, when the player is declarer, can keep the opponents from running more than 4 tricks in the suit off the top. Stoppers are: A, Kx, QJx, QT9x, Q98x, JT9x, J98xx, T98xx or better. This field does not count the number of stoppers. For example, AK in a suit is just counted as 1 suit stopped, but in the Points field for each suit, it would be counted as 2 stoppers in the suit.
A half-stopper is Qxx or Jxxx. Half-stoppers are counted in the hand's total of suits stopped. That is, two half-stopped suits are counted as one stopped suit.
The number of Suits Stopped specified is treated as a minimum requirement, so "2" is the same as "2+".
Different Ways Of Specifying High Cards
Let's go back now and look at different ways of specifying high cards.
HCP - You might specify 10+ HCP and end up with Q32 QJ2 QJ2 Q432, which is pretty ugly. Specifying 10+ KNR points will require a hand with better quality points and shape, such as A32 AQ432 32 432
Getting more specific, you can use Custom Points, where you rate Aces as 2 and Kings as 1, then give a minimum number of total custom points you want the hand to have, such as 3, which could be an ace and a king, or 3 kings. The former would require a hand such as AJ32 KQ32 2 5432. .
You could also get a hand like the last one if you specified 2 Winners or 2 Suits stopped.
Finally, in the suit fields, discussed below, you can specify not only a particular range of points, but optionally which honor cards make them up.
Hand shapes are: balanced, unbalanced, any 1-, 2-, 3-suiter, any singleton, any void, any singleton or void.
The Shape field is for generalized shape, such as when a 2-suited hand can be any two suits, but not when it must be two specific suits, such as the Majors. If you need to name specific suits, you should do so in the suits' Num fields.
If 2 over 1 shows 5-5 or more in the Majors, put 5+ in both the Spades and Hearts Num fields; do not put "2-suiter" in the Shape field because that could be any two suits.
If 2 over 1N shows ANY 1-suited hand, put "1-suiter" in the Shape field and leave the Num fields blank.
You may have to use both the Shape box and the suit length boxes if it is not possible to cover all the specs using just one or the other. If you still have trouble getting all the specs into one entry, you can always make two (or more) entries for the same bid but with different specs.
Brozel 2 over 1N shows 6 Diamonds and 4 Hearts. Put 6 in the Diamonds Num box and 4 in the Hearts Num box. It is not necessary to put "2-suiter" in the Shape field, because the entries in the Diamonds and Hearts Num boxes already specify a 2-suiter.
Brozel Dbl over 1N shows just a 6+ card suit with 5+ HCPs in it. This can be any suit, so you could put "1-suiter" in the Shape box. But then how would you specify that the long suit must also have 5+ points?
So instead of using the Shape box, use the X suit boxes to specify 6+ Num and 5+ Points and put an "x" in each suit's Num and Points box.
But when you do this, the Brozel Dbl entry used to specify a 6-card suit would also catch hands that match the criteria for Brozel 2, which also specifies a 6-card suit, Diamonds, in addition to a 4-card Heart suit. So to avoid this, also put "1-suiter" in the Shape box for the Brozel Dbl entry to distinguish it from the 2 entry which shows a specific 2-suiter.
To sum up what the Brozel Dbl entry would look like (in part):
And here is what the Brozel 2 entry would look like:
On a side note - notice that using the X Suit field lets one Bid database entry take the place of having four separate entries, one for each suit. This not only saves room in the database, but it makes it faster and easier to add to or update the database. It also makes selecting a bid faster because the BidBase bidding module can examine one entry instead of as many as four.
Shape - Singleton/Void:
If you use a bid such as Random Splinter (1-[P]-3N) to show an unspecified singleton or void, use the Shape field to specify the singleton/void.
But if you use a normal Splinter to show a singleton/void in a particular suit (e.g.: 1-4 to show a Club singleton or void), you should use the suit's Num field to specify a singleton/void. In this example, you would enter "<2" in the Club's Num field.
The term "intermediate cards" is defined and used in various ways on the Web and in books and magazines. For purposes of BidBase, we consider Intermediates to be 8's, 9's and 10's (where an 8 must be paired with a 9 or 10 to be counted).
If you specify only High Card Points, you can end up with a hand like this: A432 K2 Q432 432.
In the Intermediates box under the Shape box, you can enter the total number of Intermediates a hand must have. If you enter 5, for example, the above hand would have to look something like this: AT32 K2 QT82 982.
Alternatively, you can specify Intermediates by suit. See Suit Num And Points, below. If you specify a number of Intermediates for the hand and also for specific suit(s), those specifications overlap. That is, if you say that the hand must have 2 and then say that Spades must have 2, that is a redundant specification of 2 Intermediates. If you want the hand to have 2 outside of, say, Spades, then specify 4 for the hand and 2 for Spades.
The Intermediates field is of greatest value when trying to decide whether or not to use an entry when a hand is at the bottom of the HCP range. For example, if your notrump range is 15-17, but you sometimes open a good 14-HCP hand 1N, then you could make an entry that specifies exactly 14 HCP, but also 3 or 4 intermediates.
If you want really good Intermediates (with more 10's then 9's or 8's, for example), you could specify a number of Intermediates, and under Custom Points, specify a minimum number of 10's. For example, you could specify five Intermediates and three 10's. Those specs also overlap. The hand above would look something like this: AT32 K2 QT92 T92
"X" Suit Num and Points:
Let's say that you want to enter or edit partner's responses to 1. You could make a separate entry for a strong jump-shift in each suit (2, 2, 2), where you enter "6+" in the appropriate suit number field.
To save time in making entries, as well as to save space in and to simplify the database, you can enter specifications in the "X" suit fields, then put "x" in the appropriate suit fields.
Longest or Highest Suit First:
When the "X" Suit fields are used, the program uses the longest suit with x in its Num field. For example, if "X" Num is "5+" and the hand in question has 5 Spades and 6 Hearts, the program will bid Hearts. However, when there is more than one suit of equal length, the higher suit (Spades, in this example) will be chosen, unless...
Longest or Lowest Suit First:
The vast majority of the time, you want to BidBase to bid the higher ranking of two suits of equal length, so this method of handling the "X" suits works fine. However, if you do not want the higher suit bid, add a "U" to the spec to get BidBase to look "up-the-line" from Clubs to Spades. Example: with 4+U and Spades and Hearts both 4-card suits, Hearts will be bid, while with just 4+, Spades will be bid.
"X" Suit Doesn't Have to Be The Suit Bid:
The "X" Suit Num can be used for suits other than the one being bid. For example, an entry for Michaels over 1 (i.e.: 1-2) which shows 5+ Spades and 5+ of one of the two minors may have an entry like this
Entering An Alternative Specification:
Sometimes you may want a suit to match some other specification if it does not match the "X" spec. To do this, the second specification can be entered in the Suit's field, separated from the "X" spec by a comma, such as x,4+. This means that the suit must either match the "X" specification, or if it does not, it must be at least 4 cards long.
If you enter an "X" spec, at least one suit must match the "X" spec. For example, to specify 6-4 in the majors and that either major can have 6, you would enter an "X" spec of 6 and for each major, you would enter x,4. If the majors were 4-4, they would each match the alternative spec, but the test would fail because neither suit would match the "X" spec of 6.
If you enter "x" plus an alternative spec for a suit, the "x" must come first.
If you specify both xNum and xHCP, then a suit must match both to pass testing.
If you specify an alternative spec for xNum, such as "x,5+" and also specify a value for xHCP, the xHCP applies only when testing the xNum value for the suit. If that test fails, then when the program next tests the alternative (5+, in this example), the "x" in the "Points" field will be ignored.
Creating a Test Hand For "X" Specs:
When entering a Test Hand for an x-suit entry, make the highest suit match the "x" specs. BidBase will do this automatically. For example, if xNum is, say, 5+ and Diamonds and Clubs have "x" for their Num fields, then the test hand should be something like 432-2-KQJ32-6543.
Although 432-2-6543-KQJ32 would work for testing the entry, consistently giving the highest "x" suit the "x" specs makes entry comparison easier and more reliable, which is very important.
Even if your source from an entry is a hand from a magazine, change the hand to make the highest "x" suit match the "x" specs. Example: If the magazine's hand is 32-AQJ8432-QJ7-83 and this is an entry for making a weak jump overcall of a 1C opening, so the "x" spec is for a 6-card suit, swap the Hearts and Spades for the Test Hand.
Suit Num and Points:
For each suit, you can specify the number of cards required for the suit, as well as the strength (in HCPs) of the suit.
Specifying Suit Quantity:
The number of cards may be specified such as <4, 2-5, >C, >=D, <H, =H or, as explained above, x.
>C means more of the suit than there are Clubs.
>=D means more than or equal to the number of Diamonds, etc.
See the previous section for an explanation of using the x field. In addition to having "x" fields, a non-x field may use >x, >=x, <x, or <=x, where the suit is compared to whichever suit meets the "x" specs.
For example, if "x" = 5+ and Clubs and Diamonds are each "x" fields, Spades and/or Hearts could contain something like "<=x" so that a minor suit will not be bid if a major suit is longer.
You can make alternative specs by separating them with a comma, such as <3,>5, which means that if the suit is either less than 3 or more than 5 in length, it is okay.
Points may be specified in the usual manner: 2-4, 4+, <=2, etc.
You may also specify and Ace or King by entering A or K or to accept either, put A,K. Usually the case of letters does not matter, but since lowercase a is used for AK, KQ or AQ (see below), then to specify an Ace, you must use uppercase A. You can control Aces and Kings for the whole hand with Custom Points.
Points may be specified by using the following codes:
x = use the "x" specs, as previously described.
a = "AK, KQ, or AQ"
b = "AJT, KJT, or QJT"
c = "KQJ, AQJ, or AKQ"
d = "AKQJ, KQJT, AKQT, or AKJT"
2stop = "AK, AQ, AJTx, AT98x, KQJ, KQT, KQ9x, KJTx, or KT9x",
1stop = "A, Kx, QJx, QT9x, Q98x, JT9x, J98xx, or T98xx"
hstop = half-stop = "Qxx or Jxxx". (See Western Cue Bids.)
0stop = no stopper. (Opps can take 5 tricks off the top.)
FRC = First Round Control (either an Ace or Void)
SRC = Second Round Control (either King or Singleton)
P = honors are protected by the bidding.
i# = Intermediates (e.g.: 4+i1 means 4+ HCP and 1 intermediate.)
If you specify "c", it would be redundant to also specify "a" since "c" is just a stronger version of "a". Any hand which has, for example, the "KQJ" alternative in "c" would already match the "KQ" alternative in "a". However, "ab" and "bc" are non-redundant combinations. So you might want to enter a, b, ab, or bc, but not ac nor abc.
If you enter ONLY "b", then holdings better than "AJT, KJT, QJT", such as "AQJT" or "KQJT" will be rejected. To include better holdings, you must enter "ab" or "bc" or use some other type of input.
You can make alternative specs by separating them with a comma, such as <3,>5, which means that if the suit's HCPs are less then 3 or more than 5, it is okay.
The Protected Honors specification is primarily for use for 4th seat where the opponents have bid and partner has passed, such as 1-P-1, where KJ of Spades are "protected" because RHO bid them, but KJ of Hearts are not protected because LHO bid them.
Protected Honors can also be used where just one opponent has bid, such as in Spades where the bidding has gone 1S-?? or 1S-P-P-??.
To specify points plus Intermediates (8-10) for a suit, enter "i#" after the other specs, such as "abi2". A suit matching "abi2", for example, might have "KQT92", where the "KQ" matches the "a" spec and the "T9" matches the "i2" spec. Another example is "4+i1", which says 4+ HCPs plus at least one intermediate, such as "AT32" or "KJ92".
Do not be confused when you see "4+i1" and think that it means "4 HCPs plus 1 intermediate". That spec would simply be "4i1". The spec "4+i1" means 4 or more HCPs and 1 (or more) intermediate(s).
If a suit does not have the required Intermediates but has more than the minimum HCPs required, then the suit will be accepted. It would make no sense if, for example, when specifying "abi1", that "AQ92" should be accepted ("9" being an intermediate), but that an even better holding without an intermediate, such as "AQJ2", should be rejected.
Using ai1 for an example, the a requires AK, KQ or AQ. "KQ" has the least high-card points (5), so to fulfill the ai1 requirement, you would need an intermediate to go with the KQ, but not with the AQ or AK. Likewise, for abi2, you could have KQT92, or AKT42 or AQ942.
An example with HCPs specified is 2+i2. The cards Q98 meet this spec exactly, but K92 (1 less intermediate, but one more HCP) and KJ2 (2 fewer intermediates but 2 more HCPs) also meet the spec.
In theory, a HCP for an honor is normally worth more than an intermediate, so that for each extra HCP, we should be able to drop two intermediates instead of just one, but we are being a little conservative. If there is a great outcry about this, we could be convinced to change it, or you could just change your specs (i.e.: use 3+i2 instead of 3+i1).
An 8 is only counted as an intermediate when it is with other intermediates, such as KQ98 or KQT8, but not KQ8x.
When specifying Intermediates, do not put a comma before the "i". If you put "a,i1", it would tell the program that either "a" or "i1" is acceptable. You normally want both "a" and "i1".
Combined Suit Num & Points
The Combined Suit input boxes allow you to cover several hand types in one entry.
In the boxes labeled Comb, you can specify the total number of cards and points for any 2 or 3 suits. For example, in the Num. input box, you could enter SH=8-9, specifying that Spades and Hearts together must total 8 or 9 cards.
Assuming you don't want, say, 9 cards split 8-1, then in the individual Num. input boxes for each suit, enter 4-5. This allows you to specify that the two suits may be 4-4, 4-5, or 5-4 but not, for example, 6-3 or 3-5. Without this field, you would have to create two entries, one for Spades 4-5, Hearts 4, and a second entry for Spades 4, Hearts 4-5. Instead, you can create one entry with Spades 4-5, Hearts 4-5, Comb SH=8-9.
Example: RHO opens 1. You want to make a takeout double if you have support for the unbid suits. Assume that you don't mind 3-card support for one suit, but not for more than one. If you specified 3-4 cards for each suit, that would allow 3 cards in each suit. By entering SHD=11-12 in the Combo box and 3-4 in each of the suit's Num boxes, you will enforce a distribution of 3-4-4, 4-3-4, 4-4-3, or 4-4-4.
Here are examples of the acceptable formats for specifying combined suits:
You must specify either 2 or 3 suits, followed by a one-character math symbol (=, >, or <), followed by a number or a range of numbers (e.g.: 12-13).
Specifying combined suit HCPs is especially useful for making sure when a hand is at the minimum of the range of HCPs allowed, that the points are concentrated in the desired suits. For example, after 1-P-P, the minimum for balancing is as little as 7 HCPs, but you don't want, say, 2 of those points being a Queen in LHO's Diamonds.
But if you have a non-minimum, such as 9+ HCPs, you don't mind if 2 of the points are in LHO's suit, so you don't really want to specify that Diamond HCPs must be <2. One solution would be to make one entry for 6-8 HCP hands with D<2 and a second entry 9+ HCP hands where Diamonds could (but doesn't have to) have 2+ HCPs.
But instead of making two entries, you can make one which says that SHC combined must be 7+ HCPs. Now if the hand has 7 HCPs, all the points must be in Spades, Hearts, and Clubs, but if the hand has, say 10 HCPs, you can now have 3 points in Diamonds because you will still have 7 HCPs in the other 3 suits.
Using 'x' in the Comb field:
If an entry uses the "X" field, you can use "x" in the Comb field. For example: "xD>7" says that the "x" suit (whether Clubs, Hearts or Spades) plus Diamonds must be greater than 7.
When using "x" in the Comb field, the "x" must always come first.
Rather than have a million entries which end in the same Ace-asking sequence, BidBase has Ace-asking entries which just show prior bids of 4C-P or 5C-P (Gerber), 4N-P or 5N-P (Blackwood or Roman Key Card Blackwood). Numerous variations of Blackwood exist which are not in BidBase but could easily be added in the same format.
See the Ace Asking documentation file for information about how these entries are made.
A menu option in the BidBase Practice program lets you practice bidding Ace-asking conventions of your choice.
Vul = You are vulnerable (opponents may or may not be)
Non = You are not vulnerable (opponents may or may not be)
Fav = Favorable (opponents are vulnerable, you are not)
Unfav = Unfavorable (you are, opponents are not)
Eq. = Equal (you both are, or both are not)
Eq+ = Equal or Favorable
If you leave the field blank, than any vulnerability is accepted.
See discussion of Prior Bids, above.
This field indicates the position of either the opener or his partner. This field is needed because lead-off Passes are ignored in the Prior Bids field, yet the requirements for some bids differ greatly if the bidder or his partner has already passed.
For example, if the Prior Bids are 1-P and responder has KQ932 AJ4 2 J432, he should bid 1 if he is an unpassed hand, but as a passed hand, he may want to jump to 2 to show that he is at the top of his range for being passed.
Here are the acceptable database values for Position, along with their meaning:
1 = bidder is in 1st seat
2 = bidder is in 2nd seat
3 = bidder is in 3rd seat
4 = bidder is in 4th seat
F = bidder is in First or Second seat
T = bidder is in Third or Fourth seat.
Y = bidder is a passed hand
N = bidder is an unpassed hand
P = bidder's partner is a Passed hand
U = bidder's partner is an Unpassed hand
If the field is left blank, it means that position does not matter.
- Prior Bids: 1C-P-1S. Bid: 1N
For unpassed bidder, this shows 15-18 balanced.
For a passed bidder, it shows 7-9 HCPs, 5-5 in the unbid suits (Sandwich Notrump).
So you need two entries, one for each of the above cases.
- Prior Bids: 1S-P. Bid: 2C
For unpassed responder, this shows 11+ HCPs, Clubs could be short.
For a passed responder (not playing Drury), this shows 6+ HCPs and a real Club suit, or if playing Drury, it shows 10-11 HCPs and Spade support.
So again you need 2 entries: one for each of the above possibilities. Note that it doesn't really matter if you specify that opener is in 3rd/4th seat or that responder is a passed hand because if one is true, the other is true. However, there may be times when it seems more logical to use one rather than the other.
You do not always need to specify position. For example, after 1S-P, if responder has 3-2-5-3 and <10 HCPs, it does not matter if opener is in 3rd chair or if responder is a passed hand or not, the bid is always going to be 2S.
For those times when being a passed hand or not does matter, select the desired Position in the Position drop-down list box. Again, this is the position relative to the dealer. The Player number box to the left of the Prior Bids box is the position relative to the first non-passing bid.
So if partner was dealer and passed and your RHO passed and you made an opening bid,
- You are Player number 1 (first to "Bid") (to the left of the Prior Bids box) but
- You are also Position number 3 (third to "Call") (in the center of the Input Boxes area.)
The Best Contract field is not being used at present. It is planned for use with a Double Dummy Analyzer.
Type of Disclosure:
In bridge, the opponents are entitled to know the details of any agreements your partnership has made regarding the meaning of any artificial bids.
The three basic types of disclosures are
- Alerts -- The bidder's partner simply says "Alert" and provides no other information unless asked. A bridge program normally has some way of alerting a human about such a bid, then the user can click something for more information.
- Announcements -- An announcement, such as saying "Transfer" when a transfer response to a 1NT opening is made, should also be automatically shown to the user of a bridge program.
- Pre-alerts -- Some types of partnership agreements must be explained to the opponents prior to the start of a game (IMPs) or set of deals (MPs). In BidBase, this can be done by the user's reviewing the database before playing.
The main purpose of the Disclosure text field is to clarify for human players the information in the other disclosure fields or to provide additional information or references.
It can also be used for short notes about an entry for reference when modifying the database. Start with a left bracket "[" for any such notes which you do not want displayed during the game.
The N button to the right of the Disclosure field brings up a note file in which you can enter more information about a particular bid. This is in contrast to the info file for Conventions which is for notes about an overall convention. The Disclosure field file is for just the current bid. This information is not routinely shown to players, but a program could offer it as an option if the programmer wished.
When you click the N button, if a note file does not yet exist for the entry, one is created in the EntryNotes folder inside the Notes folder/directory as follows
- The file is given a name made up of:
- the Prior Bids,
- the entry's Bid,
- the text _ID and the entry's ID#,
- and the extension .txt.
- Example: 1C-1H-P-1S_ID1234.txt
where 1C-1H-P are the prior bids for the entry,
1S is the bid made by the entry, and
1234 is the entry's ID#.
- The N button is changed to Y.
- The BidBase File Viewer is called up to display the file.
- The phrase See notes --> is added to the Disclosure file if there is room.
If you decide you don't want the file, you must delete it in the BidBase File Viewer by clicking on Delete File in the File menu, even if you did not add any text to the file. Failure to delete files you don't put notes in will just junk up your Notes folder.
If you use BidBase File Viewer to delete the file rather than enter notes into it, the BidBase Editor has no way of knowing that right away, since it does not continuously check for the presence of the file, but it will change the button the next time it checks for the file. However, you should remove the phrase [See notes --> from the Disclosure field before saving the entry.
If you edit an entry (move it from the grid to the input boxes) and the program sees that the entry has a description file, it changes the button from N to Y to let you know that, yes, there is a file for the entry. Click the button to view/edit it.
Some times you may want to refer an entry to an existing note file rather than creating a new note file for the entry which simply duplicates information in an already existing file. To do this, enter the file name in the Explanation field in brackets, such as
[See file: Negative_Doubles.htm] or
[See file: 1C-1D-3C_ID278.txt].
You can leave out the See notes: phrase if there is not room, but don't forget to put the left bracket at the start of the Disclosure field.
When scrolling a grid, if the Explanation column contains a note file reference, you can bring up the file by double-clicking on it. (You may have to single-click on it once to select the field before double-clicking it. Blame Microsoft, not me!)
Asks Partner For Or To Bid:
This field indicates if a bid asks partner for specific information or asks him to make a specific bid, such as a transfer or relay or simply forces him to bid one more round or to game.
If the forcing nature of a bid is obvious, then this field may be left blank. For example, after 1-[P]-2, only the rawest beginner would not be aware that opener is expected to bid again, and let's face it, this program is not aimed at raw beginners. However, if you WANT to enter that information for every bid, you could certainly do so.
H(elp)s(=C,D,H,S): Invites to game if partner can help in the suit bid. Example: 1-2, 3. For the 3 bid, you would enter HC in the Asks For field to show that 3 asks partner to bid game if he has help in the Club suit. Also see Western Cue Bids.
C(ontrol)s(=C,D,H,S): Asks partner for a control in the suit indicated. This is normally a slam try.
(CD): 1-3, 4 is a cue bid asking for a Diamond control. By agreement, this could be an Ace or King or singleton or void
(HD): 1-(1)-2 asks partner to bid 3N if he has Diamonds stopped.
B(id)xx: Asks partner to make the specified bid "xx".
For example, B2H indicates that bidding 2D over 1N, is a transfer to Hearts, although for such standard types of transfers, this field is skipped.
P(ick a suit/slam): P asks partner to pick a suit and bid game/slam.
A(ces), K(ings), K(ey)C(ards): "A" or "K" or "KC", as in Blackwood.
1: Forces partner to bid one more round.
G: Forces partner to bid until some game is reached.
O: Bidding again is Optional, or semi-forcing. For example, some people play that a 1N response to 1 of a major opening is forcing, but others play that it is "semi-forcing". Doubling a high-level preempt is usually optional, such that doubler's partner has the option of passing for penalties or bidding.
SO: Sign-Off - strongly suggests that partner pass.
The Strength field is very important because
it can affect subsequent bidding and play.
Enter the expected strength of the hand for the current bid (not just the current entry) by selecting from the drop-down list box.
The expected strength is what you would play your partner for if he made the entry's bid, not necessarily the minimum with which he might make the bid.
For example, a takeout double ("TOX") usually promises opening strength, but could be made with as few as 10 HCPs with perfect (4-4-4-1) shape, or 18+ HCPs with an offshape hand.
Even though doubler may have as few as 10 HCPs, you normally expect him to have about Opening strength, so you would enter O for each TOX entry, whether an individual entry's specs are for 10+, 13+, or 18+ HCPs.
Note that the same bid may have different expected strengths based on scoring method, vulnerability, or position, or when used against different conventions; otherwise, each entry with the same bid (and with each of the variables just mentioned the same) must have the same expected strngth, no matter what the strength requirements of the individual entries.
Below are the strength classes from which to choose. The HCP ranges are approximations shown only for reference, hence some overlaps.
If you open 1NT with 12-14 HCPs, for example, you would enter O, since that is the closest range. If you open 1NT with 15-17, but sometimes 14, you would enter P for the 15-17 entry, as well as for the 14-HCP 1NT entry, even though the 14-HCP entry falls outside P's HCP range.
The last column contains examples of bids which may (or may not, depending on your system) fall into the strength categories shown.