[fred]

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

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]

fred, on Sep 16 2005, 01:13 PM, said:

DrTodd13, on Sep 15 2005, 05:51 PM, said:

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]

fred, on Sep 16 2005, 06:45 PM, said:

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.

[inquiry]

Since Pass/Correct is not available (no need to add it), I describe suich bids (after undefined michaels, after multi 2♦ after my misIry thingee) as "puppet" as the choice and Pass/Correct via text... in the text field.

[hrothgar]

inquiry, on Sep 16 2005, 10:01 PM, said:

Since Pass/Correct is not available (no need to add it), I describe suich bids (after undefined michaels, after multi 2♦ after my misIry thingee) as "puppet" as the choice and Pass/Correct via text... in the text field.

Not sure if I understand

Partner has just opened a multi 2♦ and you have bid 2♥ (or potentially 2♠) as a pass or correct bid.

The expression "Puppet" really doesn't seem appropriate.

The 2♦ opening is not a puppet to 2♥. Partner has the option to make a variety of descriptive rebids.

The pass or correct 2♥ response also isn't a puppet to 2♠ since this can be passed.

Personally, I would describe the 2♦ opening as "Preemptive" and the 2♥ response as "non-forcing"

[stev_hav]

hrothgar, on Sep 16 2005, 07:08 PM, said:

Not sure if I understand

Partner has just opened a multi 2♦ and you have bid 2♥ (or potentially 2♠) as a pass or correct bid.

The expression "Puppet" really doesn't seem appropriate.

The 2♦ opening is not a puppet to 2♥. Partner has the option to make a variety of descriptive rebids.

The pass or correct 2♥ response also isn't a puppet to 2♠ since this can be passed.

Personally, I would describe the 2♦ opening as "Preemptive" and the 2♥ response as "non-forcing"

At least IMO, describing a "multi" 2d as preemptive, and 2h response as "non-forcing", would be highly misleading.
Ordinary "preempts"--promising length only in named suit--need not even be alerted.
2d, on the other hand, pretty well DENIES d length; is either a major-suit wk2 or strong/balanced; needs to be so described.
Description of 2h really needs to explicitly say pass or correct . .

[inquiry]

hrothgar, on Sep 16 2005, 03:08 PM, said:

inquiry, on Sep 16 2005, 10:01 PM, said:

Since Pass/Correct is not available (no need to add it), I describe suich bids (after undefined michaels, after multi 2♦ after my misIry thingee) as "puppet" as the choice and Pass/Correct via text... in the text field.

Not sure if I understand

Partner has just opened a multi 2♦ and you have bid 2♥ (or potentially 2♠) as a pass or correct bid.

The expression "Puppet" really doesn't seem appropriate.

The 2♦ opening is not a puppet to 2♥. Partner has the option to make a variety of descriptive rebids.

The pass or correct 2♥ response also isn't a puppet to 2♠ since this can be passed.

Personally, I would describe the 2♦ opening as "Preemptive" and the 2♥ response as "non-forcing"

Not sure "Non-forcing" is even close to the right desciption. Let's take your simple example... 2♦ - 2♥

You FULLY expect your partner to do one of the following:

Pass with ♥s and weak
Bid 2♠ with ♠ weak
Bid 2NT with BAL strong, and then whatever your other bids mean.

In otherwords, you 2♥ bid, "forces partner to make a specific rebid", of course depending upon which hand he holds. Note this is very close to your definiton of a puppet. where you said... "A puppet forces partner to make a specific rebid."

The only difference is what is forced upon partner isn't a forced 3♣ rebid, but rather a forced bid BASED upon which of several hand he can hold.

[barmar]

Some bridge authors have also started to use another term, "marionette". www.bridgeworld.com has a glossary that defines all these terms. I've copied some of the relevant definitions below (most of what I've omitted are simply the ones that say that the word can also be used as a verb). Note that the bids many players call a puppet would actually be a marionette (e.g. after Lebensohl 2NT, partner can refuse the transfer when he has extra values), and there are probably few true puppet bids.

When you get around to writing the documentation for FD, it would probably be a good idea to have it include the definitions of the disposition terms. Or maybe they could be done as pop-up tooltips right there in the program.

Transfer

(1) (noun) a bid that shows length in a different suit;

(2) (noun) a call that asks partner to make a certain call regardless of his holding; [In this usage, also called Puppet.]

Puppet

(1) (noun) transfer (meaning 2) [= a call that asks partner to make a certain call regardless of his holding];

Marionette

(1) (noun) a transfer (meaning 2), after which partner will usually make the cheapest bid but is permitted to bid higher with special hands. (Compare with puppet.)

Relay

an artificial, nondescriptive bid that asks partner for a description.

Asking bid

a bid that requests information about a specific feature of partner's hand (e.g., number of aces, controls in spades, quality of heart support).

[hrothgar]

inquiry, on Sep 16 2005, 10:29 PM, said:

hrothgar, on Sep 16 2005, 03:08 PM, said:

inquiry, on Sep 16 2005, 10:01 PM, said:

Since Pass/Correct is not available (no need to add it), I describe suich bids (after undefined michaels, after multi 2♦ after my misIry thingee) as "puppet" as the choice and Pass/Correct via text... in the text field.

Not sure if I understand

Partner has just opened a multi 2♦ and you have bid 2♥ (or potentially 2♠) as a pass or correct bid.

The expression "Puppet" really doesn't seem appropriate.

The 2♦ opening is not a puppet to 2♥. Partner has the option to make a variety of descriptive rebids.

The pass or correct 2♥ response also isn't a puppet to 2♠ since this can be passed.

Personally, I would describe the 2♦ opening as "Preemptive" and the 2♥ response as "non-forcing"

Not sure "Non-forcing" is even close to the right desciption. Let's take your simple example... 2♦ - 2♥

You FULLY expect your partner to do one of the following:

Pass with ♥s and weak
Bid 2♠ with ♠ weak
Bid 2NT with BAL strong, and then whatever your other bids mean.

In otherwords, you 2♥ bid, "forces partner to make a specific rebid", of course depending upon which hand he holds. Note this is very close to your definiton of a puppet. where you said... "A puppet forces partner to make a specific rebid."

The only difference is what is forced upon partner isn't a forced 3♣ rebid, but rather a forced bid BASED upon which of several hand he can hold.

A puppet is unilateral. it only has one outcome
A puppet forces partner to bid suit X regardless of what hand type he holds

A pass or correct bid has two possible outcomes...
It can not be a puppet

[inquiry]

hrothgar, on Sep 16 2005, 03:50 PM, said:

A puppet is unilateral. it only has one outcome
A puppet forces partner to bid suit X regardless of what hand type he holds

A pass or correct bid has two possible outcomes...
It can not be a puppet

I think you will have a lot of disagreement here....

For instance, most people who play puppet stayman will mark their bid as puppet

And in fact it is, partner will bid 3♦ unless he has five card major...

Same thing with pass/correct bids.. partner will PASS unless he doesn't... and when he doesn't it is like puppet stayman above, it is when he holds a specific hand.

[cherdano]

hrothgar, on Sep 16 2005, 08:54 PM, said:

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.

I agree (although I wouldn't use the word recusion here). As far as FD is concerned, I think "asking bid" makes "relay" unnecessary as a category.

[awm]

I'd distinguish relay vs. asking bid in that an asking bid has some specific "question" associated with it. For example, 2♣ stayman asks "do you have a four-card major" and the responses answer that question. In contrast, a relay just says "tell me more about your hand" and the responses show a wide range of different things. To give an example, consider the auction:

1♣ (precision) - 1♥ (natural GF)

In Wei-precision methods, 1♠ is an asking bid about spades. Responder bids in steps showing various levels of spade support. Responder does not generally give any other information about his hand at this point.

In symmetric precision, 1♠ is a relay. Responder will now tell something more about his distribution. In a few cases responder's next bid will also say something about high card strength (zooms). There's not really a specific question being answered here.

[hrothgar]

inquiry, on Sep 16 2005, 10:54 PM, said:

I think you will have a lot of disagreement here....

For instance, most people who play puppet stayman will mark their bid as puppet

And they would be wrong to do so...

I'm not making this ***** up. This is standard vocabulary with well defined meanings. As barmar noted, the definitions that the Bridge World uses are virtually identical to the ones that I suggested..

I see no reason why we would want to start confusing issues by adopting our own idiosyncratic nomenclature.

[inquiry]

Well, I would disagree with the use of "relay" on an auction like..

2NT - 3♣ (where 2NT is MisIry)

3♣ would fit the definition of relay, as it in reality says "tell me more about your hand" and the responses show a wide range of different things... one of the "things" opener can tell is he has weak hand with ♣ by passing.

Perhaps non-forcing (What I had at first) is more appropriate.. .but it does have puppet or relay (dependign upon you definition) attached to it. PArtner will bid conventionally to this bid based upon his hand...just pass is one of the bids. Anyway with the PASS/CORRECT text field, I suspect this is only an issue for those of us who like something to haggle over.

[david_c]

inquiry, on Sep 16 2005, 09:05 PM, said:

Well, I would disagree with the use of "relay" on an auction like..

2NT - 3♣ (where 2NT is MisIry)

I'd call it a "non-forcing relay". But we don't have that as an option; being forced to choose, I prefer "non-forcing" to "relay". I certainly agree with Richard that this sort of thing is definitely not a puppet.

[david_c]

hrothgar, on Sep 16 2005, 09:01 PM, said:

I see no reason why we would want to start confusing issues by adopting our own idiosyncratic nomenclature.

But nor is it possible to force everyone to use one particular definition, when there is disagreement about what the words mean. For example, I think the second Bridge World definition of "transfer" is seriously misguided (it's a puppet, not a transfer), but I'm not going to be able to stop people using it.

[Chamaco]

A question about Full Disclosure.
I think the part on uncontested bidding is great.

My question is, now, rather oriented to contested bidding.
I apologize if the issue has already been raised in the past (I did not browse through all the posts).


E.g. Let's assume I am filling the scheme of our overcalls on opps 1 club opening and I go to play a BBO tourney with the FD CC uploaded.
This scheme was written assuming a "better minor scheme" in a SAYC or 2/1 context.

But then I meet one pair who is playing Precision and opens 1 club: the software will visualize the meaning and explanation of our bids over 1 club ASSUMING 1C is a SAYC opener, not a Precision opener.
Instead, over a big club we do have different agreements.
So opps will visualize the incorrect information.

The same thing happens when we open and opps overcall artificially: our followups are different than if the overcall has another meaning.
Is there a way to solve this ?