(Correction: it is BBO bidding tables, not teaching tables, that limit one’s ability to move to all four seats. You can switch between North and South, but cannot occupy East or West. This post has been changed to clarify the capabilities of BBO bidding and teaching tables.)
Computation Corner alert! This blog post goes into a lot of the why and wherefore of a new development. If you prefer the bare bones explanation of the feature without the inner thoughts of a programmer, check out the user guide.
Sometimes I think the deal generator has reached maximum usefulness. Then I actually try to use it, and it doesn’t take long for me to decide I need a new feature. Thus was born the deal variegator, or, with branding in mind: The Deal ‘Gator.
I should mention that this feature was inspired by discussions with another bridge software developer. His end of the discussion involved wishing for perfectly reasonable features that required ranging through and across large files containing bridge deals. My end of the discussion involved saying, “Nope, can’t be done, sorry. I prefer to start at the deal-generating end of things.” Then I would go off to do some actual bridge study using my generator and I kept running into things that made me think, “You know, I sure wish I could range through and across large files containing bridge deals.”
The recent Smorgasbord feature emerged from those discussions, as did deal output filters and the deal accumulator.
It’s starting to look like I need to a) stop talking to that guy; or b) just find a way to make useful things work, since that’s what I wind up doing after all my nope-saying. I think I’ll go with (b) because I need these features—badly!
That said, it is entirely likely that the latest snazzy bits, taken individually or together, don’t quite meet my friend’s exact needs. If so, that is entirely due to my tendency to first try to generalize features to see if they could then be made to give other desired results.
Let’s look at ol’ (new) ‘Gator.
The ‘Gator lives in the File Load panel. When inactive, it has no effect on file load operations. It is inactive when it looks all cute and cuddly as shown above. If you were to load a file containing deals (that would include LIN, or PBN, or HTML navigator files), it would just be loaded as usual.
You activate the ‘Gator by clicking on its image, which as you can see gets it all primed and ready to mix things up for you (hence the hand mixer and bowl of bridge deals):
So far the ‘Gator has not done anything. I’m just showing you how to turn it on and off. To deactivate it, you click the image again and off to beddy-bye it goes:
‘Gator’s snoozing state is the same as its initial wide-eyed gaze which only appears when you first load up, or reload, the generator web page. It has no impact on deal file loads when in wide-eyed or snoozing state.
The ‘Gator never affects the loading of recipe and smorgasbord files. It only changes deal-file load operations.
I’m probably delighting the kids with the cute gator but losing the bridge teachers and students. Fear not—here comes the functionality!
When I play at the club, I like to review the results and take a deep dive into the deals. My deep dive consists of loading the deals into Bridge Base Online and rebidding them. Due to moving from table to table, the seat from which I played changes every few boards. If I wanted to always rebid each board from the seat where I played it in real life, I would have to move from seat to seat in my BBO bidding table. But bidding tables only let you occupy South or North.
In BBO teaching tables, on the other hand, you can move yourself freely to any seat. However, if you want to play the same deal from more than one seat, you have to change your seat, then you have to get back to the deal you want to replay. There is no way to tell the teaching table to go back to an earlier deal. To get back to the desired deal, you have to change your deal source to something else (random, perhaps), redeal once from that source, then change deal source again back to your collection of deals, then “redeal” until you get to the one you want to replay.
A solution to this is to load up your deal file in my generator, then use a navigator to bring up each deal individually in a new page. Loading a deal via the navigator also loads it into the Recipe Maker. So now you could generate multiple versions of the original deal, rotating the cards around so that you can find a deal where you could play it from “your” seat in BBO instead of from whatever seat you were sitting in at the club. You would have to do this for each deal, save off the version you want as a LIN file, then collect up all your saved files and load those into BBO.
It’s great that you can do this, but it’s a royal pain to actually do it one deal, and one output LIN file, at a time. In fact, it’s every bit as painful as swapping deal sources in the BBO teaching table.
The ‘Gator relieves the pain of having to repeatedly reset your BBO teaching table, and of laboriously constructing deal files to try to avoid that other pain. Here comes a demo.
First, as a baseline, I show you what the generator looks like after you load a 36-board file (in this case, The Common Game afternoon file of July 3, 2024, in PBN format) with the ‘Gator turned off:
The name of the file that was loaded is shown in the File Load panel. The Generated Deal panel shows board 36 because, when you load deals from a file, the last deal in the set is always the last thing displayed. Note also that the current deal is also present in the Deal Recipe Maker panel, looking like a recipe. In fact, a deal that is fully specified down to the last card is a recipe—a very explicit one; this, plus the fact that deals actually go into the Recipe Maker first, and thence to the Generated Deal panel, means that we conveniently have access to deals-as-recipes while loading an input file of deals. This makes it easy to manipulate the deals in interesting ways—automatically, behind the scenes.
Notice also that down in the File Saver panel, the Accumulate Deals count and the Smorgasboard count are both zero. I mean, why wouldn’t they be? You haven’t done anything to put deals or recipes into those hold areas, have you? This will become relevant later on.
Now, to play these boards in BBO you would click the “Save LIN” button and then go over to BBO and load the resulting LIN file. Then you could play the boards, either all from the same seat (which is probably not how you played in the club) or else go through the rigamarole of changing your seat and your deal source, mid-session, at the teaching table. Painful.
Now let’s wake up the ‘Gator and load that same file again. I click the image of the ‘Gator, then I load the PBN file again. This time, the page looks a bit different:
There you have it, apparently all 64 boards were loaded—hey, wait just a danged minute! There were only 36 boards in the input file! And now that I look more closely, this last board is the same hands as the last board from the 36-board file, but the hands are rotated three seats clockwise! And the Accumulate Deals count is 144, and the Smorgasbord recipe count is 36. I’m scared! Someone hold me!
Fear not, I say! The file has merely been ‘Gatored, or variegated. Let’s save the accumulated deals as a LIN file and see what we have. I change the output file name to something readable and click the “Save LIN(s)” button. Here’s the first page of records in the resulting LIN file:
There are no blank lines in the file as output by my program—I inserted those to make record groupings easier to see. What we have here is a file containing four LIN records for each input deal record from the PBN deal file. You may notice a strange sequence of board numbers (in LIN format, the board number is at the left, just after the “qx” tag).
What the ‘Gator does is take each input board one at a time, put it into the recipe panel, turn all “rotate” features “on”, and set Number of Boards to 64. It sets the Deal Shaper to default values so that they don’t prevent deal generation, then it programmatically clicks the Red Button. The result is a 64-board set of one deal, in all possible combinations of dealer, vulnerability, and hand/seat rotation.
This is a significant departure from deal file loading as originally implemented. Without the ‘Gator, the generator simply loads deals—it ignores the rotation and number of deals controls on the left side of the page, for those exist to control how deal generation from recipes behaves. With the ‘Gator, the program not only pays attention to those controls, it sets them itself to achieve TGM (Total Gator Madness).
For the first input board, the program then uses the deal filter to select four boards that are “like” boards 1, 18, 35, and 52 from the 64-board set. Those boards will have the dealer and vulnerability based on their board numbers in the standard duplicate scoresheet. The first board will have the hands in the seats as in the original deal; the second will have the hands rotated one seat clockwise; and so on.
Now when you import this file into BBO, you can either replay each deal four times for the deepest of deep dives, as you will play each of the four hands from your seat with no need to move yourself to a different seat and reset the deal source. If you are only interested one or a couple of the configurations, then just hit “redeal” in BBO to skip the ones you don’t want to play.
The second group of four boards were also generated from one input deal from the PBN file—the second deal. They are numbered 2, 19, 36, and 53 because the ‘Gator uses a different deal filter for each four-board set. The four boards still represent the input deal, rotated so that you can play each hand from one seat. I chose a different set of board numbers for each group of four so that the user doesn’t get locked into seeing only one set of four board numbers and configurations.
As it produces each four-board set of the same deal rotated around the table, the ‘Gator will assign board numbers based on the 16 four-board sets shown above in the Deal Filter dropdown. After it assigns the 16th set of four board numbers, it wraps back around to the first set, with 1, 18, 35, and 52.
You may observe that this board numbering scheme means that most of the boards will have dealer/vulnerability settings that differ from those of the original deal. That’s right! But if you only want the original deals, just use the original 36-board file! The ‘Gator exists to give you variety—hence the name “variegator”.
My plan is to actually try to play through a 144-board set. Or actually 100 boards, since the club session I play in plays the first 25 boards. I have only done such deep dives on one or two deals at a time, since I didn’t have the means of mass production. I’m curious to see whether replaying every board from every direction in a short span of time helps my bidding and card play, sort of like the Suzuki method of repetitive drilling, but applied to bridge.
Here’s the resulting 144-board LIN file loaded into BBO. Some bridge software doesn’t like non-consecutive board numbering, but BBO has no problem with these funky numbers:
Finally, we saw that after the ‘Gator did its thing, the Smorgasbord count in the File Save panel was 36. That’s because it saves each original deal, converted to a recipe with all rotations turned “on,” to generate 64 deals, into the Smorgasbord hold area. You can save those recipes off into a Smorgasbord file, which will let you select recipes randomly if that’s what you want to do. While I don’t know that random selection from 36 recipes based on one day’s Common Game file would be terribly useful, random selection from a large number of designed instructional would be.
This feature was easy to program, as it consisted mainly of programmatically calling functions that are normally invoked by button clicks. That is the very definition of automation. The stage is set for further automation as the need arises.
Happy dealing!