[kladenak]

Does anybody know what is the intended BBO direction re FD CCs?

I am using the Web client which seems to be the intended way forward of BBO. However my partner uses the old Win application and so we are wondering what is the best way of creating our CC. I downloaded the FD editor and I am happy to spend the necessary time with it, but I would like to avoid the effort should BBO want to move to the simplified CCs available in the web app.

Any ideas / experience / recommendations?

[fred]

I would say that FD is not the way forward.

FD seemed like a good idea at the time (and still does), but for a variety of reasons that project did not work out as we had hoped. While it is certainly possible that we will revisit this concept one day and try to improve the implementation of FD, we currently have no plans to do so. Given all the other things that we would like to get done, I strongly doubt that we will be devoting any significant resources to FD any time soon.

I think it is safe to say that we will continue to support FD in its current form as long as that is feasible. As of right now, I have no particular reason to believe that this means anything other than "forever".

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[mtvesuvius]

An interesting topic that I would like as an operator occasionally, would be to load a pre-made FD card when Vugraphing for a pair. Having to option to do so might be a nice touch, and would make alerting some calls simpler (As well as provide a basic system outline for anyone who is curious). Not sure if it'd be practical to have, but for pairs who are on vugraph enough, with their permission, perhaps we could build FD cards.

[kaltstart]

In my opinion, the FDCC is one of the nicest features of BBO. Maybe the reason why the standard CCs aren´t used much is that they don´t contain much more than the definition of the opening bids and 1st round responses. For the natural systems offered, the explanations of further bids might be more interesting for the opponents. One very detailed CC of Polish Club WJ2005 by Gerben on the other hand is used by many players.

The idea of Adam to be able to load those in the Vuegraph is very good, imho. Especially if the explanations given by the CCs could be seen also later when the deals are stored in the vuegraph archives.

[helene_t]

I think FD is a great idea but to be honest I don't bother making FD cards myself. A more productive version of bidedit, integrated in the flash client and/or allowing local FD files to be uploaded without using the windows client, would make a difference to me and I would make FD cards for my regular partnerships, and also elaborate on the Forum Precision file.

But I can understand that Fred has more important things to do. After all, it is a small fraction of the users that are system designers, the suite of stock CCs already available probably suffices for most, and it would be very hard to make a productive bidedit tool that could be used by non-geeks.

[mtvesuvius]

Very true Helene, there aren't really tons of people who would use it, but it'd be a fun tool to have if someone is sitting around bored for a few days

[TylerE]

FD is a good idea, rather poorly implemented. IMO what's really needed is a sort of programming language for bridge auctions, that would generate actual auctions. Syntax could be similar to the shorthand often used to describe general agreements, something like:

1m-1M-1N-2om = 5M, 10+ HCP
1m-1X(!1N)-2N = 18-19 HCP
(1w)-Dbl-(1y)-Dbl = 4+ x, 4+ z, 8+ HCP
1M[1,2]-3M = 4M, 10-11 HCP
1M[3,4]-3M = 4+M, <6 HCP
1M[3,4]-2c = 3M, 10+ HCP
1M[3,4]-2d = 4+M, 10+ HCP

Those 7 rules define basic versions of NMF, opener's jump to 2N, responsive doubles, and a basic major suit raise complex. To implement those in FD would require literally hundreds of sequences.

At one point when I was fooling around with a relay precision I actually wrote a program to bulk generate an FD card for some of our relay auctions. Even with just a few steps in the relay, the FD card was several MB in size, with thousands of auctions, despite being describle in simple english in a few paragraphs.

[Gerardo]

TylerE, on 2010-November-07, 00:26, said:

FD is a good idea, rather poorly implemented. IMO what's really needed is a sort of programming language for bridge auctions, that would generate actual auctions. Syntax could be similar to the shorthand often used to describe general agreements, something like:

1m-1M-1N-2om = 5M, 10+ HCP
1m-1X(!1N)-2N = 18-19 HCP
(1w)-Dbl-(1y)-Dbl = 4+ x, 4+ z, 8+ HCP
1M[1,2]-3M = 4M, 10-11 HCP
1M[3,4]-3M = 4+M, <6 HCP
1M[3,4]-2c = 3M, 10+ HCP
1M[3,4]-2d = 4+M, 10+ HCP

Those 7 rules define basic versions of NMF, opener's jump to 2N, responsive doubles, and a basic major suit raise complex. To implement those in FD would require literally hundreds of sequences.

At one point when I was fooling around with a relay precision I actually wrote a program to bulk generate an FD card for some of our relay auctions. Even with just a few steps in the relay, the FD card was several MB in size, with thousands of auctions, despite being describle in simple english in a few paragraphs.

What if you have more than one rule matching a giving sequence?
Add weights to discriminate?

[TylerE]

Gerardo, on 2010-November-07, 03:49, said:

What if you have more than one rule matching a giving sequence?
Add weights to discriminate?

Maybe. Perhaps best to to say the most specific rule would apply. In another words the rule that matches the smallest number of possible auctions would apply.

[0 carbon]

mtvesuvius, on 2010-November-05, 23:16, said:

An interesting topic that I would like as an operator occasionally, would be to load a pre-made FD card when Vugraphing for a pair. Having to option to do so might be a nice touch, and would make alerting some calls simpler (As well as provide a basic system outline for anyone who is curious). Not sure if it'd be practical to have, but for pairs who are on vugraph enough, with their permission, perhaps we could build FD cards.

While an FD would be ideal, because of the alerts, why not extend BBO to allow "CC"s to be any pdf or txt file? (allowing html, php, ... adds more virus possibilities)

The main international pairs all have WBF pdfs, and it shouldn't be hard for Vugraph staff to generate PDFs from any html pages.

This would also allow individuals to create their own CCs their own way. For example, I could create a pdf of my goulash card at http://TomTrottier.com/Goulash.html

BTW, would be nice if:

• Rhe list of CCs indicated which type, eg, FD, ACBL, ...
  
• The list of CCs initially only included BBO standard CCs and unpartnered CCs - with an additional button for partnered CCs. This would reduce the delay and bandwidth necessary.

tOM

[mgoetze]

Dear Fred,

fred, on 2010-November-05, 16:16, said:

I would say that FD is not the way forward.

FD seemed like a good idea at the time (and still does), but for a variety of reasons that project did not work out as we had hoped. While it is certainly possible that we will revisit this concept one day and try to improve the implementation of FD, we currently have no plans to do so. Given all the other things that we would like to get done, I strongly doubt that we will be devoting any significant resources to FD any time soon.

I think it is safe to say that we will continue to support FD in its current form as long as that is feasible. As of right now, I have no particular reason to believe that this means anything other than "forever".

I was a bit saddened to read this because I really enjoy FD. Nevertheless, it has not escaped me that the concept has not caught on with the general BBO population. I would like to make a few observations.

Several people have gone to great lengths to enter their systems into Full Disclosure. My own 2/1 Transfer Walsh FD card currently weighs in at a mere 34 kB. Gerben has written a 31 kB WJ2005 FD card. Dan Neill has expanded this to a whopping 144 kB. Richard Willey's Moscito variant takes up 105 kB. Stefanlux has come up to 220 kB with his Transfer Walsh system. And even a world star such as Jan Jansma has taken the time to put 12 kB worth of bidding sequences into FD. Obviously, a lot of time and effort goes into this.

Conversely, it is very hard for others to profit from this effort that a few are making. Let's say someone basically wants to play WJ2005, but they haven't gotten the hang of Bubrotka and prefer the good old Odwrotka convention. Well, for me this is not a real problem. I know how to open up the WJ2000 FD card, copy out the Odwrotka sequence, psate it into WJ2005 and save that as a new card. But for the vast majority of BBO users, this is already too much.

So, what needs to be done in order to spread FD is: create a user-friendly method that allows the many (I will call these people "end-users") to benefit from the efforts of the few (I will call these people "designers"). There are two parts to this: first, the designers need to be able to modularize their work in such a way that those parts of it which interest an end-user can be cleanly taken out and integrated somewhere else, and second, there needs to be an infrastructure where designers can share such modules with everyone else. I won't say very much about the second part, except that I would be willing to volunteer some of my time for maintenance duties.

About the first part, modularity, I will however say quite a bit. What I envision is basically two different editors: a high-level one where modules can be combined into a system, and a low-level one which looks rather like the current editor but which cranks out modules, rather than entire systems.

The whole tedious work of defining seats and vulnerabilities should be left to the high-level editor. If I want to play Precision when opps are vulnerable and Polish Club when they are not, I should simply be able to load up two different sets of modules, and the system would display the correct bids based on opponents' vulnerability. The modules themselves do not need to include any vulnerability information.

Similarily, I should be able to create my own modules "5-card-major openings: 2/1 GF, semiforcing NT, Gazzilli" and define these for 1st and 2nd seat, while taking the "5-card-major openings: standard passed hand bidding" modules from BBO Basic for 3rd and 4th seat. And maybe later, I could replace this with someone else's "5-card major openings: two-way reverse drury with WJS" module. And switch back when I discover on the internet that Fred G. considers two-way reverse drury a "truly awful convention". This should be indepent of my "Standard Weak 2s with Ogust" module which applies in 1st to 3rd seat (I might even have a different module which applies in 4th).

OK, so by the preceding discussion, I think it is emerging what I see as the scope of a module: something like one or two openings with their continuations, which can then be applied at various seats and vulnerabilities. But this is not quite enough. Modules also need hooks where they can refer to other modules. A simple example of this would be that I want to play the same system after 2NT, 2♣-2♦-2NT, 2♣-2♥-2NT and 2♣-2♦-2♥-2♠-2NT. A more complex example would be that modules could end up on "this is an ace-asking bid with ♥ as trumps" and then hand off to a module such as "RKCB 1430, step asks for queen, zoom to specific kings" or "Simple Blackwood, 5NT asks for number of kings".

We see, therefore, that modules need to define two things to the outside world: 1. What does the module provide, 2. what input does the module need? Our "Better minor 1m openings" module needs to know the range for a low and high NT rebid, e.g. 12-14 and 18-19. Our RKCB module needs to know at what level it has started and which suit is trumps. Our 2NT module needs to know the 2NT bidder's range. Most of this should be transparent to someone using the high-level editor in basic mode, an advanced mode could provide access to tweaking these settings.

While we're at it, I would revise two elements of Full Disclosure which were perhaps and reasonable idea but didn't really work out: "dispositions" and "possible outcomes". They should be replaced by something simpler. Noone is going to thank me for the effort I put into considering whether a bid can be better characterised as a "control bid" or a "slam try" (when it is both), and even after my Jacoby 2NT raise which sets spades as trumps and sets up a forcing pass... I might still end up in 6NT after all.

I sincerely hope that you will take another stab at this. I realise that there are many other things which you would like to improve about BBO, not to mention other major bridge competitions that you would like to win, but I do believe that FD is an idea with potential which just needs a bit more work.

Regards,
Michael

[mtvesuvius]

HUGE plus vote from me, Michael. It may seem like a fantasy (and perhaps it is), but I would love to see that happen as well, and would certainly put in a lot of time making FD cards.

[paulg]

A small minus from me for Michael's suggestion and my FD card is 372KB so I do have some experience with it. It's really a question of priorities, there are so many things that I'd prefer the software crew to do before improving (replacing) FD that I don't think they'll ever get to it.

I would also be concerned that so few people put up any type of convention card. This suggests that they are not going to take anything more complicated than the most simple system, and even then they probably will not bother. Not ideal, but a symptom of how people want to use BBO.

The idea of modules is attractive, but in practice I'm not sure that it will really work as well as envisaged. I don't think there would be much sharing and even when there was it would still need careful administering to ensure that your idea of standard concurs with the author's. In real life very few people actually share substantive bits of systems and, to be honest, outside of these forums (where some are very generous) it happens very little in my experience.

Paul

[Zelandakh]

Just to put some of these FD files comparison I have files of >1Mb. Unfortunately I hit the file size limit so have edited most of them down to the 800kb range. I think FD could become more popular if there was a larger repository database of standard system files with various convention sets. Like Michael I have found myself wanting modular structures since that has the capacity to save alot of time and space. The trouble is that I think most players just think what they play is obviously natural and their partners and opponents should understand. Add to that a comparatively older age range for bridge players, with a correspondingly low computer literacy, and it is not difficult to see why a mechanism such as FD has not caught on.

But the biggest hurdle is that the vast majority of online partnerships are pick-ups or loose arrangements. It is just not worthwhile making a big time investment for this kind of set-up. If someone does not bid your way (and is therefore an idiot) you can just go elsewhere. This is how people think, whether consciously or not. Until such time as the social dynamics of BBO changes then I doubt very much if anyything like FD will take off for the casual user.

For established partnerships it might seem like FD is a more useful tool. But the trouble here is that most of these will have system documents and having FD as well just means 2 lots of maintenance for any changes. This is certainly a big bugbear for me anyway! So the current target audience for FD is very narrow - essentially regular partners that are not serious enough to keep an offline system document but have enough spare time to create an FD file.

I love FD. For me it is one of the very best parts of the BBO software. But until a way is found to broaden its appeal it is always going to be a massively minority utility. In the end I think the only realistic solution would be to have new users answer a few question about their preferred system which then auto-generated an FD card for every user. Then when sitting at a new table you could select "use partner's card". In other words an opt-out design rather than an opt-in one to create a card but an opt-in mechanism for whether it is used in practise.

[fred]

PaulG's post is right on the mark. There are (far) too many improvements to the existing software that we want to make (to say nothing of the various other new projects we are either working on or dreaming about) for there to be any sort of realistic hope that we will do any work on FD in the foreseeable future (which to me means about 1 year). The non-foreseeable future could well mean "forever" as far as FD development work is concerned (though it could also mean 1 year and 1 day). If and when we do work on FD again, I am guessing that we would start from scratch and attempt to design it properly in advance (yes, if this likely fantasy ever became reality, I am sure that we would make "FD - the sequel" compatible with existing FD files).

Probably the best hope of Michael's vision being realized in a polynomial timeframe would be for someone not associated with BBO to do all the work. Ideally this would involve creating a slick web-based module-aware version of the FD editor. If someone were to do this, if we liked the software, if there were no legal or business issues, and if it was not a nightmare for us to get the program in question to talk to BBO (probably that would involve little more than making sure the program could spit out well-formed files in FD's format that were less than 1MB), I am sure we would at least consider making an offer to purchase such a program.

In case I wasn't entirely clear about this: I am certainly not offering a job or any guarantees to progammers out there who might be inclined to undertake such a project. Anyone who chooses to get involved will be doing so entirely at their own risk.

Fred Gitelman
Bridge Base Inc.
www.bridgebase.com

[mgoetze]

Thanks for replying, Fred. I have actually considered investing some time into that but I'm afraid "slick" and "web-based" would be extremely poor descriptions of my programming style.

[kladenak]

Hi all,

thx a lot for your comments. When I posted my question, I did not expect so much good response.
Perhaps we are all asking too much from BBO. In most pick up games the CC cannot be really used, even at a very basic level some sequences differ person to person. On the other hand, with regular partners we could perhaps do what we do in the physical game - just show the alert card. What makes it impractical in BBO is that you have to type the explanation. So I would propose the following:

1) When you are making a bid, you have the option to put a tick in an alert check box (just a tick, not the explanation like today).
2) The bid appears in yellow and if nobody asks, that's it.
3) If an opponent asks, you type the explanation in the popup window, like today.
4) And, HERE COMES THE PROPOSAL, the application remembers your explanations given on a certain bid and offers them next time someone asks about the same bid in a drop-down box. I would not bother about bid sequences, the "intelligence" would be delivered by the player, so all stored meanings for a bid would be offered, irrespective of previous bids.

I think that after a short time everybody would build a small library of explanations - there would not be too many for any single bid IMHO - perhaps 3 or 4, so picking from the list would not be difficult and also the amount of data to be stored for each account would not be big. It would be obviously good to have access to this library through "My BBO" in order to edit it - correct mistakes, standardise explanations given on similar bids and perhaps prepare the explanations in advance.

I guess this could be a fairly simple change from the programming point of view.

[1eyedjack]

I am not sure what this has to do with FD, but personally I loathe the habits of players who alert bids without simultaneously providing an explanation. I mean, seriously, how likely is it that I have no interest in the meaning of a bid that the opponent has already notified me I am likely to misconstrue in the absence of further information?

Alerting without providing a simultaneous explanation just slows down the game. It is absolutely inevitable that it will be immediately followed by one or other (or both) opponents clicking on the bid to require the explanation to be entered.

[paulg]

1eyedjack, on 2010-November-26, 08:30, said:

I am not sure what this has to do with FD, but personally I loathe the habits of players who alert bids without simultaneously providing an explanation. I mean, seriously, how likely is it that I have no interest in the meaning of a bid that the opponent has already notified me I am likely to misconstrue in the absence of further information?

Alerting without providing a simultaneous explanation just slows down the game. It is absolutely inevitable that it will be immediately followed by one or other (or both) opponents clicking on the bid to require the explanation to be entered.

Oops, I do this quite a lot!

Firstly I do it for calls that are artificial and alertable in my country, even if they are not elsewhere - good examples would be Stayman or a normal transfer response to 1NT.

Secondly where a bid has come up before in the session - playing a short club that comes up a lot and I'll explain the first time and use the unexplained alert as a reminder for subsequent occurrences.

Thirdly, even where a bid is highly artifical, I will often alert and make the bid prior to putting the explanation in. This speeds up the game when LHO is not interested and does not slow it down otherwise.

In my experience, I am not bothered about the meaning of an artificial bid a large percentage of the time.

[cloa513]

mgoetze, on 2010-November-22, 16:06, said:

Thanks for replying, Fred. I have actually considered investing some time into that but I'm afraid "slick" and "web-based" would be extremely poor descriptions of my programming style.

Maybe BBO could doing some some programmer matching- you with the background programming and someone else to make the interface.