A Slew of Changes
Randomizer, Good Suits, Semi-Balanced Shape, Point Ranges, and Recipe Fulfillment
Hi, bridge pals.
Earlier, I announced my plan to exercise my bridge deal generator by creating a cookbook to recreate the configurations available in my old Custom Deal Menu. In that announcement, I mentioned how, just a few recipes into the process, I found a defect in the generator, which I quickly corrected. I also wrote that I expected to discover more flaws or the need for new features.
I was right! I found flaws and fixed them, and I hit some pain points that caused me to develop new features. This post tells you a bit about each issue, and how it was addressed.
Deal Recipe Randomizer: Now fully explained in relevant user guide posts and in its very own tutorial, the recipe randomizer is a way to use recipe placeholders (that is, anything other than a specific card) more flexibly. Used properly, the randomizer lets you write more expressive recipes, and fewer of them.
“G” Placeholder in Recipes: Also receiving its own tutorial, this feature lets you easily specify a “good” suit of the 2-of-top-3-honors variety. The “H” placeholder was already available for general “honors” needs. When used in recipe randomizers, ain’t no variety of good suit that G and H can’t express.
Semi-Balanced Shape: The deal shaper panel now includes “Semi-Balanced” as one of the shapes you can specify for each hand. In building out my cookbook I haven’t actually encountered a configuration or convention that specifically asks for semi-balanced, but it has been in the back of my mind from the time I first created the deal shaper. It’s early days in mass recipe creation, so I’m sure semi-balanced will come up eventually. As discussed elsewhere, I have tried to minimize the amount of actual bridge knowledge built into the generator, preferring to let the mind of the user supply the knowledge and let the cards fall where they may. If you think about it, hand shape might be the only bridge concept (other than 52 cards, 13 per hand) hard-wired into the generator.
In supporting only “any" or “balanced” or “unbalanced” shapes, I think I went too far. Sure, you can fiddle around and make your own semi-balanced hands with recipes. But semi-balanced exists as a defined shape (it’s 5422 or 6322) and so I should support it. Note that while balanced precludes unbalanced, and unbalanced precludes balanced, I chose to make unbalanced include semi-balanced, and semi-balanced is, in fact, a subset of unbalanced and an oft-unacknowledged cousin of balanced; but you’ll be relieved to know that in my program, semi-balanced categorically precludes balanced. Or, to summarize.
Shaper Point Ranges: Until recently, my shaper let you request up to 40 HCP for each hand. Any fool knows that the most HCP one hand can possibly have is 37. Now, that fool-known knowledge is included in my shaper definitions. Rather than enrage anyone who innocently built and saved shapers with the 40 HCP maximum, I made it so that if you use a link or import a file with anything more than 40 HCP in the lower or upper end of a hand, I silently knock it down to 37. This is, I think, better than snidely assaulting you with error messages if you try to use a shaper that I let you create in the first place. Note that I assume a world in which users are saving off and reusing shapers. Gee, I hope someone is doing that!
Recipe Fulfillment: I used to toss and turn at night worrying about the known shortcomings of my recipe fulfillment code. Seriously. Egg on my face; big disgrace, etc. etc. all over the place. It’s still not perfect, but now that I have repaired the major flaws I can discuss them openly.
“XXB” used to give me fits. You could put that in a recipe, clearly expecting to get two and only two cards in a suit. But it would routinely assign three cards. Fellow programmers will laugh at the fact that I had a menagerie of exotic test cases to try to confound the recipe processor; it would handle all of them with aplomb, but then deliver up three cards for “XXB” about 25% of the time. It was so comically cruel that I began to suspect an infestation of artificial intelligence.
There were other unexpected results, of course, but I chalked them up to complexity and the randomness that, in the end, will always affect my results. But “XXB” with no other recipe in any suit in any hand—come on! That’s not complex!
It turns out that a major logic issue was causing many of my poor results, including the glaring “XXB” issue. Long story short (too late, I know), I had to gut and reconfigure the fulfillment logic to prevent a quite large number of possible errors, among them the “XXB” thing.
“XXB” is solved, and with it many other foul conundrums. A side effect of making the recipe processor more accurate is that some randomness has been subtracted, to wit:
Recipe lines like XXXXX, with no “B” on the end to ensure a specific length, used to generate anywhere from 5 to 13 cards. Usually 5 or 6, but it could randomly go up to the maximum allowable cards in a suit. With the reconfiguration of my code, you are much more likely to get only five cards even without the “B” on the end; you may get six from time to time. You probably won’t get higher numbers.
Well, that takes away a capability you used to have. “XXXXX” used to mean “at least 5” but now it seems to mean “usually 5, rarely 6, never more.” I repeat: never more. Quoth the blogger: nevermore.
Luckily, I have lately added randomizers that not only let you control the number of each placeholder type. So, to say “at least 5 of any card” in a suit you would prefer “(5-13)XB” over “XXXXX”.
As you can tell from the direction of my changes, I accept randomness and imperfection, but I like to be able to control both to some extent. “XXXXX” as a method of getting a random number of cards (but at least 5) was an accidental feature. Nice, but not essential.
The State of the Cookbook: It’s not good. I was three sections into it before the hard labor got to me. The changes detailed in this post were all necessary to make my own work easier, and to enable creation of more generalized recipes. Now that I have better tools at hand, I’m going to have to start over on that cookbook. The existing recipes work, but they are not good examples for others to follow. Back to the drawing board. I’ll announce when that cookbook is complete, and hopefully it won’t require more generator changes.
Happy dealing!