[skiborder]

It would be great if there were different bots available to play with. I play with the bbo gib all the time. I learned to play bridge with it. And they don't talk back to you and they play quickly, lol

That said, i just tried learning precision and gave up because other than the pro i was learning from, there was no way to practice.

I know that bbo plate must be full.... but if outside developers could develop bots it would be great... u could get them in the app store and a system of revenue sharing could be between the developer and BBO.

people would develop all kinds of bots and you could chose the partner and system that you liked.

The details seem easy to develop and i don't want to push any particular idea...just the idea that more bots and gibs the better... and there could be BBO approved ones only so that after a beta test they could tell ones that delivered and worked.

[barmar]

The language used to create bot rules is incredibly cryptic -- it looks practically like gibberish. I'm amazed that Georgi does so well at it.

Opening up the process to outsiders would require teaching them the language, and then supporting them when they have questions or problems.

Writing an entire bidding system from scratch would probably be at least a year's work.

[skiborder]

barmar, on 2017-August-30, 18:45, said:

The language used to create bot rules is incredibly cryptic -- it looks practically like gibberish. I'm amazed that Georgi does so well at it.

Opening up the process to outsiders would require teaching them the language, and then supporting them when they have questions or problems.

Writing an entire bidding system from scratch would probably be at least a year's work.

If BBO creates the API to connect to the play part of the software, programers can use whatever language they want as long as the connect to the API from BBO.

Its unfortunate if your saying that we can never have any customization of robots to play with. People would like to play either different systems or there own set of menu driven gadgets and conventions.

I would have no problem if BBO did it but it could become far more robust if it were opened to the world of programmers rather than just the one that BBO has. I'm not criticizing his work , but i would pay and love to use other robots as well to make my bridge experience better for the future.

[The_Badger]

barmar, on 2017-August-30, 18:45, said:

The language used to create bot rules is incredibly cryptic -- it looks practically like GIBberish.

Now that made me smile, Barry

[steve2005]

You can connect chess programs from your computer to play chess on the internet.
The side effect is on these sites anyone who knows how to do this can play like a Grandmaster, in fact probably better and very fast too.
Now on many chess sites there is security to prevent this. Using a program is even allowed on some sites but you have to declare this.
So be careful what you wish for.

[johnu]

barmar, on 2017-August-30, 18:45, said:

Writing an entire bidding system from scratch would probably be at least a year's work.

Maybe somebody could do a bad job of writing a bidding system in a year. Debugging, rewriting, adding new sequences that weren't coded or thought of would probably take several more years. And then the bidding system has to be tied into the card play system.

There are commercial bridge systems that are probably much better than GIB that could be plugged into BBO but BBO seems to have decided that they have spent so much time and money on trying to fix GIB that they will continue on trying to make GIB work.

[barmar]

skiborder, on 2017-August-30, 19:22, said:

If BBO creates the API to connect to the play part of the software, programers can use whatever language they want as long as the connect to the API from BBO.

Currently, all our code that deals with robots works by running the GIB CLI application and parsing its text output. We never designed a generic API.

So plugging in other robots, like Jack or Wbridge, would require significant development work to redesign all of this in a more general way, or translators would have to be written for each robot so it could accomodate GIB's input and output formats.

[tomkron]

barmar, on 2017-August-31, 10:28, said:

[T]ranslators would have to be written for each robot so it could accomodate GIB's input and output formats.

Is there documentation anywhere on GIB's input/output formats? I would be curious to know how simple or complex this format was.

[barmar]

tomkron, on 2017-September-09, 07:54, said:

Is there documentation anywhere on GIB's input/output formats? I would be curious to know how simple or complex this format was.

There's documentation of the syntax, but it's not very clear, doesn't explain everything you need to really understand the rules, and is a little out of date.

If you want to see what it looks like, here's the rules that say when to pass partner's bid of game in a major:

0 ..  [45]b[HS]:.:$
1 77Xd  P	~BOK&&(LOSERS(0,b)>1)~        :m~32-MVAL(PARD,LP)~:SBFIT
1 77d  P	~BOK~:M~.<34-MVAL(PARD,LP)~         .
1 60Xd  P	~BOK~:M~.+VAL(PARD,LP)<32~          :m~31-VAL(PARD,LP)~:SBFIT

The first line contains a pattern that matches the auction so far. It's kind of like a regular expression: "." matches any bid, "$" matches the end of the auction. But ":" separates bids and before a pattern you can put a lowercase letter, which assigns that variable (the documentation calls this a "grab") the value that was matched (so this it matches H or S, and assigns that suit letter to the variable "b").

The next 3 lines are rules that are tested when the bidding matches that pattern. The first column 1 means this is level 1 of the auction depth, nested inside level 0 from the first line. After that is a priority level (if multiple rules match, the one with the highest priority takes precedence) and flags (X means the rule can't be overridden by simulations, d means it's a "default" rule).

The next field is the bid to make if this rule is used, these all say P.

After that is a constraint specification, which is matched against the information the bidder has: his own hand and what the other players have shown. BOK is true if b contains the highest suit where we have the best fit. LOSERS(0, b) is the maximum number of combined losers we have in suit b (we don't look for slam if we know we have 2 trump losers). MVAL(PARD,LP) is the maximum number of total points partner has shown (total points are called "Lindelof Points" in the code, hence the LP macro). M is followed by a pattern that our points have to match, so M~.<34-MVAL(PARD,LP) means to subtract partner's maximum points from 34, and test that we have less than this (in other words, our combined points are less than 34).

The next field after that is what we're showing if we make the bid. SBFIT is a macro that expands into all the features that describe the fit we have in suit b. "m" or "M" is our total points, lowercase for an upper bound, uppercase for a lower bound; so m~32-MVAL(PARD,LP) means we're showing at most 32 minus whatever partner has limited his hand to.

Variables are just single lowercase letters like that, and the macros are full of conventions about each variable, like "b" contains the proposed trump suit. The B in the macros BOK and SBFIT refer to this (they stand for "Is b an OK suit?" and "Show that we have a Fit in b"). These conventions aren't mentioned anywhere in the documentation, you learn them by reading the macros, some of which which have comments explaining what they do.

You can match and show lots of other things like lengths of specific suit, HCP, hand distributions, HCP in specific suits, controls, stoppers. These are all done using a single uppercase letter followed by a pattern. These all correspond to the things that get shown in a bidding explanation.

The full rule file for GIB's current system is over 7000 rules like this.

[tomkron]

barmar, on 2017-September-09, 22:41, said:

If you want to see what it looks like, here's the rules that say when to pass partner's bid of game in a major:
(... example trimmed ...)

That's pretty arcane. Reminds me of sendmail format. Thanks for the reply, but I was actually asking about the CLI format relative to understanding what would be involved in integrating a different bot. Does each call to GIB pass it the entire history of the deal so far? Does the GIB program stay running for the duration of the deal and handshake back-and-forth as new info becomes available? That sort of thing.

Thank-you for any insight you are willing to share.

This post has been edited by barmar: 2017-September-11, 08:11
Reason for edit: fix quote

[barmar]

tomkron, on 2017-September-10, 06:25, said:

That's pretty arcane. Reminds me of sendmail format. Thanks for the reply, but I was actually asking about the CLI format relative to understanding what would be involved in integrating a different bot. Does each call to GIB pass it the entire history of the deal so far? Does the GIB program stay running for the duration of the deal and handshake back-and-forth as new info becomes available? That sort of thing.

Thank-you for any insight you are willing to share.

Oh, sorry.

When you're playing a robot game, the GIB program stays running and we go back and forth. We also start new ones on the fly when you hover over a bid during human bidding, to ask it the meaning of the bid; we send a fake hand and the sequence of all bids so far along with the proposed bid, and get the meaning of that.

The input for the latter looks something like:

37JA.5T.3478.68J
5Q.24KA.5K.457QK
26.6789Q.6JQ.3TA
489TK.3J.29TA.29
s -+
+<bid>
+<bid>
+<bid>
+<bid1>!
+<bid2>!
+<bid3>

The first 3 <bid>s are the auction so far, then <bid1> through <bidN> are possible continuations, and GIB prints the meaning of each of them on a line of output. GIB also takes command line options for things like seeding the RNG, the amount of thinking time, the type of scoring.

[tomkron]

OK, thanks!