On-line Law

[stanmaz]

FYI, BBO considers Full Disclosure convention cards to be a failed experiment. The software for creating them has been abandoned and there are no plans to port it to the HTML version.

 

Unless someone can come up with a better design, it's incredibly difficult to use, and only really effective for simple bidding sequences (mainly the first couple of rounds of bidding, and simple conventions like Blackwood). You have to enter every bidding sequence, so the tree explodes as you get further into bidding sequences.

 

It might be possible to develop AI that examines a corpus of auctions by a pair and infers their agreements from it. But you'd need a huge number of deals so that you'll have enough examples of the less common sequences for the AI to detect the patterns. And having it turn that into human-understandable explanations would also be difficult.

 

I am confident that BBOalert tool that I have developed recently, can completely replace "Full disclosure" : See my post

 

BBOalert is a web browser extension running in background and filling the "Explanation" field automatically when the bidding context defined by the user is encountered. It supports also user defined keyboard shortcuts. The last feature alone can be interesting for those who do not need frequent alerts.

[hrothgar]

I am confident that BBOalert tool that I have developed recently, can completely replace "Full disclosure" : See my post

 

BBOalert is a web browser extension running in background and filling the "Explanation" field automatically when the bidding context defined by the user is encountered. It supports also user defined keyboard shortcuts. The last feature alone can be interesting for those who do not need frequent alerts.

 

Sorry if this is a silly question, but I was reading some stuff on github and ran across the following:

 

The opening bid must begin with empty field

,1C,17+HCP any distribution,Comment: this is the typical opening bid of Precision System

 

You should ignore eventual passes preceding the opening bid

--1C,17+HCP any distribution, this will not work

 

What if the meaning of my bids change by seat?

 

For example, a 2♠ opening in first seat means foo, but a 2!S opening in 4th seat means bar?

Is this supported?

[stanmaz]

Sorry if this is a silly question, but I was reading some stuff on github and ran across the following:

 

 

 

What if the meaning of my bids change by seat?

 

For example, a 2♠ opening in first seat means foo, but a 2!S opening in 4th seat means bar?

Is this supported?

 

Simple workaround : you can use the code :

 

,2S,foo (bar if 4th seat)

 

Another typical example is the sequence 1S-2C = generally game forcing but becomes Drury after initial pass. So the right code is:

 

1S--,2C,GF (Drury after pass)

 

Opponents will be able to interpret your message correctly.

 

BBOalert is just a tool to free you from repetitive task of entering by hand the explanation of frequently alerted calls. But finally you are responsible of the information that your opponents will receive. For this reason I ask the user to set 'Confirm bids' option to enable him to review the explanation text before sending it to the opponents. Exceptionally you can send a chat message to the opponents (for repetitive complex messages shortcuts can be defined).

 

I think that seat sensitive openings are extremely rare. Especially artificial openings. But nobody will blame you if you open 1S at 3rd seat with 8HCP without alerting it. It is usual and as such must not be alerted.

 

Thanks for your useful reaction. It will help me to clarify this potential problem in the sample file.

[hrothgar]

Simple workaround : you can use the code :

 

,2S,foo (bar if 4th seat)

 

Another typical example is the sequence 1S-2C = generally game forcing but becomes Drury after initial pass. So the right code is:

 

1S--,2C,GF (Drury after pass)

 

Opponents will be able to interpret your message correctly.

 

BBOalert is just a tool to free you from repetitive task of entering by hand the explanation of frequently alerted calls. But finally you are responsible of the information that your opponents will receive. For this reason I ask the user to set 'Confirm bids' option to enable him to review the explanation text before sending it to the opponents. Exceptionally you can send a chat message to the opponents (for repetitive complex messages shortcuts can be defined).

 

I think that seat sensitive openings are extremely rare. Especially artificial openings. But nobody will blame you if you open 1S at 3rd seat with 8HCP without alerting it. It is usual and as such must not be alerted.

 

Thanks for your useful reaction. It will help me to clarify this potential problem in the sample file.

 

If I am understanding things correctly, the workaround is to use the alert strings to compensate for the fact that the program itself doesn't understand that things mean different things in different seats.

 

Not sure if this is the right choice. Alert strings need to be simple. People stop reading / paying attention quite quickly

 

I'm also not sure that its true that seat sensitive openings are "rare".

 

In my experience, even if you are playing standard, th strength required for an opening bid changes dramatically between first / second seat, third seat, and fourth seat.

(Just think about preempts and the like)

Same with responses, overcalls, you name it.

 

FWIW, I think that its great that you have kicked off this project.

 

At the same time, I think that you get some good feedback if you asked potential users what features they want / need before jumping straight into implementation

[barmar]

I think this tangent about the details of BBOAlert should be taken elewhere (maybe the thread in the "Dealer and Full Disclosure" forum), it's not really relevant to the laws.

 

Although it does highlight the kinds of difficulties that will be encountered in trying to automate disclosure, and that will impact the potential Laws related to automated disclosure. It's kind of like self-driving cars, where there's concern over who would be considered liable if a self-driving car gets into an accident: the person sitting behind the wheel or the car manufacturer. Analogously, if an application like BBOAlert gives an incorrect explanation because of its own bug or limitations, should the bidder be penalized?

[pescetom]

I think this tangent about the details of BBOAlert should be taken elewhere (maybe the thread in the "Dealer and Full Disclosure" forum), it's not really relevant to the laws.

I agree - probably you have the tools to move the tangent so far over into that thread.

I only mentioned that thread here because I was sure people would want to check it out and because it is a healthy reminder that automatic disclosure is possible as well as desirable.

 

Although it does highlight the kinds of difficulties that will be encountered in trying to automate disclosure, and that will impact the potential Laws related to automated disclosure. It's kind of like self-driving cars, where there's concern over who would be considered liable if a self-driving car gets into an accident: the person sitting behind the wheel or the car manufacturer. Analogously, if an application like BBOAlert gives an incorrect explanation because of its own bug or limitations, should the bidder be penalized?

I think the bidder should be responsible for the explanations provided, even if due to a tool bug or limitations or an error of a third party who provided a disclosure library for a system. But I agree it is one of the many interesting ramifications to be discussed.

I suspect some of the most problematic issues (both in terms of direction of the game and related laws) will be in regulating agreements formed between robots and their disclosure to humans. If left unregulated they could be beyond even the best humans due to either inherent complexity or intentional concealment (e.g. encryption of bidding based on a hash of the auction so far).

[sanst]

What I’m missing is a discussion about what the laws of online bridge should regulate and not. Are the IB, LOOT and the like part of the game or not? What should and shouldn’t programs allow and prevent? Is automatic disclosure desirable? What if a program fails? Don’t forget that’s impossible to construct a faultless app which should lead to the conclusion that these programs should be as simple as possible.

[pran]

What I’m missing is a discussion about what the laws of online bridge should regulate and not. Are the IB, LOOT and the like part of the game or not? What should and shouldn’t programs allow and prevent? Is automatic disclosure desirable? What if a program fails? Don’t forget that’s impossible to construct a faultless app which should lead to the conclusion that these programs should be as simple as possible.

Any of the following irregularities should be inhibited as they are mechanical errors for which attempts are easily detected:

Call out of turn

Insufficient bid

Illegal calls

Lead or play out of turn

Revoke

[pescetom]

Any of the following irregularities should be inhibited as they are mechanical errors for which attempts are easily detected:

Call out of turn

Insufficient bid

Illegal calls

Lead or play out of turn

Revoke

I think we all agree on this, at least. I have heard opinions to the contrary though, particularly about retaining the possibility to revoke (don't ask me why).

 

The problem is that some people seem to think that this decision is an end point, instead of just the beginning.

[sanst]

Any of the following irregularities should be inhibited as they are mechanical errors for which attempts are easily detected:

Call out of turn

Insufficient bid

Illegal calls

Lead or play out of turn

Revoke

Maybe they are, but aren’t these part of the game? What I’m trying to make clear that you’re one step ahead and that a discussion about the principles of online bridge laws is necessary before you start making the rules.

[pran]

Maybe they are, but aren’t these part of the game?

Simple answer: NO!

[pescetom]

Maybe they are, but aren’t these part of the game?

I don't think they are part of the game, just irregularities made possible by the traditional (face to face) means of play.

Life for TDs and SBs may be boring without them, but others will not miss them at all.

 

What I’m trying to make clear that you’re one step ahead and that a discussion about the principles of online bridge laws is necessary before you start making the rules.

They are two separate levels, I agree, although one can only discuss principles so far without looking at how they apply to rules and real world situations.

To some extent there is also tacit assumption that the principles should remain those of traditional bridge, although I think that some are already questionable and may prove unsustainable in an electronic environment. Even just restating the current principles as a basis for developing online rules (a major task, but not herculean) might be enough to trigger a coherent rework of face to face rules too. But I'm not holding my breath on that front.

[blackshoe]

How do those making rules for online bridge know how future programs might implement the rules of the game? Perhaps the first step here is to write a program specification.

[pran]

How do those making rules for online bridge know how future programs might implement the rules of the game? Perhaps the first step here is to write a program specification.

That is always the first step when writing (actually when first designing) a program!

 

(Speaking from experience: I wrote my very first computer program in January 1963 - programming language: GIER ALGOL 60)

[pescetom]

How do those making rules for online bridge know how future programs might implement the rules of the game? Perhaps the first step here is to write a program specification.

As I see it, the rules for online bridge ARE in large part the program specification. If you mean that the rule makers have to have a realistic vision of the capabilities of near future programs then I agree, but I don't think that is either particularly difficult nor can derive usefully from a single program specification be it new or existing.

 

 

That is always the first step when writing (actually when first designing) a program!

As I have commented frequently here, the new Laws have to be in decent shape before people start building the platforms for World Bridge championships or whatever. Otherwise the platforms will work all the same (of course) but dictate their own rules, quite possibly very poor and/or very different from what WBF would desire.

[barmar]

How do those making rules for online bridge know how future programs might implement the rules of the game? Perhaps the first step here is to write a program specification.

IIRC, the old online laws simply assumed that programs would prevent the mechanical errrors that are obviously easy to avoid (AFAIK there's no computer bridge implementation that allows them), so there was no need to include the laws related to them. But rather than assume the programs will operate like this, the laws should probably mandate it.

 

Do other games have online laws? I suspect they do similarly, e.g. online chess doesn't need the touch-move rule.

[pran]

IIRC, the old online laws simply assumed that programs would prevent the mechanical errrors that are obviously easy to avoid (AFAIK there's no computer bridge implementation that allows them), so there was no need to include the laws related to them. But rather than assume the programs will operate like this, the laws should probably mandate it.

 

Do other games have online laws? I suspect they do similarly, e.g. online chess doesn't need the touch-move rule.

There are a lot of patience games available on computers, programming them is principally the same.

[mycroft]

Life for TDs and SBs may be boring without [mechanical irregularities], but others will not miss them at all.

I have played under screens (not enough) times, and have directed under screens once. Sure, the biggest benefit of screens is the reduction of several types of illegal or unconscious extraneous communication, but the effective elimination of OLOOTs, insufficient bids, opening bids out of turn,... is a big bonus.

 

As a SB I have no comment, but as a TD, "life may be boring" is - one way of putting it. "Hours of tedium interspersed with moments of terror" (to misquote, misappropriate, and horribly understate a common quotation) would be another. What my DIC told me when I started my screen sessions was that there wouldn't be many director calls (but keeping the game moving was going to be a much bigger part of my job than standard), but when you get one, it will be nasty. And that is definitely true.

[pescetom]

I have played under screens (not enough) times, and have directed under screens once. Sure, the biggest benefit of screens is the reduction of several types of illegal or unconscious extraneous communication, but the effective elimination of OLOOTs, insufficient bids, opening bids out of turn,... is a big bonus.

 

As a SB I have no comment, but as a TD, "life may be boring" is - one way of putting it. "Hours of tedium interspersed with moments of terror" (to misquote, misappropriate, and horribly understate a common quotation) would be another. What my DIC told me when I started my screen sessions was that there wouldn't be many director calls (but keeping the game moving was going to be a much bigger part of my job than standard), but when you get one, it will be nasty. And that is definitely true.

Understandably so. But online play should exclude even more possible irregularities than screens, there being no physical presence of a screen mate or opportunity to interfere in tray movement, bidding card placement etc. The nasty moments for TD will presumably be mainly linked to disclosure issues, and that is partly linked to the choices that will be made.

Of course the dynamics of TD intervention change too - not being physically at a table in presence of players will make it much harder to interact and pick up certain nuances.

[blackshoe]

That is always the first step when writing (actually when first designing) a program!

 

(Speaking from experience: I wrote my very first computer program in January 1963 - programming language: GIER ALGOL 60)

You were a couple of years ahead of me. :-)

[blackshoe]

As I see it, the rules for online bridge ARE in large part the program specification.

Of course. That explains why, when I pointed out some years ago in a forum post somewhere or other about a ruling situation on Microsoft's bridge play site that the correct legal ruling could not be made because the software didn't allow it, the guy who then ran that site said, in effect, "well, we're not changing the program".

[barmar]

Of course. That explains why, when I pointed out some years ago in a forum post somewhere or other about a ruling situation on Microsoft's bridge play site that the correct legal ruling could not be made because the software didn't allow it, the guy who then ran that site said, in effect, "well, we're not changing the program".

I assume you're talking about online bridge programs not implementing certain types of assigned scores, not the way they prevent certain irregularities. BBO is guilty of that as well, it doesn't support split scores.

 

BBO has occasionally been used to run ACBL district NAP or GNT qualifiers, I'm not sure how they deal with this. I suspect they transfer the scores to ACBLScore, and edit the results there, so the results on BBO are not considered "official".

[pescetom]

Simplifying claim law. You claim by stating a number of tricks and playing on, with your hand exposed. Opponents can accept the claim. Or they can dispute it, by continuing, double-dummy (with Declarer playing single-dummy) A theoretical draw-back is that this permits declarer to embark on a fishing expedition. In practice, that doesn't seem happen, perhaps because only particularly naive and tolerant defenders would allow it. [/size]

 

I was surprised this went undiscussed so far. I fully agree that claim management should be automated completely, at least for all but top level competition and perhaps even there too. The current non-electronic rules are contorted, encourage weak players to make rash choices, deter strong players from making reasonable claims, leave room for gamesmanship on both sides and require TDs to spend much time producing verdics which rarely convince all - so an automated solution can hardly be worse.

 

Having said that, I'm not wholly comfortable with the actual solution proposed by nige1. I like the fact that it is automated, and that it avoids the minefield of stating/following a line of play. But there is that small risk of a 'fishing expedition' by Declarer, and perhaps also the opposite risk of a 'fishing expedition' by opponents keen to defend double-dummy. More important to my eyes, this solution maintains the 'induced confusion' risk of current non-electronic rules, in that a player may be disconcerted by the request to play on and then make errors he would not have made had he omitted to claim and simply played to the end (I note on BW that even top players are wary of this risk and advise against playing on after a claim is disputed).

 

Does anyone else share these concerns and/or or have an alternative solution?

[blackshoe]

I assume you're talking about online bridge programs not implementing certain types of assigned scores, not the way they prevent certain irregularities. BBO is guilty of that as well, it doesn't support split scores.

It may have been that, I don't remember the details, though ISTR it involved Law 8 somehow.

[barmar]

It may have been that, I don't remember the details, though ISTR it involved Law 8 somehow.

That's probably 8B1, which says that when the round is called, tables that are in the middle of a board can finish playing it. BBO violates that in "clocked" tournaments, canceling the rest of the board, assigning average to both sides, and allowing the TD to adjust the score.