Hi Carsten, >> What do you think? Would this be interesting for GnuBG?
Just to say, YES - I don't know much about low-level coding but, as a QA Analyst, I do have some experience of Swagger docs and API calls / testing / scripting with Postman and how VERY useful APIs are. If I am understanding this topic correctly, I think standardizing APIs across programs could be extremely useful in programmatically creating / manipulating / interrogating backgammon positions / running automatic Bot vs Bot tournaments etc I've joined your Discord as interested in further developments. Please feel free to let me know if you would like me to assist with some high level testing of your API Kind regards, Wayne On Tue, 14 Nov 2023 at 17:03, <bug-gnubg-requ...@gnu.org> wrote: > Send Bug-gnubg mailing list submissions to > bug-gnubg@gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/bug-gnubg > or, via email, send a message with subject or body 'help' to > bug-gnubg-requ...@gnu.org > > You can reach the person managing the list at > bug-gnubg-ow...@gnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Bug-gnubg digest..." > > > Today's Topics: > > 1. Backgammon API (Carsten Wenderdel) > 2. New backgammon engine: wildbg (Carsten Wenderdel) > 3. Re: Backgammon API (Lasse Hjorth Madsen) > 4. Re: Backgammon API (Guido Flohr) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 13 Nov 2023 20:22:22 +0000 > From: Carsten Wenderdel <chrisfo...@outlook.de> > To: "bug-gnubg@gnu.org" <bug-gnubg@gnu.org> > Subject: Backgammon API > Message-ID: <8e4009a0-07af-4c8c-977b-aa854a471...@outlook.de> > Content-Type: text/plain; charset="utf-8" > > Hello, > > in the past there have been several attempts to separate the engine part > of GnuBG from the GUI. Two examples: > > https://github.com/alcacoop/libgnubg-android > https://github.com/hwatheod/gnubg-web > > Both attempts had a very specific goal in mind and were not continued. > > In chess there is UCI, an interface understood by virtually all engines, > bots and GUIs. Wouldn’t it be great if we had something similar for > backgammon? Someone could write a new engine or GUI without worrying too > much about the other. If someone wanted to create a JavaScript or Flutter > GUI on top of GnuBG, it would be possible. > > Such an API can’t exclusively be a C API. There are GUIs and bots written > in other programming languages. Also it should easily work if both parts > are closed source and distributed independently. > > In chess UCI uses standard input and output. I believe a modern > interpretation should be based on web technologies. > While protobuf is faster than JSON, a combination of HTTP and JSON is > widely supported by programming languages and libraries. > If we find the right spot where to split engine and GUI, a few > milliseconds more or less are not crucial. > > Not all engines might use neural networks and be able to calculate winning > probabilities. So maybe also a basic version of the API should be taken > into consideration. For game play there are only two questions that need to > be asked by the client and answered by the engine: > 1. Given a certain position and dice (and state of the match, cube, etc.): > What is the correct move? > 2. Given a certain position (and state of the match, cube, etc.): What is > the correct cube action? > > I found one project where someone has ported GnuBG to the Go programming > language and used HTTP and JSON for an API: > https://github.com/foochu/bgweb-api > The README of this project also has some examples how the API looks like. > > For my project wildbg (https://github.com/carsten-wenderdel/wildbg) I > slightly changed that API. Mainly I removed some information and changed > POST to GET requests. > So if from the starting position 3 and 1 are rolled, this is how the > request would look like: > > https://wildbg.shuttleapp.rs/move?die1=3&die2=1&p1=-2&p6=5&p8=3&p12=-5&p13=5&p17=-3&p19=-5&p24=2 > > Have a look at the URL, it’s already deployed and working. > For more documentation around it, see > https://wildbg.shuttleapp.rs/swagger-ui > > All this is completely stateless. So the engine does not need to remember > anything, every request would carry all the information needed. > > Currently missing: More HTTP parameters describing state of the match, > Crawford, desired strength of the engine etc. > > Also missing are rollouts. For that I imagine a POST request. Immediately > returned would not be the result of the rollout but instead an ID. With > this ID the status of the rollout could be queried and potentially also the > rollout be canceled. > > In general, responsibilities could be split like that: > > Engine > - Evaluation of positions, not only 0-ply, but also 1, 2 or 3 ply. > - Rollouts > > Client: > - Keeping track of the match state > - Match analysis > - Calculation of ELO or performance rating > > I’ve already contacted Frank Berger, the author of BGBlitz. He might be > interested in implementing such an API in BGBlitz, so other engines could > use the GUI of BGBlitz. > > What do you think? Would this be interesting for GnuBG? > > Best, Carsten > > ps: For discussions about computer backgammon (not only GnuBG) I’ve > created a Discord server. So if you are interested in this topic or others, > consider joining there: https://discord.gg/Ckvf7y8nGz > > > ------------------------------ > > Message: 2 > Date: Mon, 13 Nov 2023 20:20:39 +0000 > From: Carsten Wenderdel <chrisfo...@outlook.de> > To: "bug-gnubg@gnu.org" <bug-gnubg@gnu.org> > Subject: New backgammon engine: wildbg > Message-ID: <5300a2c7-34b6-4005-b7c2-f8dc34983...@outlook.de> > Content-Type: text/plain; charset="utf-8" > > Hello, > > > I’m about to send an email proposing some HTTP API for communicating > between backgammon engines and clients like GUIs or bots. > > For context, I do some advertisement first. > > I have started work on a new backgammon engine: > https://github.com/carsten-wenderdel/wildbg > > The current strength is roughly 1800 ELO or an error rate mEMG of roughly > 7.5 when being analyzed with GnuBG. > So far only the classic TD-Gammon inputs have been implemented, the expert > features from Hans Berliner are missing. > It’s also still learning without expert features, so I’m optimistic that > there is lots of room for improvement. > > You can play against it on FIBS (bot name is wildbg). > If you are interested in particular positions, try out > https://wildbg.shuttleapp.rs/swagger-ui/ > > > Wildbg is doing many things similar as GnuBG, which is really a great > project. > Some things however are done differently: > > 1. MIT/Apache 2 instead of GPL > > It seams, some commercial apps have copied GnuBG source code and it seems > it was not followed up. > On the other hand, legally GPL is not allowed on Apple’s App Store because > of license issues, even if the app is free of charge and source code is > provided. > Sometimes I have the impression that the GPL is not giving the protection > someone would like, but makes it difficult for some honest people. > I don’t want to start a discussion here, but only explain my choice. There > are very good reasons for GPL and against MIT too. > > 2. Rust instead of C > > Rust has the features other modern languages like Kotlin or Swift provide > which allow high level programming. > At the same time Rust allows very fast code without a tracing garbage > collector. This is important when being embedded as a library in another > app or in the web (via web assembly). > > 3. HTTP/json API instead of own GUI > > Both engine and GUI are already quite big undertakings. The chess > community has always separated those two, I think the backgammon community > should too. > > 4. Usage of 3rd party machine learning libraries instead of self written > neural nets > > This allows usage of for example PyTorch and the ONNX format. Changing the > topology of the nets (ReLu instead of sigmoid, adding hidden layers) > becomes very easy. > > > All these choices are based on opinions, I very much understand if someone > disagrees with them. > So my hope is that these choices can grow the number of contributors to > computer backgammon. > Some people prefer C, some prefer Rust. Some people prefer GPL, others > prefer MIT. > > I’d be super happy if wildbg would evolve into a community project similar > to GnuBG. > > I don’t want to abuse this mailing list too much; if you are interested > please join this Discord server: > https://discord.gg/Ckvf7y8nGz > > > All the best, > Carsten > > > > > > ------------------------------ > > Message: 3 > Date: Tue, 14 Nov 2023 07:02:06 +0100 > From: Lasse Hjorth Madsen <lassehjorthmad...@gmail.com> > To: Carsten Wenderdel <chrisfo...@outlook.de> > Cc: "bug-gnubg@gnu.org" <bug-gnubg@gnu.org> > Subject: Re: Backgammon API > Message-ID: > < > cajrjsxj0eyfilz7ugzkch0-dbkxsfykbg9zyhxnlkcbaz1b...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Carsten, > > I think this is exciting. I'm a data scientist, not a software developer, > so I don't have a deep understanding of all the implications > of choices of technology. But to me the approach you describe sounds > absolutely right. > > Thanks, > Lasse > > man. 13. nov. 2023 kl. 21.23 skrev Carsten Wenderdel < > chrisfo...@outlook.de > >: > > > Hello, > > > > in the past there have been several attempts to separate the engine part > > of GnuBG from the GUI. Two examples: > > > > https://github.com/alcacoop/libgnubg-android > > https://github.com/hwatheod/gnubg-web > > > > Both attempts had a very specific goal in mind and were not continued. > > > > In chess there is UCI, an interface understood by virtually all engines, > > bots and GUIs. Wouldn’t it be great if we had something similar for > > backgammon? Someone could write a new engine or GUI without worrying too > > much about the other. If someone wanted to create a JavaScript or Flutter > > GUI on top of GnuBG, it would be possible. > > > > Such an API can’t exclusively be a C API. There are GUIs and bots written > > in other programming languages. Also it should easily work if both parts > > are closed source and distributed independently. > > > > In chess UCI uses standard input and output. I believe a modern > > interpretation should be based on web technologies. > > While protobuf is faster than JSON, a combination of HTTP and JSON is > > widely supported by programming languages and libraries. > > If we find the right spot where to split engine and GUI, a few > > milliseconds more or less are not crucial. > > > > Not all engines might use neural networks and be able to calculate > winning > > probabilities. So maybe also a basic version of the API should be taken > > into consideration. For game play there are only two questions that need > to > > be asked by the client and answered by the engine: > > 1. Given a certain position and dice (and state of the match, cube, > etc.): > > What is the correct move? > > 2. Given a certain position (and state of the match, cube, etc.): What is > > the correct cube action? > > > > I found one project where someone has ported GnuBG to the Go programming > > language and used HTTP and JSON for an API: > > https://github.com/foochu/bgweb-api > > The README of this project also has some examples how the API looks like. > > > > For my project wildbg (https://github.com/carsten-wenderdel/wildbg) I > > slightly changed that API. Mainly I removed some information and changed > > POST to GET requests. > > So if from the starting position 3 and 1 are rolled, this is how the > > request would look like: > > > > > https://wildbg.shuttleapp.rs/move?die1=3&die2=1&p1=-2&p6=5&p8=3&p12=-5&p13=5&p17=-3&p19=-5&p24=2 > > > > Have a look at the URL, it’s already deployed and working. > > For more documentation around it, see > > https://wildbg.shuttleapp.rs/swagger-ui > > > > All this is completely stateless. So the engine does not need to remember > > anything, every request would carry all the information needed. > > > > Currently missing: More HTTP parameters describing state of the match, > > Crawford, desired strength of the engine etc. > > > > Also missing are rollouts. For that I imagine a POST request. Immediately > > returned would not be the result of the rollout but instead an ID. With > > this ID the status of the rollout could be queried and potentially also > the > > rollout be canceled. > > > > In general, responsibilities could be split like that: > > > > Engine > > - Evaluation of positions, not only 0-ply, but also 1, 2 or 3 ply. > > - Rollouts > > > > Client: > > - Keeping track of the match state > > - Match analysis > > - Calculation of ELO or performance rating > > > > I’ve already contacted Frank Berger, the author of BGBlitz. He might be > > interested in implementing such an API in BGBlitz, so other engines could > > use the GUI of BGBlitz. > > > > What do you think? Would this be interesting for GnuBG? > > > > Best, Carsten > > > > ps: For discussions about computer backgammon (not only GnuBG) I’ve > > created a Discord server. So if you are interested in this topic or > others, > > consider joining there: https://discord.gg/Ckvf7y8nGz > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.gnu.org/archive/html/bug-gnubg/attachments/20231114/b96f8f47/attachment.htm > > > > ------------------------------ > > Message: 4 > Date: Tue, 14 Nov 2023 07:45:38 +0000 > From: Guido Flohr <guido.fl...@cantanea.com> > To: Carsten Wenderdel <chrisfo...@outlook.de> > Cc: bug-gnubg@gnu.org <bug-gnubg@gnu.org> > Subject: Re: Backgammon API > Message-ID: > < > 0102018bcccb00d6-6bb37e63-3d7c-4a77-bf8a-1dc9c707496f-000...@eu-west-1.amazonses.com > > > > Content-Type: text/plain; charset=UTF-8 > > Hi, > > > On 13 Nov 2023, at 21:22, Carsten Wenderdel <chrisfo...@outlook.de> > wrote: > > > > In chess there is UCI, an interface understood by virtually all engines, > bots and GUIs. Wouldn’t it be great if we had something similar for > backgammon? Someone could write a new engine or GUI without worrying too > much about the other. If someone wanted to create a JavaScript or Flutter > GUI on top of GnuBG, it would be possible. > > I have both implemented UCI and xboard and imho both ”protocols” are > terrible. We should learn from their mistakes. > > > In chess UCI uses standard input and output. I believe a modern > interpretation should be based on web technologies. > > Absolutely. > > What would really help would be a documentation of the external interface > of GNUBG. That should allow anybody with decent knowledge in JavaScript, > Python, Perl, you name it to write an adapter that translates GNUBG’s > external interface to a new protocol. > > For that new protocol, I think it makes sense to look at the FIBS > protocol. Of course, I wouldn’t use raw sockets nowadays but a REST API or > GraphQL but if board representations, moves, etc. resemble FIBS, it should > be easier to modify existing clients to speak the new protocol. > > Cheers, > Guido > > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Bug-gnubg mailing list > Bug-gnubg@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-gnubg > > > ------------------------------ > > End of Bug-gnubg Digest, Vol 237, Issue 2 > ***************************************** >
