Vulnerability Choices - more needed?

[John in the Sun]

I open 1NT and LHO bids 2S.

 

Let's assume that we want to punish the opponents with a penalty double only when the reward is the greatest: when they alone are vulnerable. The rest of the time we'll play negative doubles.

 

These are the FD vulnerability choices:

0 = Any

1 = None

2 = Only We Vul

3 = Only They Vul

4 = Both Vul

5 = We Not Vul

6 = We Vul

7 = They Not Vul

8 = They Vul

 

The first part is easy; I define a 1N opener where only they are vulnerable:

 

3 = Only They Vul

 

and define partner's double as penalty.

 

The second part is not so easy - what I want is the converse of the first part - "NOT Only They Vul". With the current choices I believe I have to duplicate the 1N structure for 3 conditions:

 

1 = None

2 = Only We Vul

4 = Both Vul

 

and define partner's double as negative for each of the three 1NT openers.

 

Is there a better way? Should there be more choices?

[Elianna]

The second part is not so easy - what I want is the converse of the first part - "NOT Only They Vul". With the current choices I believe I have to duplicate the 1N structure for 3 conditions:

 

1 = None

2 = Only We Vul

4 = Both Vul

 

and define partner's double as negative for each of the three 1NT openers.

 

Is there a better way? Should there be more choices?

How about 1 and 6? So that covers no one vul, and then both ways that you are vul.

[kenrexford]

Is there a better way? Should there be more choices?

Heck -- let's go crazy with this.

 

The circumstances change as the seat for Opener changes.

 

In 1st seat, the other three hands are unknowns and unlimited.

 

In 2nd seat, Opener's RHO, to be dummy in a doubled contract, will be limited to less than opening strength.

 

In 3rd seat, the same is the case as to Opener's RHO and the eventual dummy, but the person doubling will have lesser potential defensive values. Furthermore, some people tweak the range for a 1NT opening at this point.

 

In 4th seat, both RHO and LHO (Declarer and Dummy) will have limited hands. Furthermore, RHO/Dummy will be severely limited if the opening style in third seat is "light."

 

Hence, you could take all 8 instances and yield 32 instances legitimately.

 

Add in nuances to be derived from oppositition system (aggressive weak two's or sound weak two's or no weak two's, for instance), and you could easily get to 96 or more specific instances.

 

Oh, but there's more. How about form of scoring? This may affect your cost-benefit analysis, as well as that of the opponents. So, assuming 96 instances, and the BAM/MP/IMP, you would have at least 288 instances to consider.

 

This is not to mention things like table feel, known predispositions of the opponents, and state-of-the-match concerns.

[ahollan1]

Handling the double-barrel situation of Treatment 1 for NV vs V [Green/Favorable] and Treatment 2 for everything EXCEPT NV vs V is a recurring theme for opening bids.

 

FD can handle that in 2 ways using 3 entries rather than the 4 shown

 

Only They Vul

We Vul

Neither Vul

 

or

 

Only They Vul

They Not Vul

Both Vul

 

In my opinion, the fundamental flaw having to duplicate information in at least 2 vulnerability permutations. Programmers hate these "multiple maintenance" situations. i.e. if the agreement changes, FD must be updated in multiple places even though only one agreement was modified.

 

The problem description and following discussion apply to a number of things in FD, including but not limited to:

 

a) Vulnerability

Common Use Case

Agreement 1 for NV vs V

Agreement 2 for everything else

B) Seat

Common Use Case

Agreement 1 for 1st/2nd/4th seat

Agreement 2 for 3rd seat

c) Form of Scoring

d) PH vs UPH

e) Immediate vs Balancing/Reopening

 

[and yes, I believe there should be an implementation to identify style of sound, aggressive, random, etc - but that is another discussion]

 

There are a number of ways to imagine overcoming these multiple-maintenance problems.

 

1) Add more things to the selection list

a) just available as manual entry to text file

B) always available to GUI

c) GUI offers current choices or a configurable option to see Extended Options

 

If software implementation is restricted to single byte entry, then range can be extended to Integer 0-9 or Hex 0-9,a-f or Alpha Numeric 0-9,a-f

 

2) Matrix for selection of all applicable conditions

 

3) Define Default Agreement then 2nd definition to override default

An example for the case that began this discussion

Default: 2H opener = Weak 1-suiter

NV vs V: 2H opener = Weak, 2-suiter, H+minor

 

a more common case = 5 card Majors but 3rd seat may be 4

 

Note: There are other multiple maintenance situations that are NOT covered by this discussion but are on my list of things to eventually write-up:

 

examples:

O1) Convention applies at multiple entry points

ex: Kokish 2C[str, art]-2D;2H 1C[str, art]-1D;2H Kokish

 

Smolen 1N-2C;2D-? 2N-3C;3D-? 1C[str, art]-1D;1N-2C;2D-?

 

Puppet Stay, etc

 

O2) Asking Bid responses by steps

ex: Ace Asking multiple ways to ask, but steps always RKCB steps:

Step 1 = 1 or 4

Step 2 = 0 or 3

Step 3 = 2 without Q

Step 4 = 2 with Q

 

current FD implementation says this has to be entered and adjusted for each spot where partnership can ask. For many that can be the entire 4-level [RKCB + Kickback, etc]. The same happens at the 5-level for Exclusion

 

 

 

My point is that the thread defines a frequent use case where FD implementation could be improved, which may actually lead to [dare to dream] more use of FD