Recently, a gentleman named “Knuckles” began frequenting our club. When I first met him, I made a show of examining his hands and I said, “I expected you to have outsized knuckles, like a retired prize-fighter.” He says, “No, I’m a lover, not a fighter.”

I’m hoping the nickname was bestowed based on a third, as-yet-unnamed pursuit, but I thought it best not to ask.

Deal Generator Notes

Several upgrades to the dealing machine since last time. I rebuilt it on a larger breadboard (the white rectangle with many holes) so all the parts fit and are oriented correctly.

The larger platform allowed me to build out to the correct number of buttons, from left: scroll forward/back through the boards, clear the deal display lights, display north, display east, display south, display west. That’s all we need.

When I develop the moving parts that this machine will control, I can chain them off of the smaller breadboard at the top of the picture. Just as this machine translates my web-based deal machine emulator into an actual machine, the future moving parts will translate the light display of this machine into the physical dealing of cards.

Until then, enjoy north’s hand from board 6 in all its red light glory:

Another upgrade is that the deal generator web page (Beta version only, for now) can now send the deals from the Deal Collection to the dealing machine. Before, it could only send deals from the deal display. Note the “Serial Port to Deal Machine” button in the Deal Collection file/export controls:

Coming soon: deals flying through the air on WiFi.

Speaking of file/export controls, I have revamped them. They work the same as before, but I changed where they live and what they look like, all in hopes of making their purpose—particularly what they operate on—easier to understand. Part of this was making the button labels longer and more descriptive, which I could not do when all file controls were jammed into a remote corner.

The recipe collection and file controls now sit inside the Deal Recipe panel, to the right of the Cards Placeholder Usage panel. They operate only on recipes, not on existing deals (though the Vary/Negate buttons do generate deals from recipes):

The deal collection and file and export (to dealing machine) controls now sit inside the Deal panel, at the bottom. They operate only on deals:

In all, the button text went from Hemingwayesque terseness to Faulknerian loquaciousness not seen since the heyday of Yoknapatawpha County. This is not as easy and obvious as it may seem, for I learned to program mainframes in 1983, back when we were—for reasons relating to severe resource constraints—shortening everything in sight, including dates (Y2K crisis, anyone?). I still default to abbreviations even when there is room for entire words.

Bridge Recipe in Focus

I got nothing this time. Been too busy with deal machine and coding mods.

Incident Report

I would love to share bridge triumphs, but those don’t qualify as “incidents.” If you make a game or a slam, you were probably supposed to make it, and it’s bad form to write things that hint at How Great I Art. I model my reports on the U.S. Federal Aviation Administration’s reports, and they don’t produce anything for safely-completed flights—only the crashes.

Still, sometimes you walk unscathed from the wreckage of what could have been a major incident, as my partner and I managed to do on this one. We tried so hard to nosedive this sucker into the ground, but fate said, “Nay,” and we wafted gently to the runway, staring at each other in amazed gratitude (much later, you understand, after seeing the session results). So, while there were no severe injuries, the frightening journey makes it worthy of the name Incident.

Happy dealing!

Not since The Soul of a New Machine came out in 1981 has there been such buzz and—dare I say it—hullabaloo in my household. Take a back seat, Data General Eclipse MV/8000: there’s a new new machine making waves. Check out this one-of-a-kind beauty, worn discreetly on my own wrist:

What you are looking at is the first working proof of concept of a new, less expensive bridge dealing machine. No, it does not actually deal cards. The concept it proves is that we can make my bridge deal generator communicate bridge deal information to external hardware.

You may recall that nearly two months ago I announced the idea of making a more affordable dealing machine. I then wrote up some design ideas, including the possibility of alternatives to the most expensive, difficult features (optical card reading, and moving cards into duplicate boards).

Right away, I realized that not supporting the reading of randomly-ordered cards and the loading of duplicate boards could well relegate my machine to casual or instructional settings, ACBL and other authority rules being what they are. But that’s OK! If my machine somehow makes things easier for teachers or individuals studying with friends, that’s a win.

I then added a dealing machine emulator to the Beta version of my deal generator. The idea behind the emulator was to identify the minimum functionality required for a dealing machine, but to express it in a web page. This nicely defines the problem that must then be expressed in a hardware design.

As for hardware, I envision some kind of lightweight, inexpensive machine driven by a micro-controller. Knowing nothing about any of that (other than the existence of the word “micro-controller”), my next task was getting up to speed on a little doohickey called the Arduino R4 WiFi (above, with the little red lights) and peripherals that it can control.

I recently completed the Arduino Starter Kit tutorials, and then got down to making my first machine based on the web-based emulator. And that’s where we are now.

Let’s take a little tour of how this works.

You start off (again, in the Beta version of the deal generator), and you generate a deal or deals. I made the Arduino support up to 64 boards, so here’s a deal display showing that I have 64 boards:

To use the Arduino dealing machine, you do not have to interact with the Deal-Lightful Emulator, but let’s click that button above the deal display to see what the first deal looks like in a hypothetical machine:

It’s not quite showing a deal, because I haven’t selected a seat. A dealing machine should let the user control which hands are dealt, since we don’t yet know what final form that machine will take—will there be one machine in the room, or lots of little ones? One per table? Or one per player?

The emulator does show the board number, dealer, and vulnerability. Then, if you select a seat, it shows you the cards for that seat. That is what we in the emulator community call “dealing the cards.” Here’s North’s hand, with blue lights over their cards:

Hey-O! Now click Close to end this side trip into the emulator, and observe the new goods down in the Save/Export Deal panel (formerly known as the Save Deal File panel).

The old HTML buttons now say “Web” because it’s shorter. Note the new Port and WiFi buttons, next to their PBN, LIN, and Web counterparts.

The leftmost “Port” button will send the deals from the deal display into whatever is attached to your computer’s serial port. You can use the Filter panel to restrict which boards are sent, just the same as you can restrict which deals are saved to a file.

Your browser should ask you to choose from a list of active ports; choose wisely, to avoid sending PBN data to some other peripheral device. Sadly, none of you have my one-of-a-kind Arduino dealing machine, so only I can really use this. Do note, however, that my program sends out pure PBN (Portable Bridge Notation) data of the exact kind you see in a data file, so anyone who is working on their own machine, and who supports pure PBN data, may find this feature useful as a ready source of deals.

The leftmost WiFi button will also send PBN data to an emulator, but over WiFi instead of through a cable attached to a serial port. I have not implemented the WiFi version of my Arduino machine yet.

The rightmost Port and WiFi buttons do the same as the leftmost buttons, but they send data from the deal collection, not from the deal display panel. Or they will—there is no code behind those buttons yet.

After I click the leftmost “Port” button and select the port to which my Arduino machine is attached, we see the machine acting just like the emulator. It shows board number, dealer, and vulnerability for board 1, but no cards because I have not selected a seat yet:

The web-based emulator has more buttons than does this machine. That’s because I was limited to the contents of the Arduino Starter Kit. Rest assured: more buttons will appear in future versions. The second button from the right, above, selects North. Let’s press it, shall we?

Merry Christmas! That’s North’s hand, represented by the little red lights. This is not by any means a useable product. It is entirely possible to interpret those lights, but we’re not going to be that minimalistic. This is just a proof of concept of the ability to go from deal generator to separate hardware, with all deal data intact. Once I get the WiFi version working, the next step will be to come up with a mechanism that actually delivers cards to players.

Speaking of fully intact deal data, here we see that, using the rightmost button, I was able to scroll through the deals (all now on the Arduino—it doesn’t talk to the connected laptop after the initial data transfer), to reach Board 64, and there I requested East’s cards by pressing the third button from the right:

Happy dealing!

Bridge Deal Generator Notes

If you’re like me (or want to be, which who doesn’t?), you think a lot about the fact that if you strip away the complex phrasing and justifications and history, bridge conventions and even just the most basic bridge systems boil down to shapes and points.

I think it’s even fair to say that bridge, in general, boils down to shapes and points.

This came to mind the other day when I was finally getting around to reading the August, 2022 issue of The Bridge World magazine. I foolishly subscribed to that publication before I could understand anything in it, but I wisely held onto my 12 issues just in case it ever became comprehensible.

The Puzzle Corner feature on page 15 has what author Göran Ofsén calls “puzzles of the construction type.” A very Nordic-sounding language construct, or else it’s engineer-speak (I myself speak/write language of the engineer type from time to time). Reading the first puzzle, I was struck by how, even when you’re not describing a convention, you start listing shapes and points.

Here’s the essence of the first puzzle, deconstructed into things that may be expressed in my deal generator while simultaneously, one hopes, not violating a copyright:

1. North/South have balanced hands. So easy to express!

2. North/South have at most 19 HCP. Oh man, give me something difficult!

3. North/South have at most 6 spades. Guffaw…can do.

4. At Double Dummy, South can make seven spades. Ha-ha…rd I mean impossible. Dang it!

OK, #4 cannot be expressed in my deal generator. The generator can display Double Dummy makeable contracts if they are supplied with existing deals, but it does not generate DD results on the fly for new deals (it will, eventually). For now, you have to generate deals, save them to a file, then load that file into Bridgesolver to see the Double Dummy analysis.

But, by golly, you can express the first three parts of the puzzle quite easily in a recipe. Then you can generate deals and decide for yourself whether South can make seven spades. Even if you let the recipe do the drudge work of coming up with candidate hands, it’s good to engage your brain to figure out if it’s a grand slam for South.

Here is a first attempt at a recipe to solve the puzzle:

The Pair Settings that let us specify 0-19 HCP for North and South are very handy for expressing “North/South have at most 19 HCP.” Too bad there is no equivalent pair setting for total number of cards in a suit. Since there is no such pair setting, we resort to using multiple shaper tabs, with each one describing a single spade holding for the North/South pair. Making multiple shaper tabs is where shaper copy and merge buttons come in very handy.

Funny how a puzzle can have just a few formal requirements, but others emerge and demand to be satisfied. For instance, while N/S have an upper bound of 19 HCP, what do you think is the lower HCP bound? Could you ever make your slam with 0 HCP? Obviously not! What about 5 HCP? No, I say! OK, how about 12 HCP? No…wait a minute. Lemme consult Bossomaier’s book on getting to thin games, or some article where some mega-masterpoints dude or dudette made a slam with 9 points to win a shiny medal, and get back to you on that.

So you see, there is very likely a lower HCP bound, but you get to have the fun of figuring out what it is. Once you know it, you must vow to use that knowledge only for good (which, by definition, does include demolishing your opponents).

Another point to consider: When I first read “at most six spades,” I thought, OK, six spades. That means 2-4, 3-3, or 4-2 in spades. But no, it says at most six. With two balanced hands, you could also have 2-2, 2-3, or 3-2. That’s why it takes six shaper tabs. But consider: could you possibly make a grand slam with only 4 or 5 of your trump suit between you? If you can imagine such a hand, then keep all six shaper tabs; if you can’t, then it would be smart to pitch the unrealistic tabs so they don’t deliver false positives.

And another thing: aces. Do N/S have to have all four? Nope. Ofsén provides a deal on page 33 in which East has the ace of clubs. Fortunately (or, I should say, necessarily for this deal to suit the puzzle), West is void in clubs. N/S are not void in clubs. So there’s another requirement: if N/S are missing an ace, it must be in a suit which either can’t be led by E/W, or in which North or South is also void and in which they can out-ruff the E/W player with a void.

Oy, as they say, vey.

Oh, and why would an E/W player be unable to lead the danger suit? Well, in the above case, West is void in clubs. What’s to keep East from leading it? Well, if N/S must win every trick, obviously we can’t lose a trick to East. What does that imply? It implies that, if East has a game-crushing ace, then in the other suits, we must be able to finesse from North through East, winning in South, to keep East off lead. You know how in normal play, you routinely want just one finesse to go your way? Well, this grand slam thing is going to need several successful finesses.

And what of N/S clubs in Ofsén’s solution? Why, obviously they must be pitched on other winners. Add 100% pitchable losers to the stack of requirements.

I’ll admit that when I first saw the puzzle I thought to myself, “Self, that’s three easy requirements and a kind of tough but knowable outcome (the seven spades contract). I’ll just whip that up in the ol’ generator.” But as I have demonstrated here, complications ensued.

We have moved well past the initial requirements, and that’s just from pondering before looking at any generated deals. I think this makes “puzzles of the construction type” quite useful as mental training tools.

Give it a try yourself, either with this puzzle or any others you find.

Recipe in Focus

This post is long enough. Coming next time: a quick-and-dirty approach to New Minor Forcing, to be followed by another post on a slower, longer-lasting approach.

Incident Report

I have a juicy, very embarrassing incident involving New Minor Forcing. I’ll save it for next time, to go along with the NMF recipe discussion.

Happy dealing!

Bridge Deal Generator Notes

No changes to the generator lately. I’ll never declare it feature complete, but it’s pretty darn mature now.

As for the inexpensive dealing machine project, I’m still learning to build and program devices based on the Arduino microcontroller. I only mention it here in hopes of sparking the dealing machine manufacturers, or a would-be competitor, to jump into the low-end market with a clever and affordable machine so I don’t have to actually keep working on the thing. Come on, folks, it doesn’t have to require a heavy-duty solution! Don’t let a famously un-handy neophyte beat you to it!

I include the above photo from the Arduino website because I think it’s pretty cool that they feature a classic playing-card heart shape in the built-in LED panel. Clearly, they intended the device to do something bridge-related all along.

Incident Report & Recipe in Focus: More crossover action

If I keep managing to coordinate the subject matter of Recipe in Focus and Incident Report, I’m going to have to come up with a different section heading.

Let’s talk learning styles.

I’m in a new partnership. We decided to start with a very plain Standard American convention card with no conventions other than Stayman and Jacoby Transfers. This lets us focus on our basic bidding and try to get on the same page without a lot of undue complications. The idea is that, over time, we will track our results and find out two things: 1) where our understanding of basic bidding is not in synch; and 2) where basic bidding itself falls short—meaning it may be time to add a convention.

I much prefer this to wholesale adoption of poorly-understood (by the partnership) conventions.

I was delighted to find a partner who likes this approach, because one thing I have observed by playing with many different partners is that many will claim to “know” a convention when in fact they only know the first one or two bids in what is actually a longer bidding sequence; they may or may not know whether it is on or off in competition, nor whether it is alertable, or which of multiple bids in the sequence are alertable. Or sometimes they know not one but two bids in the sequence, but they don’t know that it only applies to a certain seat, or is limited to majors.

An example with another partner some time ago was where I opened 1D in 3rd seat. Partner responded 2NT, which per our convention card shows 10-12 points. We went down in 3NT. Partner then took me to task for missing his Jacoby 2NT response. I told him that Jacoby 2NT is only after a 1-major opener, and that only in 1st or 2nd seat. He debated me on that until he looked it up. He then admitted that I was “technically” correct but he thought I should have known what he meant. Common sense, you know.

As in, common sense dictates that I ignore the simple meaning of the 2NT over 1D, and assume an unrelated major-suit-only convention applies?

Egad.

The lack of clarity on alerts can lead to amusing situations. Once, I opened a minor and partner bid 1 of a major. I bid 1NT, and partner said, “Alert.” Oppo’s asked partner to explain and out came, “That’s new minor forcing.”

Um. 1NT is not a minor suit. It’s not even a suit at all. Confusion reigned, but it was not my place to say anything before the correction period.

Next thing you know, partner bids the other minor and I say, “Alert,” and, when asked, “That’s new minor forcing.”

I’m a new-ish director now, and I belatedly wonder whether his incorrect alert of my 1NT, and his description of it as new minor forcing, might should have either precluded his own bid of the new minor, or perhaps should have led to some kind of penalty due to unauthorized information. All was explained in the correction period, but an argument could be made that his improper alert served to put me on notice that new minor forcing was a-comin’ down the pike.

Becoming a director messes you up, man.

From this and similar incidents, I have realized that some players give reading material only the lightest skim, and they think they know the convention. Some, when shown the relevant details that prove that a convention applies only in specific scenarios, will reply, “Well, it’s just common sense that if I bid <insert inapplicable conventional bid> here it means the same thing.”

I so dread the invocation of “common sense” when discussing conventions. Players who think it’s just common sense are expecting partner to make the same random mental leaps that they are making.

I like to read articles and books and thoroughly understand a convention before using it in live play; others like to learn one or two bids and they never do a deeper study. I can’t be too critical, because people with different preferences and learning styles routinely outplay me. Nevertheless, I simply won’t pretend to know a convention just because I can lay down the first bid.

OK, back to incidents and recipes.

My minimalist partner and I underperformed on this board a few weeks ago:

This shows that it would, in fact, be possible to bid the hand up to game without a convention. But to do so would require a deep partnership understanding of when/why one might bid a suit over partner’s weak 2-bid, and the implied value of opener’s own side ace. It’s doable, but it’s a heavy cognitive load and it requires guesswork and luck (notice I didn’t write common sense).

This is clearly a case that calls for adding one of the simpler conventions: 2NT Feature Ask. With it, I could show my points and get a better read on opener’s hand. He could show me his spade stopper and I, with a stopper in clubs, could emit a gladsome cry and bid 3NT.

So, two months in we have now added 2NT Feature Asking. To help with our study sessions, I made stunning, simply fabulous deal recipes and reports, which are now in the big cookbook.

I based the recipes on the 2NT Feature Ask chapter in the book Modern Bridge Conventions by Root & Pavlicek. The recipes are conducive to the three basic opener responses to the 2NT feature ask:

1. Rebidding the opening suit when at the low end of the weak 2-bid point range.

2. Bidding 3NT with a solid suit.

3. Bidding a suit with a feature when at the higher end of the weak 2-bid point range.

Happy dealing!

Bridge Deal Generator Notes

In last week’s note, I mentioned my desire for a less-expensive, programmable dealing machine, and my intention to build a working prototype.

I then commented on the current dealing machine designs, and which parts of those designs are (in my view) absolutely necessary and which are not. The goal of that exercise was to help guide my own efforts at machine design. It was a mission statement, not a memo.

I then put together a dealing machine emulator that will help me figure out the data requirements for an eventual physical dealing machine. I also put some new buttons into the Save Deal File panel for eventual use in sending deals into the yet-to-be-invented dealing machine. Those goodies can be seen in action only in the Beta version of the deal generator.

I have since acquired the Arduino R4 Starter Kit and begun working through the introductory project book.

I will post updates on the machine project in Computation Corner, but I won’t send those technical posts out as emails since they won’t have much bridge content. Instead, I will briefly note any significant machine progress in the weekly email updates. If the technical bits interest you, you may, of course, browse Computation Corner as much as you like.

Incident Report & Recipe in Focus: Crossover episode

Recently, I have begun planning to make the Recipe in Focus section and the Incident Report section both address the same topic. The idea is that when I analyze a result from a club or tournament session, I would like to also think about the things that make the deal itself interesting, and then develop a recipe for creating the same or a similar scenario. That way, the incident report provides analysis of a specific deal, and the recipe provides a way to generate variations on that deal for further study and practice.

The Common Game from the morning of 13 June, 2026, provides four deals of a particular type that are perfect for a combo approach. Boards 4, 6, 10, and 12 all include one hand with 7 or 8 cards in a suit. You might be used to seeing the occasional very long suit, but very often your hand is otherwise unremarkable and you are not inspired to go all in on that suit. But these four have other traits that you don’t always see with a long suit.

One such hand has 8 HCP; the other three have 12 or 14 HCP. All four long suits have an ace; all have at least two honors; one has four honors and one has five. Only one deal has the long suit in 1st seat, where it opened the bidding; all others have the long suit in 2nd or 3rd seat where, if they were bid at all, they were overcalls.

I’m not going to provide detailed incident reports for all four. I will say that for all four, we did not bid or make game in the long suit, we did not play in a sacrifice, we did not push opponents to overbid, and we did not get top board. Results varied at other tables, with some pairs bidding up the long suit and others winding up on defense, where their long suit was ruffed into oblivion.

I will show you what those deals look like, sans auction. You can think about how they should be bid and played.

That’s the specific hands. Let’s turn now to making recipes for this general type of hand.

Does making recipes start to seem a tad repetitive and, dare I say, easy? I sure hope so!

I see that my placeholders overlap the text area or other hands in places. I’ll have to fiddle with report spacing to prevent that. Meanwhile, your recipe report PDFs have a clickable link so users can just load up the recipe by clicking the URL—no need for them to key in the recipe from your report. I don’t provide deal or recipe URLs in blog posts because Substack seems to corrupt them in blog post emails.

Happy dealing!

The rationale and design considerations for the physical dealing machine are on the page linked here.

The external dealing machine may or may not look like the emulator web page, but it will have similar control and display features, and it will need the same data as the emulator: board number, dealer, vulnerability, and the cards for each seat.

The emulator turns on a blue “light” (really just a dot) above each card from the current deal for the selected seat. An actual dealing machine might do something similar, or it might actually “deal” a card by moving it in some fashion. But to know which cards to light up or deal, the machine will need only the information used by the emulator.

The emulator is currently only available in the beta version of the deal generator. That version is reached at this URL, which is also listed as the “development version” on the main page of Bridge, Out Ahead.

To use the emulator, you must have at least one deal present in the deal display. It also works with multiple deals. To activate the emulator, click the “Deal-Lightful Emulator” button just above and to the right of the deal display, as shown here:

You will then see this modal web page (that is, it takes over and obscures the rest of the deal generator page):

The emulator has all 46 boards of this set available to it. When you activate the emulator, and when you use the scroll arrows to move from one deal to another, the seat selection radio control always resets to “None” so that the dealing machine doesn’t show any player’s hand. That is, it gives no visible clue as to which cards belong to whom.

To “deal” a hand to a seat, select that seat’s radio button at the top of the emulator page. Here I have selected South. Blue dots appear above South’s cards:

Checking South’s hand back on the deal display panel, it matches the cards lit up by blue dots on the emulator:

So, emulating the dealing of phsyical cards is all that the emulator does.

If the physical dealing machine only indicates a player’s cards, such as with a light, then that player would extract just those cards.

If the physical dealing machine does something else, such as raise just the one player’s cards from inside a machine, or eject just that player’s cards into a tray, or open little sliding doors from in front of the cards, then it would do so just for the “blue dot” cards shown in the emulator.

Note that the emulator is, as I wrote up front, just a test bed. It is not the actual interface to the physical dealing machine (which, in fact, doesn’t exist yet).

The actual interface to the physical dealing machine will be a data transfer initiated from the bridge deal generator. That transfer will occur either through a USB port or over Wi-Fi (again, the machine doesn’t exist yet so all things are possible). The transfer will be initiated by clicking one of the “Dealer” buttons in the Save Deal File panel:

At the moment, since there is no physical dealing machine, those “Dealer” buttons just take you to the emulator because that’s all we have right now.

Today’s dealing machines are nice technology and are well-suited to mass-production of pre-dealt duplicate boards before the session that will use those boards. When thinking of a more affordable card-dealing solution, it is natural to start off by assuming that any machine must provide every feature of the current, very expensive, machines.

In this space, I will examine the assumptions as they apply to machine design. I will possibly sneer at and/or reject some very basic assumptions. When setting design goals, I like to start with a blank slate and then only adopt requirements that don’t make me miserable.

Assumption: All cards in a bridge deal must come from a single deck of playing cards.

The ACBL laws require that all cards in a bridge deal come from the same deck.

This strikes me as a requirement originating before the advent of dealing machines and pre-specified deals (a la The Common Game or any other that lets a computer determine the cards). Certainly, with a physical deck and with random shuffling, the cards must all come from a single deck.

I think that for pre-arranged deals (that is, those where the cards are specified in advance rather than derived from random shuffling of a physical deck of cards), it really shouldn’t matter—in a casual or instructional setting—whether the cards all came from one deck.

I do think it is important that all cards in a single hand (not the entire deal) come from the same deck. That way, every potential card for that hand will have the same back, so there is no way to distinguish one card from another based on the design.

I address this seemingly simple assumption because I can imagine some dealing machine designs where cards might need to come from multiple decks. While I think it shouldn’t matter so long as all cards in each hand have identical backs, I could see where one might want to stipulate that if multiple decks are used for the deal, they should all have identical backs. I don’t think four hands with four different designs would affect fairness of the game, but it might be distracting to players who are used to uniformity.

Please not that uniformity of card design (which I endorse) is not the same as cards actually coming from the same deck (which I don’t care about at all).

In designing my dealing machine, early versions may discard the single-deck requirement. Absent a change in ACBL and other organizations’ laws, this would relegate my machine to casual settings.

Assumption: All cards in a bridge deal must be dealt from the deck in a single starting location, and from there they must be separated into separate hands all at once.

That basically describes how today’s dealing machines work. You load the single deck of cards into a hopper at one end of the machine. The machine then distributes the cards into the correct slots in a duplicate board.

I’m sure there are security reasons for having boards dealt in this manner before an event. But setting security aside (again, perhaps in a casual setting), what if we could produce duplicated deals right at the table, and directly into the players’ hands instead of into boards?

It might seem like an outlandish proposition, but consider this: sessions that use tablets for all phases of the game (auction and play of the hand) do that very thing. No boards are involved. Each player sees only their own hand for each deal.

I would like the same capability when playing with physical cards.

You might wonder: why don’t I just go all in on digital bridge, with tablets?

The answer is that I don’t like computer bridge. I use it for solitary practice only, or for remote sessions with a partner. When playing face to face, I want to hold the cards. But I don’t think that existing methods of dealing cards, which happen to involve very difficult technological challenges that can only be met with high-precision, expensive machinery, should become de facto requirements in and of themselves.

If I first rejected the assumption that all cards must come from the same deck, then I can easily envision a simpler, cheaper way of distributing cards from multiple decks and at multiple locations (that is, at each seat at the table), and on-demand instead of being mass-produced in advance.

I can also envision the single-player, just-in-time delivery of a bridge hand where all the hands at the table do come from a single deck. The single-deck requirement, and the single-point-of-production requirement, are two different things and may be accepted or dismissed separately or together.

Assumption: The machine must read and identify cards.

Current machines read and identify cards, using either special bard-coded cards or optical scanners that can read the suits and ranks directly.

This is an absolute requirement if the cards are introduced into the machine in random order.

Therefore, supporting introduction of cards in random order requires an advanced—and expensive—technology.

Let’s imagine a machine where the cards are introduced, or are simply present, in fixed, known locations.

Assumption: The machine must move cards from one place to another.

This assumption is a consequence of earlier assumptions.

If boards must be pre-dealt on an industrial scale (even a 28-board club session fits this description), then yes, the machine has to move cards from a deck into boards well in advance of their use.

If you assume the user of a machine that single-handedly takes in a deck in random order and produces a loaded board, then by definition the machine must be moving the cards.

If you abandon those earlier assumptions, then it is possibly to—by some definition—deal cards immediately prior to their use by players, with no requirement for the machine itself to move the cards.

What is possible without the assumptions?

My ideal dealing machine would be a device that puts the right cards into each players’ hands at the table with no need to use preloaded physical boards. It would have no moving parts.

I would like to modify the single-deck requirement and instead require that all cards must have an identical back design. However, I will try to produce a design that will work either with a single deck.

The machine I envision does not use magic in lieu of optical scanners, spinning axles, and rubber belts. Cards do have to ultimately go from machine to the players. I envision the machine making the cards readily available to the players, but the players will have to interact with the machine.

Here, “interaction” is not as complex as operating current dealing machines in conjunction with PC-based deal software—a task usually performed by directors or trained staff. Instead, it would consist of preloading deals into the machine over cable or wi-fi, just once at the start of a session, in a process that many players could easily master if it is made simple enough (not disrespecting players, but many are technophobic).

Then, at each table, players would use the machine to advance to the correct deal, then extract their cards from it, and play.

After playing, the players would return the cards to the machine, advance to the next deal, extract their cards, and so on.

It would be entirely possible for each player to have their own notebook-size portable dealing machine if multiple physical decks were approved. They would carry that machine with them, and would always only extract their own cards from it. However, if single-deck-per-deal is an absolute requirement, then one dealing machine per table would do the job.

How to get there

I intend to build hardware prototypes using Arduino technology. Arduino is a company that caters to the maker and robotics crowd, and as a result they have standardized and commoditized much of the bits and pieces of technology required to design and build machines. They have also made it easy to integrate machines with computers.

It will take me some time to learn Arduino hardware and programming, and to then turn that knowledge into physical designs.

As for what data is needed by the dealing machine, and what controls it should have, I have already put some effort into that. This user guide describes a dealing machine emulator that I coded into my bridge deal generator. The emulator operates using only the data that I would be sending into an external dealing machine, and it also mimics the controls that I envision for the machine.

The technology will all turn out to be quite simple, I’m sure. The hard part will be either meeting or eliminating assumptions and requirements that restrict us to expensive solutions.

Onward…

Coming soon(-ish). Not content with redefining low-cost web-based deal generators, we here at Bridge, Out Ahead are ramping up a hardware division to see if we can’t have a programmable dealing machine that doesn’t mimic a 1950’s IBM punch-card sorter, and that doesn’t—most crucially—cost $4,000-$6,000.

More on this as plans come together.

Bridge Deal Generator Notes

My recent heavy use of the deal generator uncovered some bugs and missing features. All are now corrected. They were:

1. It was possible to create deals with too many or too few cards in a hand when using only exact cards in the Cards panel. Now you may still try to do that, but the generator will silently disobey you and put exactly 13 cards in each hand.

2. When loading a deal from a LIN file, or from a URL with the deal in LIN format, if an auction was present in the LIN, it was ignored; now the auction is loaded into the Auction text box ‘neath the Deal display.

3. If you keyed !s or !h or !d or !c in auction annotations, they did not get changed to suit symbols in the deal report PDF. Now they do.

4. In my work on deal recipes, I realized I needed an easier way to specify “void or singleton” either in any suit, or in a specific suit. Solved with new Shapers, which are the topic of today’s Recipe in Focus.

Recipe in Focus

Thank you for that introduction, Bridge Deal Generator Notes section.

Suppose you want a recipe for Jacoby 2NT, specifically one where the opener wants to rebid three of a side suit to show a void or singleton. “Or” conditions can be handled several ways.

One way is to use two Shaper tabs with nearly identical settings; the only difference here is that one specifies a void (0-x-x-x shape) and the other a singleton (1-x-x-x). When you generate deals, the generator will randomly find one or the other:

That method works fine, but duplicating and slightly modifying shaper tabs gets to be hard labor and, once you make a recipe like that, you have to always remember to keep those tabs in sync if you change the first one.

Another method to get a side suit void or singleton is by using randomizers (the brace and brackety things) in the Cards panel:

The above two methods should yield the same types of deals, but they are not equivalent in operation. The Shaper method relies entirely on random shuffles, and it searches until it finds a deal with the requisite void or singleton. The Cards method pre-deals a void or singleton into a side suit, which reduces the number of random shuffles it has to perform.

Both methods are also much, much better than nothing.

But, as usual, when I find something tedious to use in practice, I sprinkle more Shaper Dust. In this case, since “void or singleton” language seems to come up in several conventions, I want to express it succinctly. I added these five Shapers to the list so one can easily specify “void or singleton” either for the hand, or for a specific suit or suits:

Here’s the Jacoby 2NT recipe using the “Some 0 or 1” shape:

Incident Report

In this one, even if we (E/W) bid game, we are not likely to beat the action at another table where another E/W pair played 3NTE+4 (!) for 720.

So the lesson here is not necessarily to improve our matchpoints, but to come in second place with more style. Interestingly, only South and West recognized the Michaels bid. North shut down out of confusion. East showed longer clubs but didn’t jump to show points. Someone please correct me if I’m wrong about that—should West have bid again after the 3 club rebid? I didn’t see enough total points based on that bid, and I assumed East had no stoppers, and wasn’t inspired by my claim of some stoppers, since he went back to the minor suit.

Happy dealing!

Bridge Deal Generator Notes

A bridge pal recently asked whether I could implement something like Fred Gitelman’s counting game, as seen on Bridgewinners. That game is useful for drilling on bridge math. The bridge pal wanted something like that, but with numbers based on actual deals. For the record, I do not know how Gitelman’s game comes up with its numbers, and so they may very well come from an unseen deal generator. However, based on the number of zeroes it comes up with, I think it may just use a random number generator for each of the numbers it presents to the user.

I came up with this:

It uses card images, not numbers. The deals are from the Deal panel of the generator. You may therefore rely on random deals, or deals generated from recipes if you want to work on quick recognition of specific distributions.

This tutorial explains how it works, including how to start the game from the deal generator page or from an external link, like this one that can be embedded in documents, web pages, emails, etc.:

https://bridgeoutahead.com/bridgedeal/?mode=countClubs

One tester has reported issues with the game dropping cards from diamonds and therefore also counting the clubs incorrectly. I did not experience that problem, but if you see that or any other defect, please let me know, and provide screen captures and related deal files if possible.

Recipe in Focus

I have been tied up with card-counting development and have done nothing new with recipes. But it doesn’t always have to be new. I used an existing recipe as the basis for a very productive study session, and I thought I would describe that way of using recipes. It doesn’t always have to involve making deal sets that you have to play all the way through.

A few weeks ago, I shared a basic recipe for the Flannery 2 Diamond opening. It looks like this:

Last week I was directing a game at the local club, and I was the odd man out so I didn’t get to play. I wanted to study something but also keep eyes and ears on the room. So it couldn’t be too long and involved.

I pulled out Flannery’s book (which I still think he should have called The Me Convention) and took note of how he first teaches how to figure out whether to use Flannery with the right distribution and 11 or 12 HCP, and then how to handle hands with exactly 16 HCP. Very different rules! He provides a page of examples for each, along with his analysis of how to open them.

As with the counting games (Gitelman’s and my own), I think recognizing conventional openers really benefits from intensive drilling. Have you ever learned a convention, or even a whole suite of related conventions (2/1 and its pals come to mind), only to find you might only encounter that scenario once or twice a week in live play? Or how about when you do finally get a chance to use something like a Bergen raise and you alert it because you at least know you’re going to alert any 3-level response to your 1-major opener, absent interference, but when the opponents ask what it means you have to meditate for 20 seconds to remember which point range the bid represents, all the while resisting the urge to sneak a peek at your convention card?

Now, I could have studied Flannery’s pages of examples over and over, to decent effect. But what I did instead was take my basic Flannery recipe and change North’s point range to 11-12 HCP. Then I generated 100 deals from the modified recipe. Then I looked at one deal at at time in the deal display, and tried to apply Flannery’s guidelines to each one and come up with my opening bid as quickly as possible.

After that, I changed the recipe again to have exactly 16 HCP in North, and made 100 deals. Then I took those one at a time and figured out the bid.

So, whether you are a teacher, a student, or a player, consider making focused drill sessions a part of your study.

Incident Report

Here’s another of the occasional top boards that are only top because we were playing in a session with two and a half tables. In that size game, mistakes (yours and those at other tables) are amplified.

I misplayed a makeable contract, but luckily for me the other E/W pair overbid it and went down more.

I have a tendency to hold up an ace if it’s my only winner, to let oppo’s exhaust their supply of that suit. I need to recognize when the hold-up helps and when it doesn’t.

In this case, upon seeing my clubs I know I’m only ever winning one club, and I’m not likely to “exhaust” either opponent’s ability to lead that miserable (for us) suit by holding up. So in this case, grab the controls and start steering into your good suit!

To anyone who says, “Duh,” I say to you: Good point, but I’m a long-time developer, not that long-time a player. I love when a light bulb goes on for me, even on simple stuff. Especially on simple stuff, actually, because most of the mistakes my partners and I make are not in deep or esoteric areas.

Happy dealing!

Bridge Winners hosts a well-regarded counting game that was developed by Fred Gitelman. If you want a numbers-based counting game that keeps score and tells you how you are doing, start there! My own card-counting tool was inspired by that excellent game.

You should know, though, that I ditched the numbers, the score-keeping, and the automatic generation of problem sets. I kept everything else <chuckle>.

I like the numbers-based game. But at the bridge table, we see cards and then we must count them and turn them into numbers. I therefore made a counting tool that uses card images instead of numbers.

Everything in the deal generator either starts or ends with generated deals. Nothing magically springs into existence without the user requesting it. This means you must have some deals available before starting the card-counting game (note: unless you come in via a link that does make deals spring into existence—that’s covered later on in this guide).

My card-counting tool uses deals in the Deal panel of the bridge deal generator. No deal in the panel, no card-counting exercise for you! But don’t despair. You can get a plentiful supply of deals quite easily.

If you have a PBN (Portable Bridge Notation) or LIN (Like I kNow) deal file handy, you can load that into the Deal panel and use it for a counting exercise. But why limit yourself to a couple of dozen (meaning no disrespect to the million-deal data scientists out there)? You can set the deal generator to generate up to 2048 deals, and use those for your exercise.

Here we see a Deal panel with 2048 deals:

Note the cryptic button just above the deal:

In some cultures, “#” means “pound” so that could mean “pound of clubs?” Pound of clubs, Guv’nah? A little gifty for the wife and kiddies? But here in Alabama I take “#” to mean “number” so that button means “number of clubs?” Click it with at least one deal present and you will see this:

That counting tool takes over your browser window. That means you can’t do anything else with the generator until you close the counting thing. Do not lament this limitation. I have heard that some consider the deal generator a tad complex. That being the (alleged) case, no one should want to play the counting game whilst also designing recipes or doing various nefarious file input and output operations. That would lead inexorably to chaos, confusion, and, possibly, an acidic foreboding in your innards.

The second line at the top of this panel asks you how many clubs are needed to make the displayed cards into a 13-card hand. You answer by clicking one of the number buttons below the hand.

If you get it right, the missing club cards will spring into view, like this:

If you get it wrong, nothing happens.

Either way, nothing much else happens. No score-keeping. I like minimalist tools. I think the unseen but crucial feature is your own dedication to using the tool. Kind of like swimming laps in the pool is the point, not having the snazziest lap-counter. There’s no countdown clock to tell you how quickly you are getting to the right number or to scare you into clicking something before it hits zero. Just keep practicing, and you will find yourself getting faster.

See the arrow buttons below the number buttons? And see that between the left and right arrows you see which deal you are on? In this case you are on deal 1 out of 2048. You can use those arrow buttons to scroll forward and back through the deals. Scrolling here will also scroll the Deal display panel, and also the deal displayed in the Deal Report panel. That’s another good reason to not use the card-counter while also doing other important tasks. One task at a time, and reload your browser now and again in case stuff is hanging around from previous tasks.

Probably about 99.999% of the time, after getting your reward (seeing the clubs) or being defeated and unable to count to 13, you will want to go to the next deal. Clicking the innermost right arrow below the row of numbers will do that. But it would be annoying to have to move your mouse to that button every time. For that reason, if you click on any of the card images, the next deal in line will be loaded up for your club-counting pleasure. For any other navigation, use the arrows.

When you are done, click the “Close” button and it all goes away.

The magical link

In a perfect world, everyone would want to know how to generate sets of deals. Playing the card-counting game would then just be a bonus feature on top of the wondrous ability to generate your own deals.

But in this here world, some folks just want to play the game. But how to get to that # of Clubs? panel without going through the deal generation or loading process?

You can do that with this link, which has a “mode” parm:

https://bridgeoutahead.com/bridgedeal/?mode=countClubs

When you click that link, you get straight to the card-counting game with 100 randomly-generated deals preloaded.

Obviously, if you’re already on the deal generator website, you can probably manage getting some deals into the thing and clicking the # of Clubs? button. So that link that makes it easier is intended for other folks to embed in their websites or documents or emails to share with friends, or the world in general.

If you want to use or share that link, and you want something other than 100 random deals, you can specify your desired number of deals by adding a “numDeals” parm to the URL:

https://bridgeoutahead.com/bridgedeal/?mode=countClubs&numDeals=500

Bridge Deal Generator Notes

Permutations, a feature I introduced just a few weeks ago, is all grown up now.

The first version could produce variations on an existing recipe by combining new HCP ranges for any number of north and south hands. This suited recipes geared toward opening and response bids.

The next upgrade could produce variations by combining new HCP ranges for north and east hands. This suited recipes for opening and LHO overcall bids.

Those two versions convinced me that it was time to go all in: the permutation feature now lets you produce new recipes by combining new point ranges of all kinds (HCP, controls, and losing trick count) for any number of East, South, and West hands relative to any number of North hands.

All that this “combining” and “any number” stuff means is that if you have two point ranges for North, and you want to combine that with three (for example) point ranges for East, South, or West, you can apply a permutation to one recipe that will result in 2 times 3, or 6, new recipes with the desired point ranges.

You can also vary the North/South and East/West pair point ranges via permutations.

This might sound like mumbo-jumbo if you are not yet making your own deal recipes, or if you are making some but have not reached the point where you realize you could spend hours of manual effort to make all the useful variations you might want to store in a cookbook.

Recipe in Focus

Mumbo-jumbo that is over the heads of the new or most basic user is not good, but neither is just pointing to user guides and saying, “Hope you figure it out!”

So now I’m going to show you how one partial input recipe becomes two complete, new recipes via Permutations.

If this is getting too deep into the technical weeds, feel free to skip ahead to the Incident Report at the bottom of this blog post.

Here is a basic recipe for a likely 1-spade opener, with shape and cards but no restrictions on point ranges:

Won’t that product deals with something other than 12-21 points? It sure will. That’s why it is a mere “Basic” recipe, a starter for better things to come.

Now let’s make a permutation specification to tell the generator what kind of finished deals we want. Here it be:

{
    "permutations": [
        {
            "fileNameFirstNumber": 1,
            "fileNameSecondNumber": 0,
            "northSouthHCPRange":   { "set": "N", "low": 0, "high": 40 },
            "northSouthCtrlRange":  { "set": "N", "low": 0, "high": 12 },
            "northSouthLTCRange":   { "set": "N", "low": 0, "high": 24 },
            "eastWestHCPRange":     { "set": "N", "low": 0, "high": 40 },
            "eastWestCtrlRange":    { "set": "N", "low": 0, "high": 12 },
            "eastWestLTCRange":     { "set": "N", "low": 0, "high": 24 },
            "updateShaperTabIndics": [ "Y", "N", "N", "N", "N", "N", "N", "N", "N", "N", "N" ],
            "northHands": [
                {
                    "northHCPRange":    { "set": "Y", "low": 12, "high": 14 },
                    "northCtrlRange":   { "set": "N", "low": 0, "high": 12 },
                    "northLTCRange":    { "set": "N", "low": 0, "high": 12 }
                }
            ],
            "otherHands": [
                {
                    "eastHCPRange":     { "set": "N", "low": 0, "high": 37 },
                    "eastCtrlRange":    { "set": "N", "low": 0, "high": 12 },
                    "eastLTCRange":     { "set": "N", "low": 0, "high": 12 },
                    "southHCPRange":    { "set": "N", "low": 0, "high": 37 },
                    "southCtrlRange":   { "set": "N", "low": 0, "high": 12 },
                    "southLTCRange":    { "set": "N", "low": 0, "high": 12 },
                    "westHCPRange":     { "set": "N", "low": 0, "high": 37 },
                    "westCtrlRange":    { "set": "N", "low": 0, "high": 12 },
                    "westLTCRange":     { "set": "N", "low": 0, "high": 12 }
                }
            ]
        },
        {
            "fileNameFirstNumber": 1,
            "fileNameSecondNumber": 8,
            "northSouthHCPRange":   { "set": "N", "low": 0, "high": 40 },
            "northSouthCtrlRange":  { "set": "N", "low": 0, "high": 12 },
            "northSouthLTCRange":   { "set": "N", "low": 0, "high": 24 },
            "eastWestHCPRange":     { "set": "N", "low": 0, "high": 40 },
            "eastWestCtrlRange":    { "set": "N", "low": 0, "high": 12 },
            "eastWestLTCRange":     { "set": "N", "low": 0, "high": 24 },
            "updateShaperTabIndics": [ "Y", "N", "N", "N", "N", "N", "N", "N", "N", "N", "N" ],
            "northHands": [
                {
                    "northHCPRange":    { "set": "Y", "low": 18, "high": 19 },
                    "northCtrlRange":   { "set": "N", "low": 0, "high": 12 },
                    "northLTCRange":    { "set": "N", "low": 0, "high": 12 }
                }
            ],
            "otherHands": [
                {
                    "eastHCPRange":     { "set": "N", "low": 0, "high": 37 },
                    "eastCtrlRange":    { "set": "N", "low": 0, "high": 12 },
                    "eastLTCRange":     { "set": "N", "low": 0, "high": 12 },
                    "southHCPRange":    { "set": "N", "low": 0, "high": 37 },
                    "southCtrlRange":   { "set": "N", "low": 0, "high": 12 },
                    "southLTCRange":    { "set": "N", "low": 0, "high": 12 },
                    "westHCPRange":     { "set": "N", "low": 0, "high": 37 },
                    "westCtrlRange":    { "set": "N", "low": 0, "high": 12 },
                    "westLTCRange":     { "set": "N", "low": 0, "high": 12 }
                }
            ]
        }
    ]
}

Nothing to it, right? Not if you are wise to the mumbo and the jumbo.

The reason the specification is so large is that it includes every possible value of the recipe that you might want to change, whether or not you actually do change it. If you are making a specification file, the last thing you want to have to do is look up field names and key them in.

This specification has only four relevant settings.

There are two permutations.

The first one has the first Yes/No indicator of updateShaperTabIndics set to “Y” so that Shaper Tab 1 is updated. All other shaper tabs are set to “N” and so they are not updated.

Then, in northHands, the HCP range for North is set to 12-14.

In the second permutation, Shaper Tab 1 indicator is set to “Y”.

Then, in northHands, the HCP range for North is set to 18-19.

When I apply this permutation specification to the 1-spade opener Basic recipe, I get two complete recipes in files with point ranges in the file names:

I set out to create two complete recipes from one incomplete recipe. Mission accomplished.

But what about the 15-17 and 20-21 point ranges for 1-spade openers? Why didn’t I create those from the same Basic recipe?

I didn’t make those other two point ranges from the Basic recipe because that recipe doesn’t prevent balanced hand shapes. With balanced hands, those other two point ranges would be candidates for 1NT and 2NT openers, not 1 spade openers.

This calls for a second basic recipe, one that specifies “Unbalanced” for North:

It’s a small yet vital change. Some might not want to keep two versions of the 1-spade opener Basic recipe, but I like to save every useful variation so I don’t have to remember to create it on the fly during some future design session. So two Basic recipes it is, in my cookbook.

I won’t show the permutations specification for my 15-17 and 20-21 pointers, because it’s just like the one I already showed you, except that it has those two point ranges for North.

Running the permutation with the Unbalanced recipe and the 15-17 and 20-21 permutation spec, I get these two nice recipes:

All four of the recipes I created today will appear in the Openers section of my cookbook.

By the way: today’s finished recipes are tomorrow’s basic input recipes. Notice that I have not specified responder or overcaller point ranges. That’s because the Opener chapter of the cookbook only contains opening hands. But once that chapter is complete, I will then be able to make permutations that take in an opener recipe, and produce yet more recipes with many different point ranges for my Responder, Overcaller, and Advancer cookbook chapters.

That’s the big win for this mumbo-jumbo and not-all-that-easy process: it automates some potentially extremely tedious and time-consuming work.

Incident Report

Quick! Cover up the bottom half of this deal report!

Now: tell me how, as West, you make 4 clubs.

If you find a way that is different from what I describe below, please let me know. BridgeSolver was pretty definite about the line of play, at least with a queen of hearts opening lead.

Happy dealing!

This week’s update is heavy on the tech and process content since I’ve been working on mass-production of recipes and deals. The Incident Report at the end, however, is pleasingly non-technical.

Bridge Deal Generator Notes

Some local bridge pals asked me for a set of deals to practice the DONT convention. Looking back, I discovered that I had published no fewer than three blog posts about DONT, none of which resulted in a complete set of deals. Time to make it happen.

First up was Let’s Do the DONT from December of 2023. This one is noteworthy because it shows my old user interface, and because the writing style is that of a wild man (before I settled down and became wise and reserved).

I then continued that discussion the very next day in Let’s Do the Rest of DONT.

The deal generator was very hard to use back then. The thing that later became the Shaper panel, and the other thing that became the Cards panel, were on separate pages and they did not interact in any way during deal generation.

Last summer, I tackled DONT again, this time with the new, improved user interface, in the utterly non-cleverly-titled The DONT Convention.

At that point, I had 8 recipes covering the various DONT suit length combinations. But I had them for only one HCP range in the DONT bidder’s hand. I wanted the same recipes but with other HCP ranges. One can do that by hand, but it is tedious and error-prone.

A few weeks ago, I introduced the Permutations feature to make it easy to generate variations of a recipe. At that time, it only allowed you to generate combinations of North and South HCP ranges. That won’t do for DONT, where I wanted to vary the dealer’s LHO’s HCP ranges. So now, with the even newer eastHCPRanges feature described in the tutorial, you can vary North and East HCP ranges.

With that, I was able to quickly generate four variations of each of my DONT recipes, as you can see in this section of the cookbook. And now we have the tools necessary to mass-produce recipes in which 2nd seat varies.

Once I had my complete set of DONT recipes, I used the Recipe Collections panel to generate four fully-rotated deals from each recipe. I clicked the “Jambalaya!” button of the Deal panel to mix up the deals before saving them to a file for my friends to use.

Recipe in Focus

I was going to share a simple DONT recipe, but that’s really too simple and you can see all of them in the cookbook. Instead, since we have some new subscribers out there, let’s review some organizing principles. If you just make a big pile of recipes with no regard for grouping and naming, then mark ye well my words: you’ll be sorry.

So. From my earlier DONT efforts, I had these 8 recipes:

My goal was to make four of each, with four different HCP ranges in East. I used this permutation specification file (which you can see in the cookbook):

Note the “fileNameFirstNumber” setting. That’s how you tell the generator what number to stick on the front of your output recipe file names. With a setting of “1” I produced these four permutations of my first DONT recipe:

See how they each start with “0001” followed by a sequence number, then a bit of info on the HCP ranges contained in the recipe? This is how we get a) unique; and b) somewhat meaningful file names.

The filenames do not tell you that the deal is (hopefully) for DONT practice. Never fear! As the boss of your own computer, it is your job to group and name things appropriately. So, while I have been working at the individual file level, once I get a set of related recipes I put them into folders that supply the missing information.

Here you can see part of my cookbook file structure. Within the DONT folder, I chose to group recipes in sub-folders by suit lengths.

Higher level folder names tell you what you’re getting into. Everything inside the DONT folder relates to DONT, so I do not (don’t, that is) need to repeat that word in every lower-level folder and file name. To do so would be to court madness and also might exceed some filename length limitation.

Newbies note: You can see the entire cookbook, in both shared folder form and as a web page, at links provided in this user guide post. There you will see the above folder structure in action.

Incident Report

Here’s a hand from a recent club session. It presents challenges both in the auction and in the play of the hand.

Happy dealing!

Too bad they don’t give points for provisional results. Ahead by 9 match points with one round to go, then we dropped from gold to red. Still, one needs red in one’s march to life master, does one not?

One certainly do.

Bridge Deal Generator Notes

I thought playing three days in Gatlinburg would mean I had no time for deal generator updates, but I was wrong. No sooner did I get home than I saw an announcement for an application that will read photos of bridge deals (cards laid out face up on the table) and will produce a Portable Bridge Notation (PBN) text string of the deal.

I then realized that while you can load an entire PBN file into my generator so you can work with the deal, you can’t do that with just the “Deal” line from that file. I am referring to this line:

[Deal "N:KJ.T3.9863.AKQ54 AT9764.Q76.AQ.T7 Q832.AK4.J54.J86 5.J9852.KT72.932"]

You see, a PBN file of a bridge deal has multiple lines to give you a complete definition, like this:

[Event "Bridge, Out Ahead bridge session and ice cream social"]
[Site "Bridge, Out Ahead Central Command HQ"]
[Date "2026.04.23"]
[Board "1"]
[West "WESTWOOD, CLINT"]
[North "NORTHWOOD, CLINT"]
[East "EASTWOOD, EGBERT"]
[South "SOUTHWOOD, CLINT"]
[Dealer "N"]
[Vulnerable "None"]
[Deal "N:KJ.T3.9863.AKQ54 AT9764.Q76.AQ.T7 Q832.AK4.J54.J86 5.J9852.KT72.932"]
[Scoring "MP"]
[OptimumScore ""]
[ParContract ""]
[Generator "bridgeoutahead.com"]

You don’t really need all of that to reproduce the deal, but you do need three things: the Deal line, the Dealer line, and the Vulnerable line.

But hey, let’s not be obsessive. Given a Deal line, we can fake our way to any and all variations of dealer and vulnerability.

That is, we can do that now that I have added this handy Deal Text line at the top of the Cards panel:

This tutorial tells you how to make a deal from just the Deal line of a PBN file.

As for the application for capturing deals from photos, that is still under development. I will be happy to share it with you when the developer declares it ready for more users.

Recipe in Focus

Let’s do something simple this week.

I have just begun studying the Flannery 2 Diamond Opening, learning straight from the source: Bill Flannery’s own book on the subject. Now, I’m not saying that Flannery is simple. However, as with many conventions, the scenario it addresses may be summarized succinctly. The first line of the first chapter of the book says:

“Any hand containing exactly four spades, five hearts, and 11 to 16 high card points (HCP) is a probable Flannery opening bid.”

There follow 189 pages to help you firm up the “probable” part of that deceptively simple statement.

But let’s make a succinct recipe based solely on the succinct sentence, and let’s leave the complications for later.

Here’s the first of 2048 deals I generated from that recipe:

From my very limited reading of the Flannery book, I like North for a 2!D opener. Points are concentrated in the majors. It’s 3-1 in the minors.

Onward to the next deal:

Just one HCP less than the first deal. The heart suit is not inspiring. It’s 2-2 in the minors. It fits the definition, but it just doesn’t feel as good as the first deal.

This is how I study a convention, and it’s something you can use for self-study or teaching. Start with the basic scenario, get down to some deals right away, then start introducing variations as you learn more.

Incident Report

Here’s a hand from Day 3, afternoon Gold Rush session of the Gatlinburg Regional 2026. Not a terrible outcome, but was there a way to do one trick better?

Partner and I had an after-action discussion about this one. While I don’t think East can ever make 4C, it makes 3C all day long. We have a history of overcalling each other in a preempt situation, and then engaging in an internecine rebid battle. It never ends well. What we have settled on now is this: if opener preempts, responder will defer to him unless responder has something extraordinary. By extraordinary we mean a long, solid suit that might fare better than opener’s suit. Opener should then not insist on his opening suit unless it, too, is extraordinary beyond belief.

So in the above case, we might have stopped at 3CE and taken top board.

But we all know that a long suit in one hand means other long suits around the table. It can be hard to turn loose of your own suit.

Happy dealing!

Sometimes, though, you might get something like this:

[Deal “N:KJ.T3.9863.AKQ54 AT9764.Q76.AQ.T7 Q832.AK4.J54.J86 5.J9852.KT72.932”]

That is a single line—the one showing which cards are in which hand—from a bridge deal file using Portable Bridge Notation (PBN). People sharing deals in comment threads on websites will sometimes present deals that way, probably by cutting that single line from a PBN file and pasting it into the comment, or perhaps in an email or a text when sharing directly with someone.

Can you read PBN and envision the deal? I can’t.

You could key those cards into the Cards panel of the deal generator and then generate a deal in the Deal panel from it. But that is time-consuming and error-prone. There is a better way: the Deal Text field of the Cards panel.

To use the Deal Text, simply copy the Deal line into your clipboard from wherever you encountered it (perhaps in an online forum, where someone might share a deal that way) and then paste it into the Deal Text input field. Then press the “Enter” or “Return” key on your keyboard, and the deal will be placed into the hands in the Cards panel.

Here’s how it looks after I pasted in a Deal line but before I press “Enter”:

And then after I press “Enter” on my keyboard:

The “Deal” line does not specify board number, dealer, or vulnerability. But you can get all of that with the deal generator. Just set the dealer and vulnerability in the settings on the left side of the web page, then click the “Gen Deal = Cards, Ignore Shaper” button of the Cards panel.

You can accept default settings at left of page if you just want a single deal and you don’t care about dealer or vulnerability. Here, though, are the settings I use to generate 64 fully-rotated versions of one deal. I can then select the specific deal I want to study in the Deal display panel:

Bridge Deal Generator Notes

No new/changed features this week.

Recipe in Focus

Cookbook development has slowed due to the Huntsville tournament last week, and prepping for Gatlinburg next week. But recipes don’t have to be developed in large batches. Let’s make a couple of related recipes, right here, right now.

When partner opens 1NT and you have 8+ points and a 4-card major, you usually want to bid 2!C, Stayman to ask partner if they have a 4-card major. But if you are responder and RHO interferes, how do you bid Stayman?

Lebensohl to the rescue!

Because some of the bidding room has been taken away, you will need 10+ points for a game-forcing Stayman bid. Since the 2!C bid is no longer available, you use Lebensohl.

If you have a stopper in the interfering suit, you bid 2NT. Opener rebids 3!C. Now responder cuebids the interfering suit at the 3 level. Opener knows game is likely, and can decide whether to go for 3NT or game in a major suit. Yes, they may also need to explore for a minor-suit game, but let’s hope not.

Here’s a recipe that creates that scenario:

Here’s a deal generated from that recipe:

The other way to bid Stayman over interference is a direct cuebid. The saying goes “Fast Arrival Denies Stopper.”

We can start from the first recipe, but modify South to no longer have a spade stopper. To guarantee a stopper, the first recipe simply included a “K” placeholder in South’s spades in the Cards panel. For this recipe, we remove the “K” placeholder and in fact use no spade placeholders in South. We could plug in some number of zero-point placeholders, but there’s an easier option: use the “No Ace Spade,” “No King Spade,” and “No Queen Spade” shaper selections in South. South will get some random number of spades, but no high honors.

With those two quick changes, here’s the new recipe:

And a deal generated from the second recipe:

The Lebensohl section of the cookbook will eventually be chock full of that kind of thing.

Incident Report

This incident sets my teeth on edge, so I’m sure it will be painful (or painfully elementary) for many of you. Keep in mind that I’m airing these things to remind teachers and advanced players of the kinds of things that bedevil lower-level players. Also know that 90+% of the time—and certainly in today’s hand—the offender in these things is me. While it would be nice to sweep errors under the rug, the more-or-less permanent session records on live.acbl.org mean that outcomes, good and bad, are there for all to see.

In fact, I consider playing bridge an exercise in humility, requiring a willingness to fail in public. But there are no complete failures if you learn a lesson and resolve to try not to repeat the error.

In this one, the underbidding was a team effort (repeated around the room), but the poor declarer play was a solo effort by me.

Happy dealing!

Notice anything different? No? Well, look closely and you can see I am groaning under the weight of 1.41 gold points and 0.42 red points earned at the Huntsville, Alabama Spring Fling regional tournament. That’s small potatoes compared with the big winners knocking down 20+ gold points per event, but the 1.83 shiny, new points are mine, and I love them like Gollum loves Isildur’s Bane.

Seriously, though, it was a wonderful tournament and I learned a lot from partner and opponents alike. So many good players and all-around nice folks. And the egg rolls…oh, wait—that’s George’s area. I did have Chinese takeout for two lunches, though.

Bridge Deal Generator Notes

Improved Ease of Use

In last week’s update, I showed the new ability to display only the deal panel, which makes it easier to use the deal generator web page when sharing your screen for a class. It’s very easy to put the generator into deal-display-only mode by clicking the Square button as shown in the user guide; however, clicking that button is a possibly annoying extra step since you would have to do it every single time you load a deal from a deal report, and it is very unwieldy if the screen you are sharing is on a tablet. The web page is too large for the tablet when held vertically (short edges at top and bottom), so you have to scroll the page to the right to get to the Square button.

I thought about putting another deal-only Square button on the left side of the page so it would always be in view, but then I had a better idea, leading to this change:

I have now made it so that when you click the deal link in a deal report, the deal generator will automatically go into deal-display-only mode. (This is only true of deal reports created from today onward, as older reports will not have the special sauce mojo in their deal links.)

What does this get you? Easy transitions from showing the deal report to proceeding to work with the deal in the generator and, from there, other programs (Handviewer, BridgeSolver).

Here’s a deal report on my tablet:

You would, of course, have a learned lesson or meaningful meanderings or exciting exposition in your own deal report. Now, when I tap the “Click here…” link, the deal generator pops open with that deal and its auction loaded, in deal-only mode with no need to click the Square button. Those watching your shared screen will not have to watch you scroll around looking for that button. Here we are in the deal generator after clicking the link in the report, with the whole thing fitting nicely in a vertical screen:

Get a real auction into Handviewer

Have you ever noticed that when you look at tournament results in live.acbl.org, and it provides a “Play” button to let you replay the deal in BBO’s Handviewer, that it shows the correct contract but the auction is completely bogus? That’s because actual auctions are not recorded, but the final contract is known. So, in order to make the deal playable, Handviewer plugs in a the minimum viable auction. Like this, for instance, from Huntsville:

This is indeed playable, and if you are only interested in the play of the hand to that contract, it is perfectly fine. But if you are teaching a lesson from your deal report, you probably want your own auction, not the minimum viable auction, in Handviewer.

If you included an auction in your deal report, that auction will be loaded to the deal generator when you click the link that brings up the deal in the deal generator. Here it is, enlarged from the earlier screen capture:

Now when you click the Handviewer button at the top of the deal display…

…the resulting Handviewer page will have your auction, not a made-up auction:

If no auction was saved to the link in your deal report, you can always key one in on the deal display page before clicking “Handviewer.” That can get tedious, though, so if the auction matters to your lesson, it’s a good idea to go ahead and key it in—once—before making your deal report.

If you need a refresher on how to key in an auction, here’s the user guide.

Recipe in Focus

Some friends at the local club are studying Drury together. I set out to divide the Drury chapter of my cookbook into three topics: Drury, Reverse Drury, and Two-Way Reverse Drury. After making a decent recipe, though, I realized that the hands for all three are essentially the same; it’s the bidding that might differ. You would think that kind of thing would be obvious to me by now, but little factoids like that still sneak up on a chap.

Here’s a recipe where (I hope) 3rd seat can open, and first seat can ponder whether to make some kind of Drury bid. It’s a good use of multiple shaper tabs, with two each for heart openers and spade openers, and within each major opener there’s a shaper where responder has 3 trump cards, and another with 4 trump cards.

Here’s a deal generated from that recipe:

It looks like South could open 1 spade, and North could bid 2C (Drury). Will North add points for the singleton heart and bid 2D? Will partner alert the bid (not a given—this doesn’t come up all that much)? Will Dash Riprock get to the train track in time to avert disaster? And…what about Naomi?

Bet you didn’t know bridge recipes could be so dramatic.

The recipe does not limit West’s HCP. As the user or teacher, you have to decide what you want to do or say about bidding Drury in competition. Note that if North and East are both too light to open, and South has anywhere from light-to-legit opener, West is very likely to have “interesting” points. You really can’t explicitly restrict West, since the points have to land somewhere and if you make all four hands too light, you have allocated fewer than 40 HCP in total and the deal generator will search forever without finding a deal. What you might do, though, is give East something like 6-9 instead of 0-9, so that West will get fewer “leftover” points. It all depends on the kinds of deals you want—those with no interference, those with some, and those with random, realistic quantities of interference.

Incident Report

Hey, fellow non-experts, and/or the teachers who teach them: are you attuned to the situation where partner lays down an artificial bid in full expectation of you magically supporting their suit(s), only to see you go all in on the suit of the artificial bid?

It happens. It’s a feature, not a bug. For instance, if you get into a New Minor Forcing bid of 2 diamonds, and partner happens to only have diamonds, then don’t be surprised to not end up in no trump or a major suit contract.

For a possibly less commonly-used convention, here’s a facsimile of a hand from the Huntsville Spring Fling. I say “facsimile” because it was in Swiss Teams with no hand record; never fear, I approximated it with the deal generator.

Yours truly was West. I make it a habit to not look at partner’s or opponents’ faces during bidding and play lest I give or receive extraneous and/or unauthorized information (and if someone’s sneering at me I don’t care to know it). But this time, I couldn’t resist a little peek through my overhanging eyebrows.1 East did a great job of barely reacting to the Pass, and we made our bid.

Happy dealing!

Bridge Deal Generator Notes

Based on real live feedback from real live teachers using various outputs from my generator in real live classes, I wrote up a tutorial on how to use the generator website to present deals to an audience.

Most of that tutorial just emphasizes features that have long been available directly from the deal generator, but whose usefulness may not have been apparent to all: BridgeSolver, Handviewer, and deal reports. Those are very relevant to presenting to an audience because, if you are screencasting to a large television or monitor for an in-person class, or sharing your desktop in a teleconference, you have quick and easy ways to present deals and to then click a single button to get into the BridgeSolver or Handviewer to step through and analyze card play. As for deal reports, they are not ideal for screen-sharing, but they make great lesson handouts.

The tutorial, and the Deal panel user guide, also describe a brand new capability: using the “square” button of the Deal panel to hide the Deal Recipe panel, which then lets you and your audience focus on just the current deal, like this:

See? No shapers and cards and placeholders to confuse those who are not into deal recipe design. More room for just the deal. To get the other goodies back on the page, you just click the “underline” button (up there to the right of the yellow “Negate Smörg” button and all the complicated busy stuff pops back in.

Your mileage may vary, but when I bring up the website in my tablet, click the “square” button, and turn the tablet so it is vertical, that whole web page with just the deal panel fits nicely in the tablet screen. So, aside from screen-sharing, you can also more easily study deals on a tablet all by yourself, without having to shift the web page around to make the deal panel stay in view.

Recipe in Focus

Last week, I referred to gaps in the reverse section of the cookbook—gaps that would prevent one from generating particular scenarios. I think now that “gaps” is a misnomer since highly-specialized recipes exist to deliver highly-specialized deals. The so-called gaps are a feature, not a bug.

So what I should have said was that my current set of reverse recipes is useful for studying some, but not all, Lebensohl Over Opener Reverse scenarios.

Now that I’ve cleared that up, let’s get down to cases and see how we can adapt an existing recipe to fit a different scenario.

Back to the book The Lebensohl Convention Complete.

A note on the book in general: I have taken to carrying it around at club sessions for a quick look in between tables. The sight of it has sparked gladsome reactions from some very senior and accomplished players. Seems to be a well-regarded book.

At top of page 82 of the 1987 edition, we see this bidding sequence between opener and responder:

1C - 1S - 2H - ?

Below that we see 5 hands for which we are to name the next bid by responder. The second responder hand is:

The responder rebid is 3 hearts, supporting opener’s reverse suit.

Cool lesson, bro’, except you can’t make that deal with my non-gapalicious but highly-specialized reverse recipes. I purposely made the first set of reverse recipes such that responder will not have support for either of opener’s suits. Here’s the club-with-reverse-to-hearts recipe:

What to do if you want responder to be 5-4 in spades and hearts as in the example from the book? Easy enough—see how South looks now:

Does it work? But of course:

Given the possible 21-HCP that North can have, North might open 2C with some of the generated deals. That’s fine, just bid them however you prefer. If the high-point deals occur too often and make it harder to select deals for studying or teaching reverses, just lower the high end of North’s HCP range a bit to keep them from having 22+ total points.

I will be building out the Reverse section of the cookbook to cover more scenarios, such as the one demonstrated here. Until my complete set is available, you can easily modify the current recipes to get what you need.

Incident Report

Since I often share my true disasters, I sometimes like to mix in a deal where we played it all wrong but triumphed anyway. That’s how it goes in bridge, especially in a small room (3 and 1/2 tables in this session).

Happy dealing!

You do not have to know anything about designing deal recipes or generating deals if you don’t want to. The methods described here assume that you already have a set of deals in one or more files.

PDF Reports

This tutorial shows you how to make your own deal reports. You can then choose how to share them.

On Paper

You can show the deal, an auction, and a Double Dummy makeable contracts table on a deal report PDF. Ideally, you will write a lesson that the deal illustrates. Printed deal reports can be used as handouts or compiled into a booklet for your students.

The deal report includes a QR code. Users may use their cell phone or tablet to scan the QR code and bring up the deal generator web page with the deal loaded into the Deal panel. They will then have access to the other deal analysis tools described further on in this guide.

Electronically

You can share the deal report PDF via email or text, or place it in a shared online folder for others to download.

When viewing the PDF on their device, users can click the URL just below the auction to bring up the deal generator web page with the deal loaded into the Deal panel.

On a large monitor, or via screen sharing in a teleconference

You can share your screen via local screencasting, or in teleconference software (Zoom, Google Meet, etc.). However, while the deal report PDF contains a lot of information, it is static and may not be the best choice for holding the attention of your audience. For better screen-viewing options, keep reading!

The following sections describe web page features that can be shared via screencasting in front of an in-person audience, or via screen sharing in teleconferencing software.

Deal panel

The Deal panel of the deal generator is also static (that is, you cannot interact with the deal). However, it is a great starting point for presenting your deals in a more interactive way.

For a class, you probably don’t want to show the very crowded and busy deal generator web page, as it might overwhelm and distract your audience. For that reason, you should click the “square” button at the top right of the Deal panel:

This will hide the Deal Recipe panel. You can then zoom your web browser in or out as needed to get the Deal panel to the desired size for presentation. Here, I have done just that. This is not a fragment of my screen—it’s the entire web page showing only the Deal panel:

I have loaded only one deal. In a class, you can use the “Load File” button to load one deal at a time. You can also load in a file containing multiple deals, and use the arrows at the top right of the Deal display area to scroll through them.

This display can be your starting point for discussing the deal. Just keep this tab open in your browser. You may click buttons to view deals in other programs while you present your lesson, and those programs will get their own tab in the browser. When you finish explaining a deal, just close that other tab and then load in or scroll to the next deal in your lesson on the Deal panel.

Handviewer web page

For a deal display that many will find familiar, click the Handviewer button at the top of the Deal display area. You will see this:

While this page has the Bridge Base logo and the software is provided by bridgebase.com, you area actually still on the Bridge, Out Ahead website.

The “Play” button lets you step through play of the hand, with you (the presenter) choosing each card to play. You can even rewind and make different choices as you explain things to your audience.

Note, however, that for “Play” to work you must specify a contract. In the above display, the auction panel is empty so you cannot play this hand. So, before clicking the Handviewer button, follow this tutorial to key in an auction back on the Deal display panel of the deal generator.

While you may want to plan ahead and you may even have your auction text stored somewhere from where you can cut and paste it into the Deal display Auction text box, you really only need to provide any valid auction ending in three pass calls. So for the above hand I might key “7n,p,p,p” in the Auction text, like this:

Then when I click the Handviewer button, we see that I can actually play the hand:

The “DD” button at the bottom of the page activates Double Dummy analysis. With it, you will see colorized numbers showing the result of each card played. In this example with “DD” activated, we see that North/South will make their contract if the ace is played from dummy; if they play any other card, they will go down at least one trick:

BridgeSolver web page

The final option for quickly and easily analyzing a deal for your audience is reached by clicking the BridgeSolver button at the top of the Deal display area. You do not need to key in an auction before clicking the BridgeSolver button.

Here’s what you see when you click that button:

To step through and play one card at a time, first click on a contract in the makeable contracts table at the lower right of the page. Here’s what happens when I click “7” in the NT column for South:

The program colorizes each card in the hand whose turn it is to play, and it shows how many tricks that player’s side can expect to win, in total, if each card is selected.

The “<“ button is just like the “Rewind” button of the Handviewer page.

It’s not Friday yet, but on this auspicious day I thought I would address some topics that don’t fit my usual weekly post format. I thought it would be fun to look both backward and forward in time.

Looking Backward

Just last year, we celebrated the 100th anniversary of Harold Vanderbilt’s development of Contract Bridge. Bridge Bulletin and other publications covered the topic quite well, but none of them mentioned Vanderbilt’s heartfelt wish to banish a prominent element of the game. He famously wrote, “I detest card play at no trump. It is the refuge of scoundrels who cannot conceive of the proper management of a trump suit. I welcome this opportunity to banish it from our game. Harrumph.”

Thus did Vanderbilt outlaw no trump contracts in his final manuscript of Vanderbilt’s Contract Bridge Compleat - 25 tickets to Slam Towne! [Ed. This also marked the advent of publishing bridge advice in groups of 25, and promising outsized results at the table.]

Ironically, though, he entrusted delivery to the publisher of said manuscript to a scoundrel, his nephew Dwayne “Bud” Vanderbilt. Young Bud stopped at a den of iniquity (the local whist club) on the way to the publishing house. There, he fell in with local sharps and rapidly lost all of his funds. He was then reduced to writing IOUs to cover his additional losses at games of Gutter Bridge (the kind with no trump). He tore pages from Uncle Harold’s manuscript for this purpose, thus removing the prohibition against The Forbidden Contract.

Harold was devastated, of course, but the die was cast since neither he nor the publisher was willing to eat the cost of destroying the first print run of the book. Thus did economic concerns outweigh ideas of suit-contract purity.

And so it is that, to this day, we still play Gutter Bridge.

Looking Forward

Speaking of economic concerns, did you ever wonder why, since we may only bid “up the ladder,” we need four (4) bidding boxes per table?

If you never wondered that, consider yourself in the minority, for bidding box redundancy was the #1 complaint in a recent ACBL-sponsored Satisfaction Survey.

ACBL to the rescue! Beginning at 12:01 AM UTC on 1 January, 2027, The Laws of Duplicate Bridge will be amended to allow only one bidding box per table.

If ever a rule was a slam-dunk to both understand and implement, this is it. However, it can take a while to properly promulgate even the simplest bridge rule (you would know this if you had ever promulgated). Of special importance is the need to convert the seemingly-simple into proper and highly compressed legalese for the official rulebook, and then to update Duplicate Decisions to expand it back into simple-ese with many examples for those who are slow on the uptake or who are not attorneys.

But while we wait for 2027, here’s the gist in layman’s terms:

• There shall be one (1) bidding box per table.

• Since North must manage the score-keeping device and South must manage the boards, East shall be designated the Bid Box Croupier and is the only player allowed to move the bidding box. West may continue to just sit there, leeching off of the efforts of others. No judgment here, West; it’s not like we’re assigning seats in a lifeboat, so don’t worry if you seem useless.

• At the beginning of the auction period, the bidding box shall be placed in the center of the table in the Mini Lazy Susan rotation disk, which it turns out is actually a thing so this part is no joke. This author does not receive affiliate fees for any purchases made through that link.

• After each player selects and places his/her bid or call, the Bid Box Croupier shall rotate the Mini Lazy Susan one-quarter turn to face the next player in turn.

• The Bid Box Croupier shall rotate the Mini Lazy Susan in strict tempo and with consistent force throughout, so as not to impart any unauthorized opinion of the prior bid to West (if West happens to be awake; as with finesses, that’s a 50-50 proposition). In particular, no “accidentally” spinning the Mini Lazy Susan when partner (West, again) passes industrious East’s forcing bid.

• To preserve both decorum and hygiene, the Bid Box Croupier shall be required to wear sleeves that reach at least to the elbow. This will prevent unwanted (and gross) bare armpit overhang as he/she performs his/her duties, which necessarily involve much reaching across the common area of the table.

• Each club or controlling tournament authority shall provide a suitable top garment for croupiers who arrive wearing sleeveless tops or short sleeves that, upon reaching forward, expose the armpit skin and/or (yuck) hair.

• Loaner croupier garments shall be laundered—at club/authority expense—at reasonable intervals or when visible stains or detectable odors dictate.

• After the end of the auction period, the Bid Box Croupier shall collect the bidding cards and return them to the lone bidding box, and shall thence move the Mini Lazy Susan and the bidding box to the side table or, if there is no side table, into their own lap until the next hand comes up for bid.

I hope you have enjoyed this jaunt into our shared bridge past and future!

Happy dealing, and happy April 1st!

Bridge Deal Generator Notes

I added a feature to rapidly generate variations on a given recipe. There are many ways you might want to vary a recipe to create different scenarios. The lowest of the low-hanging fruit is to vary the HCP for opener and responder. The feature is described in this new user guide entry.

After spending a couple of weeks trying to manually create variations, and having to start over to apply corrections to dozens of recipes, I was able to use the new Permutations feature to create most of the 162 recipes in this section of the cookbook devoted to opener reverses. It took all of ten minutes, much of which was spent in giddy celebration as each batch of 18 recipes emerged. So, maybe 7 minutes of recipe generation, and 3 minutes of jumping about the room; your mileage may vary depending on the condition of your jump muscles and your excitability.

Recipe in Focus

I have been sneaking up on Lebensohl After a Reverse lo these many weeks of trying to make a large collection of reverse recipes. Now that we have so many from which to choose, let’s see how they help us ponder Lebensohl.

I am learning all things Lebensohl from The Lebensohl Convention Complete by Ron Andersen. The most basic point is that Lebensohl after opener’s reverse lets the responder show either a weak or a strong hand.

With a weak hand, responder bids 2NT; then, opener with a minimum hand (in context of a reverse) bids 3C. Responder can then sign off without fear of opener thinking it’s time to go to game.

Take a look at the Reverse section of the cookbook.

In the cookbook, each Reverse topic has 18 recipes with different ranges of HCP. Here’s the section where opener bids clubs then reverses in hearts.

For the weak response hand that would reply 2NT, pick one where responder has 6-7 HCP. For one where opener would complete the relay and bid 3C, pick one where opener has 17-18 HCP. Here it is, in report form after clicking on the recipe link in the cookbook:

Now generate a deal from that recipe. Given the borderline points, you would expect to be able to use the 2NT-3C Lebensohl sequence.

North can open clubs—check. Responder bids another suit (diamonds)—check. Opener can reverse in hearts—check. Now, does responder go for broke with his long suit, or use 2NT to signal low points and a wish to sign off?

Double Dummy analysis suggests 2NT followed by sign off.

Now, with that same recipe you can generate many, many deals, and some of them will result in game-going hands in spite of having the same point limitations as the above deal. That’s just the way it is in real life and in the deal generator. Distribution matters. Use this fact to study different deals and see if you can learn to spot the hands that are worth a game try.

Notice that all we have done so far is choose an existing reverse recipe, and look at the resulting deal in light of Lebensohl requirements. We haven’t actually built a “Lebensohl” recipe.

Now suppose opener has the higher end of the reverse point range. There’s a recipe for that, where opener has 19-21 points and responder has 6-7 HCP. Select it and check the report in the deal generator:

It’s exactly like the previous recipe, except in this one, North has 19-21 points. Let’s generate a deal and see how Lebensohl applies.

Well, well, well. Responder will likely bid 2NT after opener’s reverse into hearts, hoping to sign off in spades. But with 20 HCP and knowing that responder should have some decent spades, opener might refuse to relay to 3C, and go to 3NT.

Again, I didn’t have to build a “Lebensohl” recipe—I just used a reverse recipe and Lebensohled it up in my head while analyzing the resulting deal.

As a student or as a teacher, you can use recipes from the cookbook as the basis for your own study or lessons. And, of course, you can modify them to suit your needs.

Even with 162 reverse recipes, there are gaps; one of those gaps will prevent creation of a certain very specific Lebensohl scenario. I’ll discuss that, and how to fill the gap, next week.

Incident Report

Happy dealing!