[pran]

hrothgar, on 2019-December-13, 16:28, said:

I think the obvious reason is that Law 6 needs to be changed for Online Bridge games.

Law 6E (with assistance of Law 6F if needed) covers that completely.

[blackshoe]

barmar, on 2019-December-13, 10:33, said:

In fact, there was an attempt to specify online laws about a decade ago, and that was pretty much the extent of it.

More like two decades ago.

[barmar]

pran, on 2019-December-13, 17:32, said:

Law 6E (with assistance of Law 6F if needed) covers that completely.

Exactly. We already have computer-dealt hands for most F2F bridge, there should be no difference for online bridge. You just ignore all the parts of Law 6 that imply hand dealing, as permitted by 6E4.

[pescetom]

blackshoe, on 2019-December-13, 19:40, said:

More like two decades ago.

Exactly.
If BBO or WBF think we are still in that film then the name Thomas Andrews comes to mind

[pescetom]

I bet everyone reading here will also be interested in the new BBOalert disclosure tool discussion.

[stanmaz]

barmar, on 2019-December-10, 20:36, said:

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]

stanmaz, on 2019-December-19, 09:59, said:

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:

Quote

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]

hrothgar, on 2019-December-19, 10:29, said:

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]

stanmaz, on 2019-December-19, 12:57, said:

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]

barmar, on 2019-December-20, 11:30, said:

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.

barmar, on 2019-December-20, 11:30, said:

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]

sanst, on 2019-December-21, 03:12, said:

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]

pran, on 2019-December-21, 03:25, said:

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]

pran, on 2019-December-21, 03:25, said:

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]

sanst, on 2019-December-21, 04:08, said:

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

Simple answer: NO!

[pescetom]

sanst, on 2019-December-21, 04:08, said:

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.

sanst, on 2019-December-21, 04:08, said:

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]

blackshoe, on 2019-December-21, 10:01, said:

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]

blackshoe, on 2019-December-21, 10:01, said:

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.

pran, on 2019-December-21, 14:38, said:

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.