CardShark BidBase
Hand Evaluation

Version 1.0 -- February 2006


Contents:


Not As Bad As It Looks!!

    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:

    1. Enter a hand in the My Hand box, highlighted in red,
    2. Select a system name or 1.All in the System Name box, and
    3. Click the Compute Value button, also highlighted in red.

    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.


Background

    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

    • Controls,
    • Hand shape,
    • Isolated honors (i.e..: singleton or doubleton),
    • Number of intermediates (9's and 10's),
    • Concentration and combinations of honors,
    • Effect of other players' bids on our honors,
    • Length of our suit and/or partner's suit,
    • etc.

    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.


What Is An Honor Worth?

    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.


Yes, We Have Errors

    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 the System info button (bottom, right of the window), 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.


The BidBase Hand Evaluation Program with Computer Analyzed Theory

    Well, that title is too long, so let's call it HEP CAT.
    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.


System Name List Box

    When the program starts, the cursor is in the System Name drop-down list box. You can change systems with the up and down cursor keys, or you can click on the down arrowhead button to the right to get the list to drop down and then click on a system name.

    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:

    • BidBase was started by copying the Zar system and adding entries from other systems where applicable. Now we are in the process of adding entries from other sources. Like Zar, it uses 6421 honor count and long-suit count.

    • COBRA is a 4321 honor valuation system and counts long suits for opening bids. It counts short suits depending on the bidding of other players. COBRA normally has the highest hand valuation as a percent of minimum opening bid. This means that you will open a lot more hands, bid more slams, etc., with COBRA. Gut feeling says this probably isn't right.

    • Fifths is strictly for valuing honors for the purpose of bidding 3NT contracts.

    • Goren is presented for reference. It is 4321 high card points plus 321 distribution points.

    • KNR counts 321 for AKQ, but it adds more points for honors based on the length of the suits they are in. KNR also counts 321 for short suits. KNR does not make adjustments for the bidding of other players, so it is primarily of benefit for opening bids.

    • Pavlicek uses 4321 honor count and 321 for short suits, except that when honors are in short suits, you take the honor points or the shortness points, but not both. Like KNR, it does not take the bidding of other players into account.

    • TSP uses 6421 honor count and 531 count for short suits. It does not consider bids of other players.

    • Zar is a 6321 honor count system. To that is added the length of the longest suit minus the shortest plus the length of the two longest suits. The worst hand you can have, 5432-432-432-432, is 8 VPs -- 4-3=1 plus 4+3=7. A 7-4-2-1 hand is worth 17 points without any honors (7-1 + 7+4).

    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.

      HandDist. ZarGoren TSPK&R
      AK432-K432-J432-5440 111%107%115%117%
      AK432-K432-J32-25431 103%100%105%108%
      AK432-K432-J2-325422 100%100%100%107%
      AK65432-K32-32-27321 115%100%115%129%
      AK5432-K432-32-26421 111%100%110%119%
      AK432-K5432-32-25521 107%100%110%116%



    Minimum Bidding Requirements

      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.


    System Display Grid

      The grid displays the system selected in the System Name List Box. When a calculation is done for a grid, the value points are shown in the VP columns on the far right of the grid so that you can see where the points are coming from.

      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.


    New System

      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.


    Copy System

      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.


    Delete System

      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.


    Save Min.Bidding Requirements

      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:


    Copy Grid Row

      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.

    Delete Grid Row

      Select a row in the grid which you would like to delete, then select this menu option or press Ctrl-D.

    Re-Sort Grid By ID

      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.

    Whirl (Ctrl-W)

      This is just a little something to relax your mind while mulling over your system.

    Help Menu

    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.


    Evaluate A Hand

    Current Hand

      To evaluate a hand for an opening bid:

      1. Select a system or select 1.All to see the hand valued by all systems.
      2. Enter the hand in the Current Hand box.
        Use the format A972-K86-QT4-J83.
      3. Click Compute Value.

      Here are some features which make entering hands easier:

      • Letters automatically uppercased.
      • Validation of each card entered.
      • Space bar inserts a dash ("-").
      • Only 13 cards are allowed.

      While pasting in a hand may circumvent the immediate validity testing, such testing is done again before a computation is done.

    Players' Hands

      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.

      Hand Strength:

        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.

          DescriptionPoints
          B =Bust0-5
          W =Weak6-10
          I  =Intermediate10-12
          O =Opening strength 13-15
          P =Plus15-17
          S =Strong18-19
          V =Very Strong20-24
          X =eXtreme25+

        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.

      Suit Specifications:

      • Bidder's main suit: Enter the expected (most frequent) length of the bidder's main suit(s). Even playing 4-Card Majors, responder normally bids as if opener has 5. A Weak-2 bid might be made with a 5-, 6-, or 7-card suit, but the length expected the majority of the time is 6, so that is what you would enter.

        If Pard opens 1, then you would enter "3" for Clubs because that is a common minimum, but for 1, you would enter "4" if you play that you open 1 with 3-3 in the minors and would only open 1 with 3 when 4=4=3=2. You can lower or raise either of these numbers if you prefer.

        If RHO overcalled 1 with 2, Michaels (showing the majors), you would enter "5" for both Spades and Hearts, since that is what the bid normally shows.

        If LHO opens and the bidding goes 1-Dbl-2-P, P-Dbl, you can give partner 4 cards in each of the unbid suits. He very well may not have them, but you normally respond as if he did.

        For opener (LHO), you would enter "5" in Hearts and his partner (RHO), "3F", as explained next:

      • Raises: Enter the expected minimum length for the raise, followed by an "F" (as in Fit), such as "3F" for a raise of 1S to 2S.

        If responder makes a fit-showing jump-shift, you would enter the expected length of his jump suit with no suffix and the expected length in the fit suit followed by "F". (We have to use "F" because the more natural "R" is used elsewhere to show Rebiddable suits.) Example: 1-P-2, enter "5" for Spades and "4F" for Diamonds.

      • Help suits: Enter "H" for a Help suit. Example, if bidding has gone 1-P-2-P, 3, then for opener enter "5" for Hearts and "H" for Diamonds. (Don't enter a number with "H", just "H" by itself.) For responder, enter "3F" for Hearts.

      • Short suits: Enter "S" for short suits (with no number). Example of unopposed bidding: 1-4 (Splinter), for responder, enter "4F" for Hearts (the Splinter promises 4+ trumps) and "S" for Clubs to show a singleton or void.

      • Cue Bid of A/K: Enter "C".

        A lead-directing double is, in effect, an honor-showing cue bid, but it also may show some length, to avoid having the opponents pass it out to play.

        But when you enter length, the program normally assumes that the player also has honors in the suit, for purposes of upgrading and downgrading honors in the current hand, so entering a suit length, such as "5", has the effect of entering "C" for a Cue bid, but has the advantage of showing the length as well.

      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 and Bidding

      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:

      • C, D, H, S -- the suits
      • N -- Notrump
      • D -- Double
      • R -- Redouble
      • P -- Pass

      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

      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.


    Compare System Results

      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:

        System VPs %
        Zar 34 130%
        TSP 20 105%
        COBRA 19 146%
        Goren 15 115%
        Pav. 14 107%
        K&R 12.5 103%

      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).


The Database

    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 Data Fields

    The fields in HandVal are:

  • ID# -- for keeping the fields in order for editing and viewing. Use the first letter of the Name to start the ID, but if another system is already using that letter, use the first two letters. It helps when naming a new system not to use a name similar to one already in use.

  • Name -- name of the evaluation system, such as KNR, COBRA, etc.

  • Description -- of the valuation entry. Makes it easy to see what the entry is for.

  • NT_or_Suit --
      Enter S if this entry is for suit valuation,
      Enter N for notrump oriented hands.
      Leave blank to use an entry for both.

    Example:

    In Zar, all entries are marked for Suit valuation because Zar is designed solely for unbalanced hands, per Mr. Zar, himself.

    However, after copying Zar into the BidBase system, we added some NT type of adjustments from other systems, so we went back through the entries in BidBase and took out the "S" for entries we thought should also apply to NT, but because Zar says to use 4321 valuation for balanced, NT hands, we left the 6421 valuations marked "S" and added 4321 entries for "N".

    We added standard opening NT ranges in the Bidding Requirement boxes at the top of the screen for reference (they do not affect computations). Now when we do a BidBase computation, we can see whether a hand with 15-17 HCPs still should be opened 1NT.

    KJ32 KJ6 K62 A73 has 15 HCPs, but only 14.5 BidBase NT points. As previously noted, you may open a "good" 14-HCP hand 1NT because HCP values do not take other factors into account, but there is no such thing as a "good" 14-VP hand because all features of the hand which affect its value are supposed to be documented and adjusted for in the database.

    If some feature of the hand makes it worth enough to open 1NT (15 VP, playing strong NTs), then make an entry for that feature in the database to bring this particular hand back up to 15 VP.

  • Value -- Normally, this is an amount to add to or subtract from the hand valuation total, but it can be left blank if you are using the entry just to count a feature via the Flag field. Values can simply be some number, but these codes are also available:

    • .4*n = .4 times the length of the suit. This is just an example. Any value times n can be used.

      If the Length field has something such as n>5, it means the length of the suit greater than 5, so with a 7-card suit, the value would be .4*(7-5) = .8, or whatever calculation is specified in both the Value and Length fields.

      If the Length field just has n by itself, then the entire suit length is used.

    • L-S = Longest suit length minus shortest suit.

    • L1+L2 = Longest suit plus 2nd-longest. (Note that L1 in other columns refers to LHO's 1st suit, while here it refers to the current hand's longest suit. A necessary evil.)

    • T-S = Trump suit length minus shortest suit.

    • .25*HCP = .25 times the suit's 4321 HCPs. The number can be anything, not just the .25 shown.

  • Flag -- You can keep track of when specifications have been met for one or more entries by creating a Flag for the entry. The Flag identifier can be any unique set of letters and numbers.

    Then you can test for the value of the Flag, such as B1=0, B1>0, B1=2, etc.

    Example in BidBase:

      Entry B1650 deducts for a Q in LHO's suit, but if the Q is in a short suit, 1 point has already been deducted in B1540-1560, so a Flag (bQ) is set in those entries.

      Then if the flag is 0, entry B1630 deducts 2 for the Q; otherwise (bQ>0), B1640 just deducts 1, since the other 1 point of the Q's value has already been deducted.

    Example in COBRA:

      Entry C1180 says to deduct 1 point if a hand does not have a biddable suit. Writing such a rule would be extremely difficult without the use of flags.

      With a flag, it is easy. Entries C1110-1120 look for biddable suits in the hand (as defined by COBRA) and the flag C2 is incremented for each one found (though in this case, all we care about is if the flag is 0 or >0).

      Then entry C1180 checks the flag and if it is zero, indicating that the hand has no biddable suits, 1 point is deducted.

      Note that entry C1580 has no Value. It serves simply to count 5-card suits in the hand for Flag C3, and if C3=0, then entry C1590 deducts 1/2 point.

  • Position -- is the position of the current bidder (for the hand entered), starting from the dealer. If RHO is dealer, then the current bidder is position #2.

    • 2-4 -- the current hand is in seat 2, 3, or 4.

    • Opening bidder can optionally be specified by adding L, P, or R, for LHO, Partner, or RHO. For example,
        4L -- we are in 4th chair, LHO opened, while
        2-4R -- 2nd, 3rd of 4th chair, RHO opened.

    • Suit(s) bid or not bid may be specified by appending the suit letter to the end, with or without a minus sign to indicate NOT bid. Example:
        2-4R-S -- current bidder is in chair 2, 3, or 4,
             RHO opened anything but Spades.


  • Hands -- allows specifying features of players' hands. Hand strength for other players is entered in the What The Bidding Has Shown section. For the hand entered ("My Hand"), you can specify either standard High Card Points (HCP) or Valuation Points calculated to the point of that entry.

    Use the following format:

    • Enter all characters without spaces.
    • Multiple specs should be put into multiple entries
          with Flags, if necessary, to unite them. (See B1860-1862.)
    • Where L (LHO) is shown below, substitute
           R for RHO and
           P for Pard and
           M for Me

    • Enter hand strength required.
      • L<O = LHO has less than Opening strength.
      • L=S = LHO has a Strong hand.
      • L>W = LHO has a greater than Weak hand.
      • L<>I = LHO does not have Intermediate strength
      The next 3 are for the Current Hand only:
      • VPS=25 = My Hand has 25 Suit VPs at this point in the calculation. (See Zar/BidBase's last entries.)
      • VPN=26+ = My Hand has 26+ NT VPs at this point.
      • HCP=10+ = My Hand has 10+ HCPs.

    • Specify suit/NT holdings:
        e.g.: "L=Spds", "LS=Clbs", "LS=Hrts", etc.
        Use a minus for not (e.g.: -L = LHO didn't bid)
      • L = LHO's suit. "L" = any suit or enter:
      • LC = suit in which LHO cue bid an A or K.
      • LN = LHO bid NT (used alone or to show minimum end of range, such as LN=15)
      • LR = LHO has shown a Rebiddable suit.
      • LF = LHO has shown a fit for RHO's suit.
      • LS = LHO's Short suit (singleton or void).
      • MS=0 = My Short suit is a void,
      • MS=1 = My Short suit is a singleton.
      • MS=2 = My Short suit is a doubleton.

    • Compare two players' hands:
      • MS < > L = My Short suit < > LHO's suit.
      • MC < > L = My Cue bid suit < > LHO's suit.
      • M < > LS = My suit is LHO's Short suit
      • M < > LC = My suit is LHO's Cue bid suit.
        P may be substituted for L or M.
        R may be substituted for L, but not for M.
        E (Either opponent) may be substituted for L.
        '=' may be substituted for '< >'.

  • Fit --
      N -- you have not established a fit.
      Y -- you and partner have a fit,
      YC, YD, YH, YS -- fit is in the specified suit.
      (Used when there may be more than one fit or if you want to take the adjustment only with a fit in a particular suit. See P1200-1210.)

  • Suit --

    A border separates the Suit, Cards, and Len columns from the other columns for two reasons --

    • The amount in the Value column can be added up to 4 times for an entry -- once for each suit which meets the specs in these 3 columns. If these 3 columns are left blank, the value can only be added once if it meets specs in the other columns.

    • These 3 columns are interrelated. If the Suit field is left blank, then the Cards and Len field specs are applied to all suits; otherwise, they are only applied to the suit(s) specified in the Suits column.

    Below are the codes which can be used to specify the Suits to be tested. Any of these can be reversed with a "-" minus sign. For example, "P1" says to test only the first suit indicated by Partner, while "-P1" says to test every suit except that suit.

    If Len="5+" and the Suit spec is "P1", then if the current hand has 5+ cards in its first suit, the hand gets the Value specified.

    A suit spec of L (LHO), R (RHO), E (Either opponent), P (Partner), or M (Me) indicates the specified player's suit. For example, if you enter 5 in LHO's S box and no higher numbers in other suit boxes, then L's suit is Spades.

    F, by itself, means any suit in which a Fit has been established between the current hand and partner. F may also be used with a specified player as explained below.

    If a second letter is appended to a player specification letter, it has one of these meanings:

    • 1 -- player's longest/primary suit
             (e.g.: P1 is Partner's longest suit).

    • 2 -- second suit bid/shown. (E.g.: with a 2nd bid or in one bid with Michaels, Unusual NT, etc.)

    • R -- a suit shown to have Rebiddable length.

    • F -- a suit in which a player has shown a Fit by raising his partner's suit (e.g.: EF = a suit in which Either opponent has raised the other, LF = LHO raised RHO, etc.).

    • H -- a Help suit (game invitation made by showing a second suit after being raised).

    • W -- a player's Weak suit (or Western cue bid suit: NT try which asks his partner for help in the suit).

    • S -- a player's Short suit.

    • C -- a suit in which a player Cue bid an Ace or king.

    Specific suits can be indicated in the Suit field:

      Spds, Hrts, Dias, Clbs

    The following codes can be used to test for a concentration of points in the current hand:

    • A3 -- All points are in Any 3 suits.
    • A2 -- All points are in Any 2 suits.


  • Cards -- This is the trickiest field to specify because you have to be careful that your specifications net all the cards you want without unintentionally meeting the specs of some other entry as well. At least if this happens, you can easily spot the results on the grid in the VP column.

    It's not uncommon to have to use multiple entries to cover one specification. If necessary, you can use a flag to ensure that no hand will match more than one of these entries, as was done for COBRA entries C1165 and C1170.

    Here are specs you can enter:

    • One or more cards, using A through 2.

    • An asterisk, such as *Q, means that the Q must be present, but that a higher card may also be present, but is not required. Lower cards may also be present, if the Len spec, if any, allows (i.e.: *Q makes no sense if the suit Len spec is 1).

    • A question mark means that an honor must be present for each question mark.
      • ?Q -- Q plus any one higher honor (A or K).
      • Q? -- Q plus any one lower honor (J or T).
      • ??J -- J plus any 2 higher honors (AK, AQ, KQ).
      • ???T -- T plus any 3 higher honors
      • ? -- any honor, A through T.
      • ?? -- any 2 honors, etc.

    • When cards are specified without * or ?, such as just KQ, it means that higher ranking cards may not be present. However, the suit may have unspecified lower-ranking cards. So if KQ is specified, you could have KQJ2.

    • A minus sign indicates that the specified card must not be present; e.g.: -Q means no Q.

    • An ampersand ('&') is used to put multiple card specs together. Most often, this is to join a spec for a required card with a spec that a different card must not be present, such as K? & -T, which means a K with any lower honor except a T. To specify a K and no lower honors, enter K & -Q & -J & -T.

    It is easy to make card specifications which are not what you intended. Zar specifies that a point should be added for a Q in RHO's suit unless it is headed by the A and K (i.e.: AKQ). Entry Z1610 handles that; however, we originally put Q & -AKQ, but a Q without an asterisk means no higher honor. The correct code is *Q & -AKQ, which says that a higher honor is allowed, but not both A and K.

    Notice that both KQ and KQJ match both

    1. ?Q and
    2. *Q & -AKQ,
    but QJ matches only the 2nd spec. It does not match the first spec because the ? says that there must be a higher honor than Q, which QJ does not match, but * says that there may be a higher honor, but one is not required.


  • Len -- Length of a suit. For example, to specify a singleton King, enter K in the Cards field and 1 in the Len field.

      An n in the Len field refers back to the Value field. Something like n>4 means the amount by which the suit length exceeds 4 (or whatever number is specified).

      T1430 has n>4 for Len and 1*n for Value. If this hand has a 6-card suit, then for that suit, 6-4 is 2 * 1 is 2, so an adjustment of +2 is made; a 7-card suit would get +3, etc.

      T1480 has 5+, without the n, and a Value of 1. So if a suit has more than 4 cards, it gets 1 point, no matter how many more cards it has.

      Notice that the Cards and Len specs are suit specs and are tested for each suit (unless the Suit field limits the suits tested). If every suit matches the specs, the entry's value will be added four times.

      In contrast, the other fields are all for the entire hand and the value will either be added once or not at all, depending on if the hand matches the specs.

      Flags can obviate the need for a Length spec. Flag bQ in entries B1540 and B1550 is set if the hand has a Q in a short suit. Since B1640 is only used if bQ has been set, then we know it has to be a short suit, so no Length spec is needed.



  • VP -- Valuation Points are shown in this column so that you can easily see which entries are generating the points.

    The points are not saved. They are cleared out when you select a different system or click the Compute button again or exit the program.