Cataloging GIB flaws

[1eyedjack]

One of the things that I find quite frustrating about GIB upgrades is an apparent disconnect between bug reports and progress. Ideally it would be good, at any instant, to be able to see a snapshot of issues that need to be addressed, ranked by some semblance of priority, and properly classified so that when repeated instances present it is a simple process to point to a record of it already having been raised, with some record of age and frequency. Some problems get reported repeatedly year on year with minimal acknowledgement by the programmers, and several upgrades later the same problems are there.

 

The point was driven home to me when, out of the blue, one of the GIB upgrades announced the introduction of Drury, the prior absence of which raised barely a whisper in the forums. I appreciate that the discussion forum is not the only source by which grievances get reported, but I would expect some correlation. And I am not sure that GIB uses Drury in a classically standard way, but instead responds 2C on virtually any hand with a game try and support for opener.

 

There are some encouraging signs. We are informed that with version 33 GIB performs more intelligently after an inverted minor raise or splinter. Early days to confirm that these issues are solved but let's hope so.

 

But that still leaves outstanding a formal method of categorising GIB failings and prioritising them. In this regard there are (at least) two major problems to overcome:

1) The forum software does not lend itself easily to this task.

2) BBO's priorities may be ranked differently from those of the user-base.

 

1) Forum Software:

 

I feel sure that there will be a better solution but one might be to have a separate pinned thread for each regular issue. The priority ranking could be indicated by where it is pinned. The thread can be unpinned when the issue has been addressed (including note of version number, for posterity). Individual hands that exemplify the problem can be contained in their own threads so that comments relevant to the particular hand can be added without cluttering the pinned thread, which would just contain a single post with a link to the hand.

 

Without doubt this is a kludgy suggestion and not one that will command great compliance by newcomer posters. Possibly too labour intensive for moderators.

 

2) Priority

 

These are the main factors, in my view, that affect appropriate priority:

a) Ease of implementation of a fix (easy = high priority)

b) Severity of the problem (Severe = high priority)

c) Age of the issue (older = high priority)

Obviously there is potential for tension between these factors.

 

Severity of the problem can be subdivided also into three factors:

(i) Frequency of situation arising

(ii) Likelihood of loss resulting when it does

(ii) Magnitude of loss when it occurs

 

Issues should probably escalate in priority with age, otherwise a moderate priority will never get addressed as there will always be a higher one.

 

If BBO expects that a fix is likely to be a long time incoming, it might help to provide an assessment of these factors in the control thread for that issue, with a budgeted fix date.

 

I predict two main areas of contention:

1) Whether a fix is indicated at all (and if so which of potentially several).

2) The "ease of implementation" is an issue on which BBO may be privy to information not available to users, which could cause conflict in assessment of priorities.

It would be healthy if such disputes were out in the open.

 

In my immediate response to this post I shall list some of the more common complaints which I think may be worthy of pinning. Others will have a different list, and I am not convinced that I have thought of all of mine.

[1eyedjack]

OK, so here is my list of issues, in no particular order of priority (although I comment on priority on each issue where I have an opinion).

 

Use of total points to judge NT level

==============================

 

Comment: High priority resulting from high frequency. GIB uses TP to evaluate hands prior to establishment of fit, when there remains a good prospect that NT will be the final strain. This results in it making GF bids on hands that are only worth an invite. Arguably, even when a minor suit fit is found, the priority assigned to TP is overstated given that 3N is usually an option to be considered, but that is harder to police.

 

Overhaul of hand evaluation system generally

======================================

 

(ie to take suit length into account instead of shortages incertain situations)

 

Comment: Probably a low priority due to difficulty of implementation.

 

Mismatches between explanations and hands held

=========================================

 

Difficult to assign a priority because I don't understand the process by which explanations are generated, but I suspect a major project so low priority. It must involve a degree of automation, so if fixing that is easy it rises in priority.

 

Competing showing 25+ TP or 30+ TP (or whatever)

==========================================

 

Comment: Only moderate priority, because users should be on notice of this predilection and most complaints result from players making what they think are competitive sacrifice bids which GIB assumes are bidding to make; which would be a reasonable action but for the fact that you can see what the bid means before committing. It retains some priority, however, as it restricts your ability to make sacrifice bids at the game level, and often 25 TP is not even necessary for the contract to have play to make.

 

Slam bidding

===========

 

Various issues which should probably be separately threaded:

a) Inappropriate use of Blackwood as preferred slam try (ie when holding a void or wide open suit)

b) Tendency to leap to slam without using any slam try on the way (even Bwood, however inappropriate) based on general TP values.

c) Use of 4N as Bwood when clubs are agreed suit (and to a lesser extent Diamonds).

d) Indiscriminate inclusion of void in response to Blackwood (one key + void gives a response that commits to slam).

 

Accept transfer and later competing shows superaccept.

===============================================

 

General malaise is that some bids show hand types denied earlier in the auction but this one crops up with high frequency.

 

Assume 1N opener has guards in all suits, despite overcall

================================================

 

Undisciplined Capp

================

 

Contentious issue, showing 5-4 either way round in 2 suits.

 

Bidding 5cm in pref to 4cM in response to X

====================================

 

Possibly recently improved in ver 33 but there is some evidence not solved.

 

2+ trumps nebulous penalty X (and pulling X) overhaul of double structure

==============================================================

 

High priority due to frequency and cost.

 

Continuations after a strong single-suiter or hand too strong for 1N overcall starts with t/o X

===========================================================================

 

High priority by virtually all of the measurements. Currently GIB systemically agrees with X to show one of three hand types:

1) 3-suited hand with opening values, short in opener's suit.

2) Balanced hand too strong for 1N overcall

3) Hand with distribution suitable for a suit overcall but too strong.

 

However in its follow-up sequences advancer has a tendency to fail to allow for any possibility other than type 1, and overcaller does not help matters by clarifying.

 

Hole in balanced hand ranges when protecting in 4^thseat

===============================================

 

Some ranges are systemically unbiddable (ie between protective 1N and delayed via Double).

Only moderate priority, in my view, partly because of low frequency of sequence, and partly because there is an inherent lack of safety in any solution once you accept, as seems to be the expert consensus, that an immediate protective 1N should be about a weak 1N opener strength, so you have a wide range in total to cover. This reduces the long term expectation of loss from not fixing it.

 

Allow 1N rebid to have singleton in responder? 6cm? 6cm to open 1N?

=========================================================

 

Recent posts show some improvement in ver 33, in that GIB will now rebid 1N with a singleton. Unfortunately it also does so with 6-5-1-1

 

Card play (particularly in defence)

============================

 

We get conflicting reports of the feasibility of implementing any significant change in GIB's card play. There is I think broad agreement that such feasibility as exists is very limited. But occasionally we get some examples where action is taken.

 

Difficult to prioritise, due to a huge disparity between ease of implementation and severity of the consequences. If it simply cannot be done, then no amount of severity will raise the priority. Possibly should be split into two threads:

 

Absence of formal carding methods, and

 

judgment/simulation problems. This category is closely linked to the "blind faith" issue discussed below.

 

Blind faith

=========

 

GIB places blind faith in other players conforming to GIB system to the letter (even though in recent versions GIB will depart from system by a card or so). This creates two distinct problems. Each possibly deserving of its own dedicated control thread, but then the same fix would solve both problems, so perhaps not. Furthermore, as the same fix would solve both problems this should elevate its priority to high.

 

The lesser problem of the two is its vulnerability to psychs by humans. It remains a level playing field of sorts, as all humans are in the same boat (except in Instants). Arguably those with experience playing against robots have an unfair advantage.

 

The more significant problem is that in defensive play GIB will provide equal priority to lines of defence that assume opponent honesty as it will to other lines that result in the same number of tricks without making such assumptions about the opponents. In such cases the line that does not rely on assumptions re. opponents (or forthat matter partner) is actively superior, but somehow GIB needs to be taught that.

 

A possible solution might be to allow for a margin of error in the opponent's bidding, but perhaps continuing with blind faith in partner. A refinement might be to distinguish between human and robot opponents, but that may not be popular.

[Bbradley62]

There are also general categories of bug fixes and system improvements. Everything you've listed above is a system improvement, and I think it's likely that bug fixes generally get a higher priority.

[chasetb]

I think this combines both a flaw and a bug. GIB should not be counting TP when no fit has been established, and I look at it as 3♣ categorically denies 4 hearts, since there is easily room over that to find a possible 4-4 Club fit. I supported the Spades because slam still seemed like a possibility, and I've seen GIB with 6+ in this sequence before.

[hv=sn=chasetb&s=SAJHQ932DQJT6CKQ2&wn=Robot&w=SQ7H864D8432C8643&nn=Robot&n=ST8642HAKJ7DCAJ95&en=Robot&e=SK953HT5DAK975CT7&d=n&v=e&b=9&a=1S%28Major%20suit%20opening%20--%205+%20!S%3B%2011-21%20HCP%3B%2012-22%20total%20points%29P2D%28Forcing%20two%20over%20one%20--%2013+%20HCP%3B%20biddabl%29P3C%28New%20suit%20--%204+%20!C%3B%205+%20!S%3B%2021-%20HCP%3B%2016-22%20total%20points%3B%20forcing%20to%203N%29P3S%28Raise%20--%203+%20!S%3B%2013+%20HCP%3B%20biddable%20!D%3B%2014%29P4C%28Cue%20bid%20--%204+%20!C%3B%205+%20!S%3B%2021-%20HCP%3B%20!CA%3B%2016-22%20total%20points%29P4S%283+%20!S%3B%2013+%20HCP%3B%20biddable%20!D%3B%2014-17%20total%29PPP&p=DKD6D2S2S6S5SJSQD4S4D7DTC5CTCKC8C2C6CJC7CAHTCQC3C9H5H2C4H7D9H9H8H3H6HJS9S3SAS7STHQH4HAD5HKSKDJD8DADQD3S8]400|300[/hv]

[1eyedjack]

There are also general categories of bug fixes and system improvements. Everything you've listed above is a system improvement, and I think it's likely that bug fixes generally get a higher priority.

I agree. But that was just my list

 

Bugs tend to be one-off events that do not lend themselves to a themed thread or other generalisation of documentation or approach to fixing.

 

I am guessing also that when they are identified, fixing them is by and large a relatively simple process for the programmers. That would naturally elevate their priority.Most clear bugs, once identified and reported, get fixed within a couple of upgrades. In my list I have tended to focus on the regular issues that continue to crop up over the ages.

[1eyedjack]

I think this combines both a flaw and a bug ...

Might be best to keep individual reports in their own threads. This thread is about the BBO and forum approach to tackling issues, not actually tackling specific examples. Let's not hijack, please.