Introduction and Background
To open a linked file in a new window,
The executable versions of the BidBase programs described in these files are not ready for distribution.
= Diamonds or Clubs.|
= Hearts or Spades.
Links to web pages for more information are sometimes given, followed by an archived page link. 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.
Hold Shift and click on a Web link to bring it up in your browser. Use the browser's File - Save As menu command to save the file to the Archives folder in your BidBase\Notes folder. Give the file the name shown in the link. After you have done this, you will then be able to view the archive file without going online.
If you follow these steps and an archived link does not work, either it was not saved to the Archives folder or it was not given the name shown in the link. You can use Windows' My Computer to look for the file to rename it or move it if necessary.
I have been using CSBB File Viewer/Editor for many, many years to create documentation files as well as Web sites for myself and for several organizations. It has a very large number of features for creating fairly sophisticated (if not guady) Web pages.
The source code can also be used as a guide for putting a web browser into your own programs. Any features you don't want to include can easily be omitted.
Set-up: Create a folder/directory for the programs wherever you want them. The documentation and note files should go in a Notes folder inside your program folder. You can put the programs and source code all in the main/program folder.
There is no copyright or licensing. 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 on the BidBase pages on SourceForge.
If anyone wants to try to make money selling the files, more power to you - if you can get someone to pay for the files while I'm giving them away, then they must have been unaware of MY efforts, so you have provided a service, but download the latest versions now and then.
The BidBaseDB.DLL file is a bidding module which could be added to any bridge software (I think) and used to provide bidding for that software. It is also free.
The primary purpose of BidBase is to create a system in which criteria for making bids in the game of Bridge can be stored in a user-editable database.
Reviews of Bridge games invariably contain complaints about the bidding in general as well as the lack of support for common conventions and bidding systems. Any types of bids or conventions not already in BidBase can be added using the BidBase Editor. The Editor can also be used to correct errors in bidding or to modify the criteria for making specific bids.
Any bids, systems, and conventions can easily be activated or deactivated by the user.
The BidBase system includes a program for practicing bidding which uses the bidding module. The Editor allows entering a bridge hand, prior bids, vulnerability, etc., and finding a bid for it. Various other related programs are also included in BidBase.
At this time, most bidding is 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.
Most of the bids in BidBase are based on recommendations by top experts as expressed in bridge books and magazines. Except for relatively few situations, later bids do not get the same kind of attention and so there are few or no specifications to support such bids which is why bidding doesn't go much beyond a couple of rounds.
On the simplest level, the BidBase can be set to bid 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.
Other systems which can also be selected include Bridge World Standard, Precision and 2-Over-1.
These basic systems can be added to by checking off conventions from the database grid in the CSBB Editor program. 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.
CSBB is extremely simple to use. You click on the system and conventions you want to use (and optionally, those which you want your opponents 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
The database can be modified by adding or changing entries to your own preferences, which makes it possible to include any type of bid or convention you wish. For example, slam bidding conventions were only recently added to BidBase and presented some unique challenges but ultimately was done by using the existing database fields without having to make changes to program code.
In order to be able to do 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 over 50 fields which can be used to describe the hand though typically an entry uses fewer than a dozen of these fields.
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 or entered by the user for each new or changed entry and when saving 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.
In addition to the documentation files, 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 at any time.
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 in the database. 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 if for no other reason than that a hand may match the criteria in your new entry, BidBase will use the entry's bid and never get to the bids that come after yours in the database,
So one needs to be careful when changing, adding, or deleting entries.
That being said, the CSBB 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, CSBBE will search for a bid for the Test Hand in your new entry. If it finds another entry matching your criteria before it gets to your new entry, it will alert you.
Sometimes, you may have to rearrange the order of the entries so that your new one comes before the other one. The entries for Roman Key Card Blackwood responses are in reverse order (higher level bids come first) because there was no other way to get around multiple entries containing the same criteria.
Another check which CSBBE performs is that every time you start the program or change the range of entries to be displayed in the grids, CSBBE will test each entry in the grid to make sure that entry criteria do not overlap and that each entry's Test Hand stills brings up that entry.
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 valid 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
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 all I'm aiming for right now.
If you want to vary from conventional wisdom, you will need to enter or modify BB bidding criteria accordingly.
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:
A program can "cheat" by looking at the cards in the other hands to decide what to bid or play. A cheating program does not bid or play in a natural manner (e.g.: it may make an abnormal bid because it can see that the bid will work on a particular hand, even though statistically, it is not the best bid), so it is not a very satisfactory method of computer bidding, and it is completely ineffective as a learning tool.
"Random selection" is also ignored here because it also does not result in a satisfying bridge program (even though you may feel that many of your human partners use this method).
To the best of our knowledge, none of the latest, major, bridge-playing programs cheat nor use random selection. Following is a discussion of each of the other methods of computer software bidding.
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. Read the reviews of Bridge programs on Amazon and you will see many complaints about the limitations of the bidding systems and/or the poor bidding the programs do.
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 (you know, like Russian), 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:
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 a 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 50(%) in the Percent field unless until better information is found.
Other Bidding Databases:
When work on BidBase began in the late 1980's, no bridge playing programs used player-editable bidding databases ("PEBD"). The original plan for BidBase was to create a standard bidding database which could be used by all bridge playing programs.
However, as work on BidBase has dragged on over the years, a few programs have begun using PEBDs.
We leave it to others to compare these to BidBase in these important areas:
There will probably always be a need for new entries as bidding theory evolves and new conventions are created.
The most important features of BidBase are those designed to insure that new (and editied) entries are accurate and consistent with other entries in the database.
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. (Hopefully. There's an old expression that if two people do the same tasks for 10 years, one may have 10 years of experience - meaning he has continued to learn and improve over the entire 10 years - and the other has "1 year of experience 10 times" - meaning that he has not continued to learn and improve; he just repeated what he learned the first yeaar.)
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 can.
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 build up 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.)
The first 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.