Full disclosure

[cicus]

Fred, have you thought of creating a web-page in Bridgebase where standard cards can be downloaded ?

Yes, we will certainly create such a web page (and also make it possible to download various FD files through BBO itself).

 

I am not sure if members of the BBO staff and going to get involved in creating these files themselves. I hope that groups of volunteers will form for this purpose.

 

However, FD is still too young to start a project like that. The file format could still change and the program needs more testing until I am confident that it is stable enough to be used for a major project (like creating an SAYC file for example).

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

Hi Fred,

 

I have already typed in a great part of our pretty complex convention card so if you change the file format for FD could you please find a way so that I don't have to input all the data again? If not I'd better stop right now...

 

Best wishes,

Gábor

[stev_hav]

I have already typed in a great part of our pretty complex convention card so if you change the file format for FD could you please find a way so that I don't have to input all the data again? If not I'd better stop right now...

 

Best wishes,

Gábor

Have you completed enough of the keying to be able to estimate your final record count?

 

I have just begun working on a comparable file, based upon "BBO Standard - Basic". All that I'm attempting to do, at this time, is record sequences beginning with 1c and 1d. I have keyed what appear to be the higher-frequency uncontested auctions, including "only some" of the more-likely slam-try sequences.

 

It appears that, after suit agreement and using standard Blackwood, there are at least 55 logical sub-sequences from 4nt onward. (4 possible replies, after which asker may sign off, bid slam, or continue with 5nt . . ). And, that there are "quite a few" suit-agreement sequences, in which one partner is unlimited and may logically ask for aces. (Single raise, 2+ jump raises, 3 possible splinters, raise followed by cue bid/s, etc). In all likelihood, several thousand uncontested slam-try sequences.

 

Not to mention possible competition. Each combination of opposing actions--even assuming that opponents subside below 3nt--would generate an additional copy of "all logical uncontested" sequences.

 

It is "far from obvious", to me, that it would be truly feasible to make use of--let alone record--a file consisting of one record for each reasonably-forseeable auction. It would seem advisable to--in the relatively-near future--estimate the "maximum feasible" file size . .

[cicus]

I have already typed in a great part of our pretty complex convention card so if you change the file format for FD could you please find a way so that I don't have to input all the data again? If not I'd better stop right now...

 

Best wishes,

Gábor

Have you completed enough of the keying to be able to estimate your final record count?

 

I have just begun working on a comparable file, based upon "BBO Standard - Basic". All that I'm attempting to do, at this time, is record sequences beginning with 1c and 1d. I have keyed what appear to be the higher-frequency uncontested auctions, including "only some" of the more-likely slam-try sequences.

 

It appears that, after suit agreement and using standard Blackwood, there are at least 55 logical sub-sequences from 4nt onward. (4 possible replies, after which asker may sign off, bid slam, or continue with 5nt . . ). And, that there are "quite a few" suit-agreement sequences, in which one partner is unlimited and may logically ask for aces. (Single raise, 2+ jump raises, 3 possible splinters, raise followed by cue bid/s, etc). In all likelihood, several thousand uncontested slam-try sequences.

 

Not to mention possible competition. Each combination of opposing actions--even assuming that opponents subside below 3nt--would generate an additional copy of "all logical uncontested" sequences.

 

It is "far from obvious", to me, that it would be truly feasible to make use of--let alone record--a file consisting of one record for each reasonably-forseeable auction. It would seem advisable to--in the relatively-near future--estimate the "maximum feasible" file size . .

I am a little bit scared by what you wrote. I have keyed in about the first 4 rounds of our most important bidding sequences. The file size is 15kbyte now. I have not yet bypassed 3NT...

We use a bit complicated relay big club system. The same bid always denotes the same hand type, only the suits vary. E.g. 5422 is always shown by 3♠. I don't think I will include these 'moduls' in the file because then I will have to repeat the same key sequence 20 times. Even if I use copy and paste it is not easy because suits have to be altered in the explanation fields.

Still, it is useful to complete this CC: while I'm doing it I memorize the system.

[hrothgar]

We use a bit complicated relay big club system. The same bid always denotes the same hand type, only the suits vary. E.g. 5422 is always shown by 3♠. I don't think I will include these 'moduls' in the file because then I will have to repeat the same key sequence 20 times. Even if I use copy and paste it is not easy because suits have to be altered in the explanation fields.

Still, it is useful to complete this CC: while I'm doing it I memorize the system.

I'm running into precisely the same situation with my own Symmetric Relay methods.

 

As I noted in an earlier posting, its unclear to me whether the GUI that Fred provided is necessarily the best way to propagate system files for systems based on relay methods. Personally, I I find the option of using some kind of script to automate the process is MUCH more appealing. Long term, I expect that we'll see a variety of different mechanisms that can be used to edit these files.

 

However, none of this "work" will be possible until Fred has a chance to finalize the file format. Ideally, I hope that he'll also have time to provide some documentation.

 

In the mean time, I'm having fun playing arround with what we have available today..

[badderzboy]

I agree with Richard, its been great fun playing with the tool and when you get more convoluted sequences trying to figure out what they should mean has been a real eye-opener and a great learning curve...

 

Fred has suggested that a conversion tool would be available if the format changes as he appreciates how much work people have done in advance.

 

One thought I did have was a seperate forum for each standard .bss file developed for BBO when Fred asks for help to discuss any contentious sequences to get a common view?

 

For example

1C-1S-2D-2H vs 1C-1S-2D-3H what should the jump mean if anything or is it an impossible bid and the answer may be different for ACOL than SAYC or BBO Advanced?

 

Steve

[DrTodd13]

If a sequence comes up at the table that you haven't provided an explanation for in FD, it would be nice if BBO would bring up the FD window for that sequence and allow you to enter the information at that time and then save it. In this way, you could build up the system over time rather than doing it all at once. I too share hrothgar's concern about relay systems. It isn't easy at all.

[PMetsch]

Hi Fred,

 

I think I found a minor bug in FD. If I enter the following line in FD then wrapping in the description field of the pop-up box goes wrong:

 

FG, 4+♣, may have 5-6 ♦ or 4441♦♥

 

The part "4441♦♥" should appear on the second line, but it doesn't. Other descriptions are wrapping correct. I think it doesn't wrap, because the first character is numerical.

 

EDIT: have done some experiments: it is the suit symbol at the end of the line, that causes the problem.

[Gerben42]

Hi, I've defined my opening bids for 1st and 2nd seat but now I can't enter 3rd and 4th seat... This seems to be a bug.

 

Ah found a relevant post further up, will try that.

Edited September 16, 2005 by Gerben42

[PMetsch]

Hi Fred,

 

Another small problem:

 

If you define 1NT-2NT as a transfer, save the file, stop FD, and restart FD again, then the disposition of 2NT is changed to "signoff" and in the description field a 0 (zero) is added at the first position.

[fred]

If a sequence comes up at the table that you haven't provided an explanation for in FD, it would be nice if BBO would bring up the FD window for that sequence and allow you to enter the information at that time and then save it. In this way, you could build up the system over time rather than doing it all at once. I too share hrothgar's concern about relay systems. It isn't easy at all.

This feature is already part of the plan.

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

 

PS Happy Birthday!

[PMetsch]

Hi Fred,

 

Another small problem:

 

I have 1♣ - 1♥ - 1NT defined as a relay (disposition). If I save, stop FD and start FD, then diposition is changed to signoff and a 2 is added at the first position of the description. Probably the same problem as the transfer problem.

[fred]

Hi Fred,

 

Another small problem:

 

I have 1♣ - 1♥ - 1NT defined as a relay (disposition). If I save, stop FD and start FD, then diposition is changed to signoff and a 2 is added at the first position of the description. Probably the same problem as the transfer problem.

I cannot seem to replicate this problem. Is it possible that you have more than one version of FD on your PC and an old version is messing this up?

 

Is anyone else having trouble with the new dispositions?

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

[david_c]

The new dispositions are nice. Though there are still a few bids that don't have an obvious disposition to me - I'm wondering what disposition people are using for:

• a natural opening bid (is this "non-forcing" or "constructive"?)
  
• 2♣:2♦ waiting / negative. Similarly 1♣:1♦ in Polish.
  
• the completion of a transfer
  
• a response to Blackwood (or to any other convention with defined responses)
  
• a natural bid in an already game-forcing situtation (e.g. 1♠:2♦,2♥ playing 2/1)
  

[PMetsch]

Hi Fred,

 

Another small problem:

 

I have 1♣ - 1♥ - 1NT defined as a relay (disposition). If I save, stop FD and start FD, then diposition is changed to signoff and a 2 is added at the first position of the description. Probably the same problem as the transfer problem.

I cannot seem to replicate this problem. Is it possible that you have more than one version of FD on your PC and an old version is messing this up?

 

Is anyone else having trouble with the new dispositions?

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

I have only 1 version, bidedit (1.07) in c:\program files\full disclosure. I have always upgraded it with every new version.

 

This are my settings bidedit:

 

[sETTINGS]

CONSTRUCTIVE=Y

WE_OPEN=Y

TOOLTIPS=Y

WINDOW_LEFT=403

WINDOW_TOP=126

DEFINE_DIALOG_LEFT=425

DEFINE_DIALOG_TOP=209

[bOOKMARK]

FILE_NAME=babylon.bss

FILE_PATH=C:\Documents and Settings\Peter\Mijn documenten\games\bridge\bieden\systemen\babylon.bss

AUCTION=001CP1HP1NP

[background_COLORS]

<<<< snipped >>>>

 

It is the sequence: (vul any, dealer any)

(pass) - (pass) - (pass) - 1♣;

pass - 1♥ - pass - 1NT

 

1NT is the only defined bid after the 1♥ response.

 

EDIT: added the system

 

babylon.bss

 

<<<< snipped >>>>

001C=YYYYYYY50815+ HCP, ANY

001CP1D=YYYYYYY5080-8 HCP

001CP1H=NYYYYYY648FG, 4+!H, may have longer !C/!D

001CP1HP1N=YYYYYYY12®

<<<< snipped >>>>

[PMetsch]

Hi Fred,

 

Have done some experiments. I think the problem is the number of dispositions. The new dispositions are saved as "10", "11", "12" etc. When the file is read again after startup, FD only reads the first postion so "1" and the rest "0", "1", "2" is read as description.

[fred]

The new dispositions are nice. Though there are still a few bids that don't have an obvious disposition to me - I'm wondering what disposition people are using for:

• a natural opening bid (is this "non-forcing" or "constructive"?)
  
• 2♣:2♦ waiting / negative. Similarly 1♣:1♦ in Polish.
  
• the completion of a transfer
  
• a response to Blackwood (or to any other convention with defined responses)
  
• a natural bid in an already game-forcing situtation (e.g. 1♠:2♦,2♥ playing 2/1)
  

I am thinking of adding dispositions of "asking bid" and "response to asking bid" for handling things like Blackwood and responses to Blackwood.

 

I personally think that "non-forcing" is the best way to describe something like a 1H opening bid, but I suppose "constructive" is also OK (though I did not have this purpose in mind when I created this disposition).

 

I actually have no idea what relay/puppet/transfer are supposed to mean (or if any of these are actually well-defined anywhere).

 

As has been suggested in other posts, the people who get involved in creating system files that will be used widely on BBO should make decisions involving standards for describing various types of bids. I will be happy to offer my opinions about such things, but this is not exactly my area of expertise.

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

[david_c]

Hi Fred,

 

Have done some experiments. I think the problem is the number of dispositions. The new dispositions are saved as "10", "11", "12" etc. When the file is read again after startup, FD only reads the first postion so "1" and the rest "0", "1", "2" is read as description.

Aha! Yes, I can get it to do this too now, but it only happens for NT bids. For suits it saves correctly, with "A" in place of "10" and so on.

[fred]

Thanks! I will fix this and make a new version.

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

[david_c]

Obvious bug in 1.0.8 - the final three dispositions should be

 

"Relay"

"Asking bid"

"Asking bid response"

 

but instead they are

 

"RelayAsking bidAsking bid response"

""

""

 

Edited: and the no-trump dispositions are all messed up now. :D

 

Edited again: Don't use this version on an important file until Fred fixes it, as it will make all your no-trump dispositions wrong.

[cherdano]

I actually have no idea what relay/puppet/transfer are supposed to mean (or if any of these are actually well-defined anywhere).

Me neither, but instead of trying to ask people, I may try to give definitions so people can tell me what is wrong with them :D

• * Relay: The cheapest possible bid as an asking bid, not promising anything except ability to handle all (automatic) responses (and in the context of an auction where several such cheapest-bid-is-asking-bid can follow each other). I.e., as for disposition, it is just an asking bid.
  * Puppet: Asking partner to bid the next step (exceptions allowed) without implying length in this suit/strain (2

♣ in XYZ)
* Transfer: Asking partner to bid the next step (exceptions allowed), showing a hand that wants to play in this strain

[fred]

It's amazing what can happen when delete a comma by mistake :D

 

1.0.9 is now available in the usual place.

 

Thanks for quickly noticing and reporting this problem, David.

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

[stev_hav]

If a sequence comes up at the table that you haven't provided an explanation for in FD, it would be nice if BBO would bring up the FD window for that sequence and allow you to enter the information at that time and then save it.  In this way, you could build up the system over time rather than doing it all at once.  I too share hrothgar's concern about relay systems.  It isn't easy at all.

This feature is already part of the plan.

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

 

PS Happy Birthday!

Where do you intend that system files reside, during online play?

 

It would seem "ideal" to house these on the server:

A. To ensure that both members of each partnership are using the same file.

B. To keep files available to those who use a desktop at home, and a laptop while traveling; avoiding any need to keep files synchronized.

C. Possibly, at some future time, to serve as clear-cut evidence of a pair's actual partnership understandings. To assist in resolution of certain controversies, in higher-level at-the-table competition. (Assuming that at least appeals committees, and most likely directors, would have at-the-site internet access.)

 

There would, however, be complications:

A. Need to support upload/download and/or on-line updates; most likely both.

B. Need to account for members' system files; both as to backup and space occupancy.

 

Altho it appears that "on the server" would be long-term preferable, "on the client" appears to be both a feasible alternative and simpler to implement.

[inquiry]

I am going to guess that the same thing that happens now with convention cards will happen with FD files. Both partners may have versions, and these versions maybe different, but when one of them loads the FILE, that is what is loaded.

 

In theory, partners should not be using these as memory aids. That is, you should not be checking your won FD file while playing on line. In practice, Fred has consided that this can not be regulated. But I would guess that if the two partners have different versions, that is tough for them if thye are checking the file and their opponents might be due a correction if they have agreements different from what FD displays.

 

I pretty sure Fred will not want to keep the dozens of FD files I am creating on his server multiplied by thousands of members times the size of the files....

 

Currently, each partnership would need to upload one FD file to play (not both partners), and they play that..so at every table there is a maximum of two such uploads. Say there is 2000 tables between main room, private clubs, tourneys, team games, public clubs (I don't think it runs anywhere this high), that is only 4 thousand files if everyone uploads. That probably seems handable... have the partner with the fastest internet connection upload your FD files if they are huge.... (yes, I can imagine some well more than 1MB).

[fred]

Part of the plan is to create files for common systems like SAYC, 2/1, WJ2005...

 

Everyone will have the latest versions of these files on their hard disks and the server will be smart enough to send them updates when necessary.

 

So people will just be able to say "I want to use the SAYC card" and there will be no reason to send any giant files around (since all users will already have the same version of SAYC).

 

Presumably if someone creates their own FD files or modifies one of the templates, they will have to have a way to upload their card to the server (ie the equivilant of the "use" button in the convention card window). The server will then be responsible for sending copies of this file to other people at the table.

 

Most likely we will implement some kind of caching mechanism on the server, the client, or both. Uday and I are trying to figure all of this out.

 

We are also trying to figure out how to create a user interface to make all of this easy.

 

Good news is that I think we will figure it out and that it is going to be good.

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

[hrothgar]

I actually have no idea what relay/puppet/transfer are supposed to mean (or if any of these are actually well-defined anywhere).

Here are the working definitions that I use:

 

A puppet forces partner to make a specific rebid. A lebensohl type 2NT that forces partner to rebid 3♣ is a classic example of a puppet. Some players use a 3♠ response to a 2NT opening as a puppet to 3NT. In theory, there could be bids that puppet to some other than the first step, however, I can't think of any obvious examples.

 

A transfer is an artifical bid that shows length in another suit. Typically, the known anchor suit is one step higher than transfer suit, however, there are many examples of 2 under transfers. A transfer typically shows willingness to play in the known anchor suit.

 

An asking bid is an artificial bid that instructs responder to describe his hand. Stayman are both well known examples of asking bids.

 

A relay is specific type of asking bid. Relays differ from asking bids in that relays are recursive. Assume that you have made an asking bid and partner has responded. If you have the option to make a second asking bid after partner's response to the first asking bid than the first asking bid is a relay.

 

Please note that the definition of a "relay" is highly idiosyncratic. In theory, there should be some distinction between a relay and an asking bid. Recursion seems to be a valid distinction. However, I doubt that there are many people who would agree with me.