Yes, We Have Errors
The BidBase Hand Evaluation Program
System Name List Box
Minimum Bidding Requirements
System Display Grid
Evaluate A Hand
The Data Fields
At first glance, the program can look a little overwhelming, but it's not that bad if all you want to do is evaluate a hand:
Well, maybe a little...
If you want to modify or create a new evaluation system, things become a bit more complicated.
Writing an evaluation system in a programming language is simple (assuming you already know how to program). Trying to create the same system with a series of database entries is a lot harder.
On the other hand, testing and tweaking a system which was written in a programming language is very much harder than with the same system in database format.
Plus, however complicated this all looks, it is a lot less complicated than learning a programming language. Start by entering some hands, computing the valuations, and examining the VP (Value Point) column in the grid to see where the value is being adjusted.
The box at the bottom of the program window explains each column in the grid. Those of you who don't like to waste time reading doc files (and isn't that most of us?) should be able to make entries just following those notes and looking at the other entries to see how they work. When all else fails, you can refer to this file for more detailed explanations.
The reason it's not being done now is that the work being done on BidBase now is almost entirely adding new bidding entries to the database. It is too difficult to figure out how a new entry fits in with past entries just by looking at the custom hand valuation.
It's much easier to understand why and where a new entry is needed by comparing suit holdings, HCPs, etc.
It is conceivable that sometime in the future custom valuations could be added to existing entries, but it seems highly unlikely.
Beginners are taught only the Goren system of 4-3-2-1 points for honors and 3-2-1 for short suits as a means of evaluating hands for bidding.
More experienced players will factor in things like
However, the somewhat amazing fact is that in the long history of bridge and frequent discussions of coming up with better hand evaluation methods, about the most that anyone ever does (in terms of valuing a hand numerically) is try to find a better method of valuing honors, while mostly ignoring all the other factors listed above.
The primary exception to this is the COBRA system, developed by Torbjörn Lindelöf. The Zar Points system, by Zar Petkov, also goes deeper into hand evaluation than others, but just shy of COBRA.
Even these two are not complete. For our own system, BidBase, we used Zar as a starting point, then went through COBRA and other systems looking for adjustments which would be applicable to Zar, and finally, we have started adding adjustments based on other sources.
Although a detailed hand evaluation system is great for computer bridge programs, it is beyond the memory capabilities of most humans.
But even if a human cannot duplicate the exact calculations at the table, studying and working with this program should improve understanding of the finer points of hand valuation which, in turn, will pay off at the bridge table.
The value of an honor is like the value of a dollar -- it depends on what you can get with it.
That value of 3 is the net value of the King (in 4321 honor count) in the play of a very large number of deals (e.g.: millions). Since an Ace always takes a trick (ignoring trumps) and is worth 4, the King, which has a value of 3, must only take 3/4ths of a trick in the long run.
Well, in 1/4th of those million deals, LHO will have the Ace and capture our K when we play it, making it worth nothing. The other 3/4ths of the time, either we, partner or RHO will have the Ace and we will eventually take a trick with the King. It takes a trick 3 out of 4 times and is worth 3 out of the 4 points an Ace is worth. Good symmetry.
So we start with a value of 3, but we have to adjust its value for any of the factors which can impact its value.
For example, a factor in giving the K a value of 4 is that 25% of the time, LHO may have the Ace and greatly reduce the trick-taking ability of our K.
If RHO opens 1H and we have the K, then odds become a lot lower than LHO has the Ace. The stronger our hand, the lower the odds that LHO has an Ace. If we have KTxxx of Hearts open 1H and LHO makes a takeout double and our partner jump-raises Hearts, the odds of LHO having the Ace become neglible.
On the other hand, if LHO overcalls our 1H with 1NT, the odds that he has the Ace become very high.
Because the initial value of the King was based in part on LHO having the Ace 25% of the time, if the bidding gives us strong reason to believe that he does have the Ace, the reduction in value of the King should be 3 times the adjustment made if the bidding indicates he does not have the Ace.
We have been through each one of these systems countless times, even to the extent of indexing each system creator's HTML files with our entry IDs to make sure we covered every specification.
Each time through, we have found errors, either due to our misinterpreting what was written or through faulty logic in the specification entries created to represent what was written.
Naturally, we have corrected those errors and would like to think that we have caught them all, but...
If an entry doesn't seem quite right to you, click System Info in the Help menu, and you can read the basis of each of our entries. The info files also contain links to the system creator's original file(s).
Even if we got the system creator's intent right, maybe you have good reason to believe that he is wrong. (Nobody's perfect.)
Any errors you find, as well as suggestions or improvements, we appreciate hearing about. See the contact information at the end of this file.
Okay, just HEP.
HEP consists of a database which contains the specifications for a number of existing hand evaluation systems. HEP also includes a program for viewing, testing, and modifying those systems, as well as for creating new systems.
The good news is that HEP makes working on evaluation systems a lot easier.
The bad news is that "easi-er" is not the same as "easy". Designing hand evaluation systems is very complex and difficult. If it were not, somebody would have nailed it by now.
Probably the best way to go about it is to start a system by copying one of the existing ones that you like best (how to do this is discussed below), then when you find hands which pros bid differently than is indicated by your system, analyze the hand to see why and make an entry to change the hand's valuation. This is what we have done with the BidBase system.
But even if you do not want to work on creating or improving hand evaluation systems, you can just use HEP to evaluate hands using the existing systems.
When you add a new system, it will automatically appear in the list box.
If you leave the System Name box on 1.All, then when you compute the value for a hand, it will calculate and compare all systems.
When you select a system, you can click Help - System Info to get details for each entry for the system.
Here is a brief summary of the systems:
Below are some comparisons of hand distributions using several systems. Percentages are the percent of each system's VPs divided by its minimum VPs required to open 1S.
Some hand evaluation systems try to keep to Goren-level bid strengths, such as 13+ to open, 6+ for 1/1, 10+ for 2/1, 22+ for 2C, etc. Other systems value honors and/or short/long suits higher, so their point requirements for those systems are higher.
Filling in these boxes is not required. They are for reference only, and do not affect computations. However, when you do a comparative computation of all systems, one column shows the value for each system as a percent of the minimum value for a 1-level major suit opening bid as a means of comparing results of differing point ranges, so you should at least fill in that one box.
Some numbers cover more than one type of bid, whether stated or not. The minimum for a 1/1 Response is also the minimum for a simple raise.
As noted on the form, the numbers for Game and Slam are the total points for both hands, based on the actual points in the current hand and the expected points from partner based on his bidding (or in this program, the strength entered).
Opening notrump ranges are rarely, if ever, changed by hand evaluation systems. Systems may revalue honors or hand shape for notrump, but only for purposes of bidding within the standard NT framework.
For example, a balanced hand with 16 HCPs may be downgraded to 14 evaluation points or upgraded to 18, suggesting that you should not open the hand 1NT, but the 15-17 range for a strong notrump would not, itself, be changed.
The same applies to suit contracts. If a system specifies 13 VPs to open, then a 12-VP hand should never be opened. If everyone says that it should be, then find out what makes it worth more than the system is currently valuing it at, and make an entry to adjust for whatever that feature is so that it is worth 13 VPs.
As a matter of fact, you want to find hands which are exceptions to the database results because making new adjustments for them is exactly how a system should be expanded and improved.
On rec.games.bridge, someone said that this wouldn't work because people have different styles of opening -- e.g.: light or super-sound. This is not a valid objection because it is talking about styles of bidding, not styles of valuing hands.
For example, if your system calls for you to open a hand with 13 points but you get a 12-point hand you think is worth opening, then you should determine what about the hand makes you want to vary from the minimum and make a rule to adjust for it so that the hand's rating fits your minimum opening bid requirement. Then you are no longer bidding "light"; you are bidding just what your system says to bid.
You can edit data in the grid, but be sure to read the rest of this file first. Any changes you make are saved as soon as you move from one row to another. If you accidentally change something, if you haven't left the grid cell yet, press Esc.
File Menu Items:
Back up the BB-HEP.mdb database file before starting to work on it. Any changes made in the data grid are saved as soon as you cursor up or down to another line. The only ways to recover from a screw-up are to retype the original data or to have a backup.
Copy a system to a new name within the database before working on it, even if you don't intend to create a new system. Doing this is fast and easy, and if something goes haywire, you have the original to refer back to.
In fact, in case of a massive screwup, you can just delete the system name of the working copy. If things go well, when you are done, you can delete the original and copy the working copy back to the original name. You can leave the working copy there for future work, or you can delete it.
Starts a system from scratch. You will be prompted for a new name and a starting entry will appear in the grid which you can modify and add to. Note that you are not creating a new database, just a new set of entries in the existing database.
When all systems are displayed, they are sorted by ID. If two different systems start with the same letter followed by the same number range, their entries may be intermixed.
So before starting a new system, look down the list to see if another system has the same first letter in its name (or worse, has the same name). If so, you may want to choose a new name so that the IDs will start with unique letters. Alternatively, you can start the IDs with two letters to make them unique.
A system name can be up to 10 characters long. If you create a new system, you can click on System Info in the Help menu to create an information file for it.
The editor provided for this purpose is an HTML editor (and the info files are HTML files). If you don't want to mess with HTML code, go down to the blank area of the file that comes up in the editor and enter <PRE> before you start typing and everything below that will be displayed just as you type it without any further HTML invocations.
Incidentally, the HTML Viewer/Editor is the program you are in now, if you brought up this file from the program. If so, press F11 to display the HTML source for this file, and F11 again to hide it.
Hopefully, you will want to take a crack at improving existing hand evaluation systems. If you make changes to an existing system and then mess up, you may not be able to get back to the system's original entries.
To modify a system, pick the system in the System Name list box, which will cause its entries to appear in the grid, then click the Copy System in the File menu. Copies of the original entries will appear in the grid with the new name you give them.
When you copy a system, you are just creating duplicate entries in the database with the new system name on them.
The Delete System function is intended for systems you have started but want to erase. The existing systems should be left in the database for future reference, although if one particularly annoys you for some reason, you can delete it.
In the data grid, changes are saved automatically when you move from one row to another. To save changes in the Minimum Bidding Requirements, you must use this menu option.
Edit Menu Items:
Select a row in the grid which you would like to copy, then select this menu option or press Ctrl-K. You can copy it to another system or within the system, giving it a different ID.
Select a row in the grid which you would like to delete, then select this menu option or press Ctrl-D.
When you add a new entry, it normally stays at the end of the grid until you reload the system into the grid.
To move a new entry into alphabetical order without reloading the system, click the Re-sort menu option or press Ctrl-R.
System Info Files (Ctrl-I)
Each system has an information file which has been extracted from the system creator's original file(s) so that we can link each entry to the creator's specifications.
The file will open up to information about the entry you are on in the grid. If you open an info file and press Ctrl-I again for the same system, a new viewing window will open, so you may end up with multiple file viewers open.
Each info file also contains a link to the system creator's original web files and web site, when available.
When a calculation has been done for an entered hand, the Value Points, if any, for each entry in the system, are shown in the VP column at the right of the grid.
To see an explanation for an entry, look in the system's info file for the entry's ID.
To evaluate a hand for an opening bid:
Here are some features which make entering hands easier:
While pasting in a hand may circumvent the immediate validity testing, such testing is done again before a computation is done.
Valuation systems which do not take other players' bids into account are basically only good for opening bid evaluation.
This observation is not intended to denigrate such systems, because they contain many good ideas for evaluating hands, but the fact is that subsequent bidding does affect the initial valuation, and cannot be ignored in a complete valuation system.
Normally, a bridge program would examine the bidding and deduce the other player's strength and distribution to the extent possible. In the BidBase bidding program, from which this program was extracted, that is what is done.
Since we don't have a bidding database to draw on (that program is not ready for prime time yet), we need you to enter the the strength and suit lengths which would be indicated by the bidding.
Normally, the program can get data about the current hand from the cards entered. However, if necessary, you can override the program's analysis of the current hand by entering suit lengths, Help suits, Fit suits, etc., manually as you do for other hands.
Enter the minimum expected strength of the hand for a bid by selecting from the drop-down list box. If a bid may be made with different strengths of hands depending on different factors, select the minimum expected strength and use it for all entries for the same bid, even though the criteria for other entries may specify a stronger hand.
For example, a takeout double ("TOX") usually promises support for each unbid suit and about opening strength or greater. But with a very strong hand, you could TOX with a one-suited hand, intending to bid your suit over any response by partner. But neither your partner nor opponents are entitled to know exactly which type or strength of hand a specific TOX is based on.
When partner makes a TOX, you start off playing him for about opening strength, until subsequent bidding proves otherwise. So you would enter O to indicate an Opening strength hand.
Below are the strength levels used, the point ranges shown are approximations, hence some overlaps. If you open 1NT with 12-14 HCPs, for example, you would have to enter O, since that is the closest range.
Also note that these points are can be HCPs, but are not necessarily. More often, they will be the playing strength (or Total Points) of a hand.
Think of "I" also as Invitational -- the strength when you might invite opener to game. Opening strength includes Weak NT's and 2/1 Game Force bids.
The Plus relates to opening strength Plus about a King. It is also, conveniently, the range of a strong 1NT opening. A Precision 1C also falls in that range.
Strong is about the range where responder would jump-shift and where opener would jump-rebid. Very Strong covers opening 2NT and 2C.
We have experimented with a number of different strength classification methods over the years. This method is not perfect, but none is, and this has worked the best.
Strength specifications are made in the Hands specs field in the entries.
NT (Bid) Checkbox:
If a player has opened 1NT, check the NT box.
In the Str, enter the normal, expected minimum point count for 1NT, such as 15 for a 15-17 NT. This does not have to be the same as the 1N Notrump Range shown for Minimum Bidding Requirements, which is simply the range for a strong 1NT.
Dealer -- Enter N, S, E, or W, where S=South (hand entered), N=North (partner), W=West (LHO), E=East (RHO).
Bidding -- Enter bidding as a continuous string of bids separated by dashes ("-"). Use the following abbreviations:
Even though the hand strength and suit lengths are entered separately, the program may still need the bidding for other types of information.
Click Compute to compute the hand value for the data entered and for the system selected. (Or you can usually just press Enter.) The hand's value will be computed for the selected system and the results for each line added in the VP column on the right side of the grid.
Total VPs are displayed in the Suit VPs and NT VPs boxes below the Compute button. Entries going into these totals are determined by the settings in the NT_or_Suit field.
To see where the total VPs are coming from, look down the VP column in the grid. If an amount in that column doesn't seem right to you, click the System button to bring up a file which links each entry to the system creator's specifications. If you believe that the database is in error, please report it to us. See the Contact info at the end of this file.
The VP column in the grid is automatically cleared whenever you change systems or click the Compute button again or quit the program.
To see a comparison of values computed for all systems, select 1.All in the System Name list box before clicking Compute.
A box will come up to display the results by system, showing the VPs for a suit contract, the Suit VPs as a percentage of the specified minimum for opening 1 of a major ("%/1M"), and the VPs for a NoTrump contract.
The %/1M column makes it easier to compare the results of systems which have widely differing point requirements for opening, raising, etc.
Example: enter the hand QJT32-K432-A32-K where LHO has opened Hearts and partner has shown 5 Spades, short Hearts, and a Diamond Help suit and you get the following:
Without the % column, you could not meaningfully compare the VPs for each system. For example, COBRA's VPs are 1 less than TSP's, yet COBRA's rating indicates about a 40% stronger hand than TSP's rating indicates. To see why, check out the entries for each system, as well as their info files (from the program's Help menu).
BB-HEP.mdb is a Microsoft Access database. If you have MS Access, you could modify the database, but if you change the field definitions, the database may no longer work with this program.
The HandValBidReq table in BB-HEP contains the Minimum Bid Requirements for each system, as shown at the top of the program window.
The HandVal table contains the evaluation specifications ("specs") shown in the grid.
To create a new entry in the grid, first select the system, then scroll down to the last entry in the grid (not necessarily the last entry displayed).
Click on the ID for the last entry, then press the down cursor to move to the blank line with the asterisk on the left. This will start a new line with the previous line's ID incremented by 10. You can change that ID if you wish.
When you are done entering specifications, press the up cursor to go the prior line or click on a different line. The icon in the left column will change from a pencil to an arrow, indicating that the entry has been saved in the database. An entry is not saved until you move to a different line, and then it is saved to the database on your hard drive.
The Save Changed Reqs. button at the top of the screen is not for saving grid data; it just saves changes to the Minimum Bidding Requirements.
To create the specifications for an entry, you must use the codes and numbers as described in the next section, or the entry will not work.
If you are unable to make the type of entry you need with the existing codes, send a message to explain what you need. See the contact information at the end of this file.
Give entries IDs which, when sorted, will put the entry where you want it in the list. This is to make the entries easier to review; it has no effect on the computation, other than entries with Flags must be before the entry which tests the value of the Flag, obviously. You can change existing entries' IDs at any time.
We have incremented entries by 10 to allow for entries to be inserted between existing entries. Likewise, when creating a new ID between existing IDs, split the difference in the numbers to allow new entries on either side; e.g.: between K1120 and K1130, enter K1125, not K1121. An exception is if you are making an adjustment which requires multiple entries to complete. In that case, increment the numbers by 1 to keep them together.
Back up your database regularly. We use a free program by the name of Cobian Backup. It Zips up selected files and directories each night while we sleep and copies the Zip file with the current date in its name to an external hard drive. This process has saved our bacon numerous times.
The fields in HandVal are: