Full disclosure

[fred]

A question:

how to deal with different sequences for responder, based on whether he is a passed hand ?

 

E.g. what is the combination of menu-options/checkboxes to select, e.g. when 1M:1NT is forcing or not (in 2/1), OR when 1M:2C isa Drury or not ?

Use the "dealer" pulldown menu to specify the seat the dealer is in.

 

If you want to define Drury, for example, set the dealer to "3 or 4" and make sure both "constructive" and "we open" are set. The click 1H, then 2C, then enter your definition for Drury. Go up and do the same thing for 1S (or use cut and paste).

 

The above instructions assume you are using version 1.0.2 (or later) of FD.

 

Let me know if this is not clear.

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

[keylime]

Fred,

 

This program has lifted my spirits after a very turbulent month in my life. Big smiles here from Maryland.

 

I hope that there will be a print function included soon - the logic trees wouldn't be too hard to transcribe.

 

Lastly, it's a great first effort. Well done.

[pigpenz]

Fred:

is it possible to have it where you can put in multiple bids say for a realy like a walsh relay

 

1nt 2♦

2♥ 2♠

2NT now the following responses for the 2♦ bidder

 

3♣

3♦

3♥

3♠

3NT

 

where all the above could then be explained with having to go back and redoing everything from the start. I think that would be more useful for partner and opponents.

[Flame]

not sure i undersood the question , but if i did then you can press "up" from outside the bidding explanation, or even better press "ok&up" from inside it.

[shoeless]

Remarkable innovation!!! Call it Ashtray - Birdbath - Bidding Matrix - Bidding Tree or Box of Chocolates and in the end people won't care much as the value is not in the name but in the content. When I first saw the initials BBO I thought of Bobo the Clown. 'Full disclosure' works for me, but inherent in that name, are the rantings that will arise when someone fails to completely flesh out their system Director!!! They say full disclosure but look at this 3D bid!!!! We were damaged!!!! How about AAAFD - An Attempt At Full Disclosure for the semantics freaks?

 

I do have one strong recommendation. Get someone working on a user' manual or the FD 'help' file right away - or even a team from these forums. Those that understand their systems well and understand software interfaces will have great joy in playing with this tool. Those of us however who are mentally challenged in one or both of these areas need help. I would go so far as to say that down the road, there should be a regular training session in the lecture theatre on the use of this tool. (mind you, I also think that a twice weekly seminar on the features and tricks of BBO would be valuable). I think there is a vocabulary that high level bridge players and software buffs understand in this program that is somewhat unique and not easily understood by us lesser mortals - 'heh? what is it asking me to do?'

 

I suppose with all great innovations - it is the highest level that gets it and enjoys it first and proves it and creates a standard of usage and creates an attraction to it for the masses.

 

Hats off to you BBO.

[badderzboy]

I quite like the name 'Bidding-Tree' sums it all up in two words.

 

Would it be possible to make the window a tad bigger both length and width ( about 10% more?) so we can see the full description?

 

Will there be a section for carding and leads etc?

 

When we can use this in BBO in partnership bidding / play etc it will possibly be one of the best teaching tools available (alongside LTPB/LTPB2 ;) )!

 

Steve.

[Dwingo]

I will appreciate if one of the moderators of this Forum move this topic to another thread started by david_c on the same topic. It will be easier for people interested in Full Disclosure to be focussed on one thread.

 

Godwin

[hrothgar]

posting moved to original thread

[hrothgar]

Hi All

 

Here are a few toughts about the application currently known as "Full Disclosure"

 

"Full Disclosure" can be decomposed into three distinct elements.

 

1. Fred has defined a file format that maps a bidding sequence onto a text string. System templates are stored on the local hard drive with a .bss extension.

 

2. Fred is modifying Bridge Base Online to use these files to for different functions. Auto-alerts and "cheat sheets" are the two most obvious examples

 

3. Fred has an application called "Bid-Edit". Bid-Edit is a Graphical User Interface (GUI) that provides a fairly intuitive mechanism to create properly formated .sxc files.

 

I think that its useful to recognize the different components to this system. Case in point: Bid-Edit is one of a number of different tools that could be used to create .sxc files. If people preferred, they could use a standard text editor accomplish the same end. Personally, i prefer to play relay methods. One advantage of playing relay that relatively large numbers of bidding sequences are assigned predictable meanings based on some kind of pattern. Accordingly, I suspect that it will be much easier to generate .bss files for MOSCITO using some kind of script to automatically populate the system file.

 

The reason that I bring this up is the following: When people are suggesting enhancements to "Bid Edit", they might want to consider whether they can accomplish the same task easier using a different front end...

[hrothgar]

Under the category "Disposition", it might be useful to add a couple additional categories

 

1. "Puppet"

2. Either "Relay" or "Asking Bid"

[david_c]

I don't find the "possible outcomes" section very useful. I've found that there are very few bids which actually reduce the set of possible outcomes (apart from sign-offs) and those that do are only by inference anyway. So I'd vote for this to be removed, as it's rather cluttering up the output.

 

Edit: ... and, as it stands, I don't think that someone looking at the output would understand what "♣ ♦ ♥ ♠ NT Def" means.

Edited September 5, 2005 by david_c

[Chamaco]

I don't find the "possible outcomes" section very useful. I've found that there are very few bids which actually reduce the set of possible outcomes (apart from sign-offs) and those that do are only by inference anyway. So I'd vote for this to be removed, as it's rather cluttering up the output.

A checkbox/pulldown menuitem specifying:

 

"Sets forcing pass at:

- any level

- XXX level and higher"

 

might be more compact ?

[hrothgar]

"Sets forcing pass at:

- any level

- XXX level and higher"

 

might be more compact ?

I define forcing passes more by sequence than by level...

 

I'll repeat an earlier comment:

 

I would would prefer to "Bid-Edit" to be optimized for ease of use.

I strongly suspect "serious" design work will require some kind of scripting system to automatically populate the bididng tree.

[cherdano]

I'm just an incy-wincy bit concerned about the disclaimer around the file format - does this mean that any input we make now will *almost certainly* need rekeying when the platform gets stabilised?

I think "almost certainly" is an overbid. "Not unlikely" is how I would characterize it.

 

Most likely the file format will not change in any dramatic way. Most likely, if it does change, those of you with good computer skills will be able to edit your existing files manually (using Notepad for example) in order to get them to work.

First of all, great program!

 

I think it would be great if you could choose a file format that is not only practical for your programs, but also easy for others to use. There would be a good chance that other people would start writing small programs to use or create FD files. E.g. hrothgar would write a script to automatically generate them for relay systems. Others might write a little helper program to fill out a WBF CC with the information from the bidding file. I might write a little program to generate a LaTeX file with a system description, for convenient printing. Etc. In other words, I think a lot of useful stuff can be done with this that you won't want to do yourself, and the world of bridge players has enough programmers that somebody will do that.

 

At the same time the file format might need extensions later. Maybe at some point people will want to add information whether a bid is alertable in ACBL/WBF/EBU. Etc etc. (I am sure by now someone will start suggesting XML...)

 

I think the potential of all this is great.

 

Btw, I actually like the name.

 

Arend

[cherdano]

I don't find the "possible outcomes" section very useful. I've found that there are very few bids which actually reduce the set of possible outcomes (apart from sign-offs) and those that do are only by inference anyway. So I'd vote for this to be removed, as it's rather cluttering up the output.

I actually found it confusing, and first didn't know at all what it should mean.

 

Arend

[david_c]

Another little request: it would be nice if we could use suit symbols in the description, perhaps by typing !C, !D etc. like in BBO.

[Rain]

One problem when merging posts into another thread is posts are listed in strict chronological order---may be hard to understand what's going on. Anyway, merged.

[pigpenz]

actually full disclosure is nice, but if there were secondary/tertiary etc trees available on the convention card button on the botton of the bbo toolbar it would probably be easier to do all that we are trying to do with full disclosure.

[fred]

Another little request: it would be nice if we could use suit symbols in the description, perhaps by typing !C, !D etc. like in BBO.

This will certainly happen eventually.

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

[fred]

I don't find the "possible outcomes" section very useful. I've found that there are very few bids which actually reduce the set of possible outcomes (apart from sign-offs) and those that do are only by inference anyway. So I'd vote for this to be removed, as it's rather cluttering up the output.

A checkbox/pulldown menuitem specifying:

 

"Sets forcing pass at:

- any level

- XXX level and higher"

 

might be more compact ?

I personally think the notion of suit agreement is important, both in terms of defining a system and in terms of information that the opponents rate to care about.

 

However, if I receive enough negative comments about this feature, I could probably be persuaded to get rid of it (or at least make display of the information an option).

 

Fred Gtielman

Bridge Base Inc.

www.bridgebase.com

[fred]

actually full disclosure is nice, but if there were secondary/tertiary etc trees available on the convention card button on the botton of the bbo toolbar it would probably be easier to do all that we are trying to do with full disclosure.

Most likely what you see when you click the CONV button in BBO will be completely different once FD is integrated into the BBO client.

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

[Finch]

I'll repeat an earlier comment:

 

I would would prefer to "Bid-Edit" to be optimized for ease of use.

I strongly suspect "serious" design work will require some kind of scripting system to automatically populate the bididng tree.

I strongly agree with this.

I think the concept of having a well-defined text file to define the meaning of bidding sequences would be a great addition to online bridge as well as being a good tool if/when it is integrated into a hand generation program.

 

 

p.s. I note a lot of similarities to a commercially available peice of software called HCS System Notebook.

 

Edit: I realise you might take that as accusing you of plagiarism. I didn't mean that at all... I meant that I'm going to remember why I never really used that piece of software!

[Finch]

Having got the compliments out of the way, I'll tell you the biggest problem I have with using a tool such as this to define my systemic agreements.

 

I have two regular partnerships, and in both of them I play a natural(ish) based system with some gadgets. The best-documented system has a 60-odd page word file. Of those 60 pages, about 5 are on opening leads and defensive carding. Of the rest, only about half is content that can be transcribed directly into bidding trees such as FD offers.

 

About a third of the rest is stuff that could be turned into bidding trees with a script and some intelligence such as Richard describes. Take the simple sentence "Responses to 1S of 2NT and above as to 1H but a level higher, except where obvious". It's the "where obvious" bit that's pretty clear to a human, but hard to script (such as there's a sequence after 1H-2S (artificial) that eventually shows 5-6 in the majors; having opened 1S you can't be 5-6 in the majors but you can be 5-5, while if you open 1H you can't be 5-5 in the majors).

 

Another third is general stuff on approach (what we consider to be an opening bid or a pre-empt or an overcall, what is our general style on upgrades & downgrades, and so forth). This is important to disclose to the opponents but doesn't fit anywhere nicely into a set of definitions of opening bids etc without a vast amount of repitition.

 

The last third consists of "meta-rules" about bids. For example, there is a couple of pages on the use of 4NT in non-competitive auctions. One part of this says "If it is possible to agree a major explicitly via a forcing raise or a cue bid, and this is not done, then 4NT is natural." This is quite a simple rule, but it doesn't map onto a "bidding tree" in any type of easy way, because the rule can apply in a huge number of possible auctions.

 

We even have chains of rules. There is a set of rules for when 2NT in competition in natural. After that, there is another rule for determining what an artificial 2NT means (and this in a partnership that doesn't play what is traditionally known as good/bad 2NT at all...).

 

As a minor (but to my mind interesting) point: we've been playing together seriously for about 15 years. We rarely add or change the meaning of bits of "system" (about once a year, or so, things get mildly improved or tightened up). But most of the pages that have been added are trying to document stylistic things that have come up, or strange auctions that we agreed afterwards didn't mean what the system file implied they ought to mean.

 

I'm not trying to pick holes for the sake of it - I'm explaining why I will never put my systemic agreements into this type of tool for my use, only if it's required by the event I'm playing in.

[hrothgar]

I'm not trying to pick holes for the sake of it - I'm explaining why I will never put my systemic agreements into this type of tool for my use, only if it's required by the event I'm playing in.

There's an old saying: "Don't make the best the enemy of the good..."

I sincerely doubt that I'll ever code a complete bidding system using full disclosure. This doesn't mean that it isn't worth entering descriptions for the most common sequences.

 

In an earlier post, I noted that players should distinquish between system templates (the actual .sxc files) and the editors used to create them. Once very interesting possibility would be leveraging the BBO client as an editor to create .bss files... Imagine if you had the ability to "tell" BBO that you wanted to start building a new .bss file. From this point forward, all alerts and announcements would automatically be saved as a system file. In theory, this system should converage pretty quickly on an optimal system definition. Mopre formally, the expected order in which data would be entered into the .bss file would be a function of the frequency of the bid.

 

Needless to say, you'd still want the ability to go in an edit the file in order to clean up typos and the like. However, I think that the idea has a lot going for it...

[MarceldB]

How do I get rid of the "open squares" in the description box, caused by ctrl-enter.

In other words is there an other method to go to the next line if the line itself is not completed.

 

I prefer this in case of f.e. multi-bids to keep a clear/better view of the different meanings.

 

Marcel