Introduction and Background
To open a linked file in a new window,
= Diamonds or Clubs.|
= Hearts or Spades.
In Bidbase, citing a source in the Reference field is only given as a place to look for more information. The hand from that source is used as a starting point for creating the hand specifications required for making the bid and are virtually never provided by the aource.
BidBase bidding entries are frequently tested agains bidding quizzes, sample auctions given in bridge articles and books, etc., and are updated, if necessary, to agree with expert opinion.
All the databases, text files and programs making up BidBase are public domain.
That being the case, I cannot be responsible for how up-to-date or correct files are which come from sources other than my web site.
The BidBaseDB.DLL file is a bidding module which could be added to any (Windows-based) bridge software and used to provide bidding for that software. It is also free. Direct any questions to:
BidBase's primary purpose is to allow users to practice bidding in order to improve their games using the BidBase Practice Bidder program.
The part of BidBase which does the actual bidding is in a separate module which is called by the BB Editor and Practice programs when a bid is needed. So another goal for BidBase is for this module to be used by bridge related programs (in addition to mine) which involve bidding.
Originally, most bidding was limited to two rounds. After that, it usually becomes less a matter of bidding agreements and more about completing what you've already started. As discussed later on, even the Bidding Dictionary only partially covers even the first two rounds.
However, now that dozens of commonly (and even less commonly) used conventions have been entered, most new entries are now going beyond two rounds of bidding.
With very, very few exceptions, the bids in BidBase are based upon recommendations by top experts as expressed in bridge books and magazines and web sites.
Other exceptions are entries to fill in holes in bidding sequences or to apply numbers to bid requirements where there are inconsistencies or somewhat vague terms as will be discussed in more depth elsewhere.
On the simplest level, the computer bids ACBL's "Fat Free" system. You can download the convention card for this system at ACBL's Convention Cards page. As the name suggests, it is a very basic system with no alertable conventions. (NT transfers must be announced.)
One level up is the Standard American Yellow Card ("SAYC") system with some common conventions.
In addition to Fat Free, SAYC, Bridge World Standard, Precision and 2/1 are systems which can also be selected with one click.
These basic systems can be added to by checking off conventions from a list. But such systems rely on many Standard American bid specifications which are not selected or deselected when you choose a system.
For example, the Web site describing Bridge World Standard also describes some general bidding situations and bids which are not specific to BWS. Most of these situations and bids are included in BidBase along with a reference to the BWS pages for more information. Those entries will NOT be deselected if BWS is not selected.
To this point, the program is extremely simple to use. You click on the conventions you want to use and run the practice program.
But let's say that while selecting conventions, you don't see one you would like to use, or perhaps you don't agree with the hand specifications the database has for making a particular bid
Well, the database can be modified by adding or even changing entries to your own preferences, which, in theory, makes it possible to include any type of bid or convention you wish.
I say "in theory" because in order to be able to offer all of this, BidBase must be very flexible and the trade-off for flexibility is complexity. To make an entry for a bid in a particular situation requires being able to fully describe the hand's specifications which would justify the bid. Each such entry is a record in the database and each record contains a total of 59 fields which can be used to describe the hand. And an improperly prepared entry could throw off other entries in the database.
The CardShark BidBase Editor has numerous features to make it possible to view the database and to create new entries and change existing ones. A test hand is generated by the program for each new entry and before accepting the entry, the program attempts to get the bid for that entry by submitting the prior bids and the test hand to the BidBaseDB module to make sure it returns the new bid. If it does not, the user is alerted and the bid is not added.
In addition to the documentation file, linked above, the BB Editor has a built-in tutorial which walks you through every feature of the program or can be used to selectively get help on any particular feature.
The point to be learned is that [no bidding system] is perfect. Even experts disagree.
Bidding is a form of science, but, as in many scientific endeavors, it is impossible to attain perfection. The theoretical must give way to the practical in numerous hands, and some bids are only general-direction shots with which the marksman hopes to hit the target.
For BidBase, we had to select criteria for all the bids. However, as noted by Lawrence, not everyone is going to agree with all of our choices. For example, one person may make a takeout double with a hand with which someone else may overcall but with which a 3rd person may pass. And often, neither bid can be proven to be consistently superior to the other.
Consequently, we had to make choices with which you may not always agree. But the beauty of BidBase is that unlike most bridge programs, you are not stuck with our choices. You can modify the database to your heart's content.
However, with any system or convention, there can be problem hands which one convention or system handles easily, but which present a difficult, or even impossible bidding problem for another convention or system. But for some other hand, the reverse may be true.
So when working on the database and/or on your bidding system, keep in mind that no system is perfect. If you run up against a problem in bidding which your system or convention cannot handle, you may be able to solve it only at the cost of creating a different problem somewhere else.
Every entry in a section can potentially affect every other entry in the same section, so be careful when you change, add, or delete entries. That being said, the BB Editor contains numerous features to make sure such problems don't arise. One feature is that when you make a new entry and save it, BBE will generate a test hand which matches the specifications you entered for the bid, tells the BB Database Module to find a bid for the test hand, and alerts you if your new entry doesn't come up.
Before mucking up your system trying to fix a problem which may not be fixable, we recommend asking someone for advice. A great place to do that is on the rec.games.bridge newsgroup or bridge web sites on the Internet.
1 Team, 2 Systems?
As complex as the BidBase database is, it at least assumes that you and your partner are playing the same way. This is not necessarily a sound assumption.
Larry Cohen says in an article on partnership style that his long-time partner, David Berkowitz, may bid more conservatively than Larry does.
He says that David will open 2 in second seat at unfavorable vulnerability with a minimum such as Qx AKxx AJxxx xx while Larry's minimum would be more like KJ8xxx x QJ9x xx.
At present, BidBase does not offer a way for partners to make the same bids with different criteria.
Perhaps even more interesting in the article is Larry's narrative about how he played 3 wildly different styles (kamikaze, medium, and ultra sound) with different long-time partners.and that one style is not necessarily better or worse than the others.
So ideally, BidBase should provide alternative entries for each style for most bids in the database, but it's hard enough just trying to create all the bids needed for just the "sound" style, so that's BidBase is aiming for right now.
If you want to vary from conventional wisdom, you will need to enter or modify BB bidding criteria accordingly.
The Feb. 2019 Bridge Bulletin had this hand on page 42:
AK4 AKQ -- QT98543 with bidding of 1-P-1-P-??
The 14 top experts agreed that there was not any good bid and they were making the least bad, which included about equal votes for 1, 2, 3N, and 3.
The point is that it is not uncommon to have to make bids for hands which do not have the cards or points the bids normally promise. That's just the nature of the game.
Some people will think that this program is too complicated to use. But the purpose of this program is to allow ANY and ALL bidding systems and conventions to be defined in a database format.
It would be unrealistic to hope to describe the specifications for every possible bid for every possible system and convention without some degree of complexity.
However, this isn't like learning to speak Russian or to perform brain surgery (or to perform brain surgery in Russian). You should find the program relatively easy to use if you first take the time to read the documentation and understand all the implications of the bidding database structure.
There is no reason for it to take any longer to become an expert at this program than it would take to, say, read a single issue of Bridge World from cover to cover.
In addition to this help file, there is a tutorial which you should have run through the first time you ran the BidBase Editor. You can bring it up again at any time by clicking on the main database screen's Help menu. And if you only want a tutorial for a specific menu command, you can find that in the Help menu as well.
Another source of help is the bar at the bottom of the main (grid) window which displays for each input box the type of data to be entered and the format of the data to be used.
Finally, there are also many validity checks included to insure that data has been entered correctly. Nevertheless, it's the nature of the beast that occasional errors will get through. Again, freak not out, because the joy of BidBase is that you can easily fix them.
There are many ways for a computer bridge program to decide what to bid:
As this is being written, prior to the release of BidBase, virtually all bridge programs use software algorithms for bidding. This means that the bids (and the specifications required to make the bids) are written ("hard-coded") into the program code. Even programs which use DDA normally use hard-coded algorithms for opening bids and conventions.
One problem with this approach is that corrections and enhancements to the bidding system are very difficult to make because in addition to the complexity of the bidding systems, you have the complexity of the programming language used to implement the systems.
Whenever changes to the bidding systems are made, the program itself must be modified and the new code debugged. Only programmers can do this, so users cannot modify the bidding system in any way, other than selecting among options hard-coded into the program. While for the novice, programs may appear to offer an overwhelming number of bidding options, the experienced player will find those options fall far short of what they would like to have.
Another problem is that the more sophisticated the bidding systems become, the larger and more complex the program code (and the program itself) becomes, making the code more and more difficult to modify and debug.
So unlike other methods of computer bidding, programs with hard-coded algorithms are more limited in the number of conventions they contain, and they do not allow more conventions to be added (nor bidding errors corrected) by the user.
Another difference is that scripts can be stored in text files while hard-coded means that the bidding algorithms are written into a program, so it is relatively easier to change the bidding for a script-based system than for a hard-coded system. (But we know of at least one program which hard-codes its scripts.)
Script bidding differs from database lookup bidding in that with Scripts, there are not standard fields and records. As previously noted, scripts are created with a language, while with database lookup, entries in the database are created by filling in blanks on a form for such things as HCPs, suit length, etc., thus scripting is harder for the user to learn and scripts are harder to modify than databases.
As this is being written: Script bidding is relatively new. To date, nobody has done an extensive bidding system with scripts. It remains to be seen if it is even possible or if the system will get bogged down once the number of entries reaches the thousands or tens of thousands (to say nothing of the hundreds of thousands, or millions which a database could easily handle).
We have done some research into Scripts which leads us to believe that scripts will not work for defining large, complex systems in the great detail required while maintaining the consistency of the systems when changes are made.
Northern Colorado Bridge has this definition:
In the June 2005 issue of the ACBL Bulletin, a couple of Bridge Baron programmers explained it like this:
|The program imagines possible hands that partner and the opponents might have, based on the bidding so far, and constructs dozens of possible complete deals. Then for each of these deals, the program projects the hypothetical result of playing out the deal...|
The words imagines, constructs and projects are not descriptive of how a program really does any of this. Below is a description in more specific terms. It's possible that Bridge Baron's DDA does not work exactly this way, but it's not possible to tell based on their article.
|1.||Give the cards to the current player which he is known to hold.|
|2.||Randomly distribute the remaining cards to the other 3 players.|
|3.||Bid those cards for each hand and see if those bids match the ones made on the actual, current deal up to the current point.
If they match, then go on to step 4, below; otherwise, go back to step 2.
|4.||Analyze the deal by looking at all the cards in each hand to determine the best contract. (This is where the DDA comes in.)|
|5.||Determine the bid which should be made next with the goal of getting to that contract.|
|6.||Repeat steps 2-5 for as long as the user has allotted for the program to bid.|
|7.||Make the bid most often resulting from the above steps.|
For example, if North deals and the bidding proceeds 2-Dbl-Pass, then to find a bid for West, the computer would give West his known cards first, then repeatedly shuffle and deal the remaining cards to the other three players.
For step 3, above, the program would bid the hands of each of the other players to see if they made the same calls as in the actual deal. If they do not (i.e.: 1st chair doesn't open 2H or 2nd chair doesn't have the cards for a Double or 3rd chair doesn't pass), then that deal is discarded and another deal made.
Only when a hand does result in bids matching the actual bids up to the current point can the DDA proceed to step 4.
The computer may have to generate hundreds of thousand random deals (or even millions) to come up with a sufficiently large sample of matching deals. It analyzes those hands to see what the best contract is on average.
However, DDA does not, itself, make bids. The program still must figure out what to bid next to try to reach the DDA contract. If those algorithms are hard-coded, we have the same problem of the user's not being able to modify them.
This procedure brings with it a number of potential problems. (See DDA-problems.htm.) )
(In an online document, the author of the bridge program, GIB, gives a more detailed explanation of how DDA works.)
CardShark BidBase's approach is to use a bidding database. Instead of bids being hard-coded into the software, they are entered into a database along with the specifications for what a hand must have to make the bid.
Any kind of bridge program using BidBase simply calls the BidBase DLL and passes it the current hand, bidding, scoring method, etc., and BidBase searches for a matching entry and if it finds one, passes back its bid.
If it should turn out in the future that there is a significant bidding method or system which cannot be defined using the existing database fields and look-up routines, then these can be modified by the programmers of BidBase, but this should occur very rarely. Also, such changes are only made to the bidding module, and changes should never have to be made to the various programs which use the bidding module..
In contrast, correction of bidding errors or addition of different bidding systems, both of which can occur quite frequently, can be made immediately by the user of the program rather than hoping for a change by the programmer sometime in the future. And BidBase has extensive features which ensure that changes made by users will be accurate and consistent with other entries in the database.
BidBase is primarily for the implementation of bidding agreements (including bidding systems and conventions). If no agreement has been recorded for what a particular bid means, then the program's DDA (or other bidding methods) should kick in to decide what the best bid is. Then if the user is not happy with that bid, he can modify the database to use a different bid.
Originally, we thought that DDA was the only alternative for finding bids when no applicable entry was found in BidBase. Now we are hoping that a sophisticated hand evaluation system will displace DDA. We are not at that point as of this writing, but see the Hand Evaluation Program documentation for more info.
The advantages of the database lookup approach are significant and there are no apparent drawbacks:
For example, it would be relatively easy to put into a database all of the conventions from the 1100-page book, Bridge Conventions Complete. Relatively easy doesn't mean that it wouldn't take a lot of time, but it would be time spent simply typing in data, while with hard-coding, you not only have to type in the data, but you also have to figure out and type in code to get the program to use the data, debug and correct the code to get it to work, etc.
This is intended as a learning experience, but if you do not agree with the bid made, you can change it. If you think there is an error in the database, you can fix it. Or you can refine the bidding by adding an entry to make a different bid with a more specific set of criteria.
This is all done by filling in blanks with plenty of help available in the program.
In contrast, here is a quote from another program:
If the user thinks "Why did it bid 1 in that situation?" the computer tells them why (in a somewhat cryptic way):
((hcpoint ?hc dpoints ?d (?* ?x) biddable ?s (?* ?y)
(?if (>= (+ ?hc ?d) 14)))
Somewhat cryptic? That's being pretty generous.
Imagine trying to modify a system made up of thousands of rules like that, not to mention the difficulty of keeping changes consistent, and all the other problems mentioned elsewhere.
You can also feed the program bidding problems out of newspaper bridge columns and bridge magazines, and if the program doesn't get the "right" answer, you can modify the database accordingly (keeping in mind that there is not necessarily one "right" bid for any particular hand). Most often, such changes would not be corrections of errors in the database, but refinements to the entries in the database via new entries with tighter specs.
With programs which do NOT use database lookup, you could keep playing them and five years from now, they will bid no better than they do now, and in fact, they would actually continue to make the same silly mistakes over and over. With a database-lookup program, in five years the program could be much, much better at bidding than it is now, and if a silly bidding mistake is made once, it can be corrected and it will NEVER be made again.
And while other programs may not allow you to implement all parts of your bidding system, BidBase not only allows it, but over time, it will also become much more adept at bidding them.
The program could be left running to generate hands and then use DDA where no more bids for a hand can be found in the database. Then it can add the DDA bids to the database. The longer this is done, the more the database builds up and the less often the time-consuming DDA process must be used during actual play of a game.
And during game-play, DDA is usually limited to a minute or two at most for making its bids, whereas in the learning mode, you could give DDA as much time as you want, generally resulting in more accurate analysis.
Another way to use DDA with the database is to play against the computer, and when you are not sure if a database bid is best, ask for DDA. If you like the DDA result better than what is in the database, add it as a new entry or change the existing entry.
You can turn the last procedure around, as well. If DDA makes a bid which you do not think is best, you can make an entry to the database to correct it. Then the next time the same situation arises, the database bid will be used instead of DDA, since DDA is used only when the database does not have a bid for a specific holding.
Now, the odds are against any one exact hand coming up again in the future, but one sufficiently similar is more likely to come up, and the longer you keep doing this, the more such hands you will have covered in your database.
The last advantage of the bidding database is that it provides a very extensive bidding reference source. In comparison (and with all due respect), Alan Truscott's Bidding Dictionary is over 270 pages and only covers two rounds of uncontested bidding and only ONE round of competitive bidding (i.e.: it doesn't even cover rebids by opener in competitive bidding), and not every reasonable set of bids within even that limited scope is covered.
In addition, most books and magazine articles leave gaps or have overlaps in the criteria for bidding. In one book, for example, in the sequence which begins "1-1-P", the following bids are given for the fourth hand:
|1 or 1||7-11 HCP and a 5+ card suit|
|2 or 2||10-14 HCP and a 6+ card suit|
|2||13+ HCP and any distribution|
Note that if you have 10-11 HCP and 6 Hearts, you can either bid 1 or 2, according to the criteria in the book. If you have 13 HCPs and 6 Hearts, you can bid either 2 or 2. Presumably, some unspecified "judgment" of the player is needed to determine which of these to bid.
For example, Bridge World Standard says:
When opening a one-bid in a minor suit: with 3-3 in the minors, always bid one club; with either 4-4 in the minors or 4 diamonds, 5 clubs and a minimum-range hand, use judgment to decide which minor to open.
In the bidding database, gaps and overlaps in bidding criteria cannot be allowed, and "judgment" must be quantified, which has made it much more difficult to encode bidding systems and conventions into this database than to write books or articles which do not have to be so precise in specifying criteria.
In Balancing (page 17, #2 hand.), Mike Lawrence gives the hand QJT8754 A2 3 A97 as one with which he would bid 2 after
However, on the next page, ML shows an almost identical hand, KJ3 QJT8642 AT 5, and says he would bid 3 after 1-P-P. The same suit quality and length, and the same number of HCPs. He even has both sides vulnerable in each case.
So do we have the database bid 2 or 3 of a 7-card major in an 11-HCP hand after 1-P-P? Frankly, I don't know.
This illustrates the difficulties in trying to translate bridge literature on bidding, even by the very best writers in the business, into a database structure. A situation like this normally requires two entries in BidBase, one for a 2-bid and one for a 3-bid, with each bid given a 0.5 in the Percent field unless and until better information is found.
A new (May 2020) project underway will allow BidBase to compute bids not already in the database.
The Practice program generates random deals and calculates the optimum contract for each pair using the Practice program's Double Dummy Analysis
The hand to bid, the prior bids, and the optimum contract is passed to BidBase to look up a bid. If a bid cannot be found in BidBase, BidBase will compute one based on the optimum contract. BB will then add a new entry to the database for the bid, prior bids, vulnerability, etc., and the hand's features (number of cards and HCP in each suit, etc.).
Once this feature is perfected, the Practice program can be left to repeat it for as long as it can be left to run (including stopping and restarting) as long as necessary.
The computed bids are based on a hand's specific features, such as bidding 1 with exactly 5=2=3=3 shape and 12 HCP, another entries for 5=2=3=3 + 14 HCP, 5=2=3=3 + 15 HCP, etc., as well as other distributions such as 5=2=2=4, 5=2=4=2, etc., for each HCP level.
Most BB entries have ranges of numbers for which the same bid can be made, such as 1 entry specifying 5+ spades and 11-21 HCP. We can run software analysis which will look for entries with the same bids (and same prior bids) and combine them into one entry.
This method has several advantages over just computing bids during the play of a deal:
Despite the large number of entries in the database, the criteria for some entries are still relatively broad. This means that as you use the database, you will find hands which are exceptions to these criteria.
The reason is that sources of information about bidding frequently use vague terms, such as a hand of being of "invitational" strength. While that specification may (or may not) be adequate for a human being, a computer needs a specific range of points, such as 11-12 points, in addition to distribution specs.
Even a human, when first learning, lacks the judgment necessary to fill in the gaps in bidding systems left by bridge books. But if he is ever to progress, the human will over time, develop that judgment through experience.
Likewise, as you play a program using this database, you can add new entries with more specific criteria. In this way, the program continually learns to bid better and better through experience, just as a human does.
Example: The HCPs specification for a strong 1N opening may be 15-17, but in the real world, you may play it as (14)15-17, which means that you will open 1N with a "good" 14-point hand.
You cannot change the range in the database to 14-17 because then the program would open EVERY 14-point balanced hand as 1N.
At this instant, you may not be able to say what, exactly, makes a 14-point hand "good enough" to open 1N -- you just know one when you see it. But when playing the computer, if you get such a hand, you could add an entry to the database with that hand's precise specs. That is, you leave the 15-17-point 1N entry in the database, but you add another entry for a 14-point 1N, perhaps entering some number in the "Intermediates" field or that the hand has a good source of tricks in a strong suit, etc.
The odds are small that you would get another hand with those exact specs, but the next time you got a 14-point hand which you would open 1N and it doesn't match your previous entry for a 14-point 1N, you could modify that entry's specs (or add a new entry) to make it include the current hand.
Eventually, as you continue to modify this entry or even add new ones, you should have a pretty good description of a 14-point 1N hand, even though you originally may not have been able to define it very well.
Some people think that a computer is not capable of emulating the "judgment" of a human player, but this example illustrates that just like a human, the computer can gradually "learn" good judgment - e.g.: when to open a 14-point hand 1N and when not to do so. To claim that this process is any different than what a human goes through to develop "judgment" is just human vanity.
Another problem is that most books or articles on systems, such as Standard American Yellow Card, do not provide a complete system. They may tell you the most common bids, such as what to bid over 1N-(2), but not what to bid over 1N-(2N) when you have, say, a 6-card Club suit and 10 HCPs.
Rather than leave holes in the database in these situations, we have put in bids which may not be to your taste. If so, you just need to change such bids as you come across them.
(Actually, it is better to leave an entry which you wish to change in the database and deselect it, then save your modified entry as a new one; otherwise, when your database is updated, Then if you have a problem with the new entry, you can refer back to or reselect the old entry.)
With such a system, you can make one entry which says to open 1NT with 15-17 of your system's Valuation Points (VPs). The system will take into account the factors which make a 14-HCP hand worth 15 or more VPs.
The advantage is that you do not have to manually specify such features for every entry you make because the system does it for you. All you have to do is specify VPs.
Unlike HCPs, which must be adjusted for factors such as distribution, HCP concentrations, bidding of other players, etc., VPs already include those considerations, so a VP rarely has to be adjusted for other factors other than things like specific suit length requirements and specific suit HCP requirements.
Hand Valuation is a good safety net for when no entry can be found in a section which matches the current hand's specs.
The last entry in the section can simply specify that if the VPs are such-and-such, bid so-and-so. Without such an entry a "no bid found" flag would be sent back to the calling program which may use DDA or hard-coded algorithms to generate a bid.
BidBase has several tools to help. You can click on the links below for detailed explanations of each tool. (Hold down the Shift key when you click to open the linked file in a new window.)
One tool is that each entry has a Test Hand which is supposed to meet the requirements for making the bid in the entry it is in. Every time you start the BidBase Editor, it checks each entry in the database against its Test Hand. Every time you save a new or changed entry, it also tests the entry.
If a Test Hand doesn't match its entry's specs, you are alerted and the entry is displayed in the Input Boxes for checking and editing.
If a Test Hand meets the specs for an entry which comes before its entry, you are alerted because when the BidBase Bidder searches the database for a bid for a specified hand, it stops at the first matching entry. So if a Test Hand matches the specs for an earlier entry, it will never get to its own entry.
In such a case, there are three possible solutions:
Here is another example:
The screen shot below contains a newer version of the comparison window in which some other fields have been added, including Test Hands. While this helps compare the conflicting entries, it doesn't have all the data.
You can click an Edit button at the bottom of the comparison window to load one or the other entry into the Input Boxes, but then you can't compare the two entries. Here's a way to do that: In Windows 10 is a little app called Snipping Tool (which may be renamed in the next Windows 10 update).
So I loaded #3350 and used Snipping Tool to copy it, then I loaded #3646 and dragged the Snipping window above it as shown. This lets you see all the detail for both entries at once
The first major fields to compare are HCP and Distrib.Pts.. Although the specs appear to be quite different at first glance, the Test Hand for #3350 has at least 4 distribution points, giving it T14 (Total points = 14) which is within the range for #3646.
Generally, it seems better to show total points required for suit bids and High Card Points for notrump bids, so after seeing this, I changed #3350's entry to blank out HCP and put T12+ in Distrib.Pts..
[later that same day...] Upon further study, it appears that based on the comment about bidding a reverse on the next round, this entry was made in anticipation of making an entry for the round in which a reverse is bid. However, this entry is not needed for that purpose. Any general purpose entry, such as #3646, will do as long as it lets the bidder call 1 of his long suit. So rather than try to fix up entry #3350, I just deleted it.
Because it may be difficult to recognize where overlaps are between conflicting entries, here is another example with explanation:
You may have noticed that the line Position has been added to the Compare Entries window. This line was added because the bidding code was not weeding out entries which had similar specs except for having different Position requirements. However an entry which is only for seat 2 cannot conflict with an entry which is for some other position. Now that the code has been fixed, it should not be possible for two entries to conflict with different positions, thus there is no reason to have this line in the chart and it will be removed. Anyway, Position did not affect this comparison, so on to the analysis of what did.
It's easy to see that Hand Strength is where the overlap is. The Test Hand in the Snipping Tool window has 10 HCPs and 2 Distribution points. Since the bottom entry only specifies HCs of 5-11, the top Test Hand meets the Hand Strength requirements for both entries.
Suit requirements for the top entry are a 6-card suit with 5 HCPs plus at least 1 Intermediate. For the bottom entry, it's a 6-card suit with 1+ HCPs. Clearly the top entry's specs are intended for a much stronger suit, but because the Suit HCP specs for the bottom entry are unlimited, any hand which meets the top Suit specs would also meet the bottom ones. So the top Test Hand would meet the bottom entry's specs and never make it to the top entry.
One possible solution would be just to change the top Bid Order Number of 698300 to something lower than the bottom number of 390000. This would cause the top Test Hand to be compared to the top entry's specs first; it would pass those specs and never make it to the bottom entry. Meanwhile, the bottom Test Hand would not match the top entry's specs and would make it to the bottom entry which it wouuld match and all is well.
A second possible solution would be to change the bottom Suit HCP specs to 1-4; however, there may be hands which have a suit which would match the Suit specs but not the Hand Strength specs and thus would not pass the specs for either entry.
A third solution would be to change the Hand Strength specs.
The "2+" Distrib.Pts. seems unnecessary. When a hand has a 6-card suit, it has to have at least 2 distribution points (e.g.: 6-3-2-2), so we drop that.
That leaves the HCP specs. The top test hand just has 10 HCPs, following the usual procedure for creating test hands which meet the minimum specs. It certainly looks like a reasonable hand for the 3x bid.
We could change the bottom HCP spec to 5-9, but a hand like JT7643-KQ2-J-K54, which is not materially different from the bottom Test Hand, would no longer meet the HCP spec for the bottom entry.
Another tool for maintaining consistency is the set of Dupe entry boxes to the right of the Input Boxes. This is a list of all sets of Prior Bids which are very similar to the current entry's, whether an entry actually exists for each of these sets or not. When you change an entry, you can click on each similar entry's button to duplicate the entry for them.
The second tool is the Dupes Grid in which all the existing entries similar to the selected entry in the top grid are displayed. We strongly recommend that you keep the Dupes Grid active whenever possible, and set to show Similar Entries.
Another tool is the menu option for comparing entries in two grids. This can be used to compare all the entries for two different sets of Prior Bids or to compare a selected entry in the top grid to all the similar entries in the Dupes Grid.
We can pretty much guarantee you that if a program says it has database lookup or scripting for user entry of bidding criteria, but does not offer these kinds of checks, their database will quickly be error filled. This was our experience prior to implementing these features.
As mentioned a few times in these documents, BidBase was never designed to go far beyond a couple of rounds of bidding. SAYC itself only goes through a few rebids by opener, so one-and-a-quarter rounds. (Slam bidding conventions are an exception for both BidBase and SAYC.)
The problem is that it simply is not possible to enter every bidding sequence which can be made because the number of different possible auctions is
The BidBase database does not have a different bidding entry for every possible specific combination of points and distribution for every situation. Instead, it has an entry for ranges of points and distributions which should result in the same bid.
So one entry could cover dozens of different hands with which to make the same bid. And only a small percentage of those possible auctions are realistic. Nevertheless, the realistic auctions are too many to be completely covered using a database approach.
So a refinement of BidBase is that by the time BB runs out of bids, players have sufficiently described their hands to each other (via bidding) such that players can figure out what to bid next based solely on that knowledge.
For example, playing 2-Over-1 Forcing, the bidding goes
1 1N 2 3 ???
At this point, opener knows that responder has exactly 3 Hearts and 11-12 points. Opener's next bid is a function of simple addition. Sort of. There are refinements which could be made, but the point is that these refinements don't require knowing the actual bids used.
With HCPs= Opener Bids
20-21 Ace asking
So say that we have a database which has an entry for each of these bids showing each of these point requirements, and instead of Prior Bids, the bidding would be based upon the number of points and distribution shown by partner and opponents, and the agreed-upon trump suit, plus any bids required by partner's bidding.
It doesn't matter which sequence out of a trillion, trillion possible sequence got us there. It doesn't matter what bidding systems, conventions, etc. have been used up to this point. Just the resulting information revealed by such bidding.
Such a database would actually be a lot simpler than the current BidBase database with just a fraction of the 50+ fields in each BidBase record.
This is actually the same method used for Ace-Asking in BidBase, and it works fine. The only Prior Bid which is shown is 4 for Gerber or 4N for Blackwood and 5N for Grand Slam Force.