gtp

gtp@lists.lysator.liu.se

164 discussions

None
by None 08 Mar '22

08 Mar '22

category 4 and I'm pretty sure that all of Andrew's *plus programs so far fall into category 1b. I can add that GNU Go is a 1a and that it would require a major effort to get it further than 2. /Gunnar

1 0

None
by None 08 Mar '22

08 Mar '22

http://www.lysator.liu.se/~gunnar/gtp/spec9.txt 7. komi Description: Sets the Komi value for the game. Parameters: Real: Komi value for the game. On Success: The Komi value changed. On Failure: The Komi value is not changed. Error Messages: invalid_argument out_of_range Dan

1 0

gtp v2 shortsighted ?
by Rodrigue ASSARD 23 Aug '07

23 Aug '07

Dear list, first of all, my intention is by any means to hurt anyone's feeling nor to start any flame war. This said, IMHO i think this spec is a little shortsighted ... Here are at least three reasons why : 1- the BOARD command should accept to create rectangular gobans... the question is why restrict it to square only ? I understand gtp is designed to enable testing on software programs ? then please let the possibility to foster some diversity... It would be good to see gnugo on a 4x7 board for instance :-) 2- "Boards larger than 25x25 are not supported by the protocol." Why ? Is it so complex to use another coordinate systems as 1,1 instead of A1 ? I know SGF has the same limitations, but why imposing such limitations ? is that another heresy to think about a 51x53 board ? played by two softwares for instance ? OK i'm definitely an heretic... for now :-) 3- the last but not the least concerns the time_settings. And here it's a special request : why not offer the possibility to set different time settings for each player ? again i think it would be fun to afford more time for gnugo than for myself. That would put more pressure on me... ok i talk a lot about gnugo but i understand that the spec is tightly bound to gnugo or the opposite ... Hope that i'm not off topic. Best regards. Rodrigue.

3 3

Re: [gtp] gtp v2 shortsighted ?
by A van Kessel 23 Aug '07

23 Aug '07

I'm afraid, we basically mean the same thing. I have always commented on GTP that it is not designed for angines to 'play a game' it is intended (and designed) to send commands to engines, and expect them to reply with the appropiate responses. The engine has no notion of a game; it is supposed to respond to isolated requests. One of Gunnar's design principles was to keep the amount of shared state (between engine and controller) as small as possible. Basically there is only initialised+size+komi+board-contents. The timing is more or less optional, and is communicated on a per-move basis. This leaves most of the timekeeping to the controller (arbiter or bridge). This will cause al lot of business-logic to be forced into the bridge (or arbiter) program, but it wil keep the protocol itself relatively small. (and: yes, most engines will have more flags to tweak than the protocol has defined, but there are always private extensions, caommandline-arguments and config-files. AvK

2 1

Re: [gtp] gtp v2 shortsighted ?
by A van Kessel 23 Aug '07

23 Aug '07

[Re=reply: the listserver does noet seem to set the Reply-to: header correctly ... ] > a special request : why not offer the possibility to set > different time settings for each player ? again i think it would be fun Te protocol is asymmetric. There is the engine at one side, and the controller at the other. For a game between two computer players, you need two GTP-"sessions", and one (or two) controllers driving them. There is no restriction on the (time-)settings for both players (the engines don't need to know the other's settings). So it is possible to create an uneven match. This is not a protocol-thing. (and it does not need to be) This is a controller-thing. AvK

2 1

Blank line except for Id
by Salvador Girbau 13 Aug '07

13 Aug '07

Gents, thanks for your work on the GTP. I have a [silly] question, IMO not clear in the protocol draft. Blank lines are specified to be ignored. But what should an engine do with a line containing an Id, and nothing else? If this counts too as a blank line, then the sender gets no acknowledge for some Id number. If, on the other hand, a response =Id should be issued, then this is inconsistent with the treatment of blank lines, which get no response. Thanks, Salvador

2 1

The Number One Success System - noss123.com
by Tommy Lee 18 Jul '07

18 Jul '07

Guidelines have been established to maintain the integrity and high standards of this activity and to enforce respect for participants and the law as it pertains to gifting. Participants are prohibited from representing the activity of* Number One Success System* as anything other than as stated above. Maintaining the integrity of this activity and the privacy of its participants are foremost to ensure that this activity remains viable for the long-term. It is our sincere wish and hope that all who join us will be visited by abundance very soon. http://www.noss123.com/ http://noss123.studioathome.com/ http://noss123.blogspirit.com/ http://noss123.alkablog.com/ http://noss123.blogster.com/ http://noss123.livejournal.com/ http://members.greenpeace.org/blog/noss123 http://noss123.blogspot.com/ http://www.bloglines.com/blog/noss123 http://noss123.bloghi.com

1 0

Handling extra arguments or garbage after valid command
by Colin Kern 21 Mar '07

21 Mar '07

Hello, I'm just starting to implement a Go engine and I'm working on supporting the GTP protocol right now. I was wondering about a situation that I don't see addressed in the current draft of the version 2 protocol. What is done with commands such as: 1 boardsize 19 19 2 boardsize 19 this is garbage It seems the choices are either fail with a syntax error or set the board size to 19 and discard the rest of the line. Has this been discussed before? Was a decision reached? Thanks you, Colin

2 1

Re: [computer-go] GTPv3
by Paul Pogonyshev 09 Mar '07

09 Mar '07

Don Dailey wrote: > On Thu, 2007-03-08 at 12:27 -0500, Weston Markham wrote: > > > > > > There is no race condition because commands _are_ read > > synchronously. > > > But responses _may be_ sent asynchronously. > > > > > > Paul > > > > I'm not sure that I understand Paul's explanation, so I'll try out my > > own: Any race condition that occurs here is entirely the fault of the > > engine. The engine is already responsible for serializing all of the > > responses that it makes. Any failure to do so would allow interleaved > > responses, which could not possibly be understood by the controller. > > So, at the time that the async_genmove is permitted to write its > > asynchronous response, (it may have to acquire a lock in order for > > this to be the case) it is unambiguous whether or not the response to > > abort_async_genmove has been sent. > > I think I am confused. > > So what you might get is this: > > 1. controller sends async_genmove > 2. controller (after some period of time) sends abort. > 3. engine responds to aysnc_genmove > 4. engine responds to the abort search > > In my example, I'm assuming the engine send it's response to > asyn_genmove > at the same instant the controller wanted to abort the search, so the > engine didn't see the abort comming before it was too late. > > Isn't this a race condition? I believe this should cause no problems > because the controller can simply ignore the non-relevant response to > genmove (it knows it send abort.) But I don't think that is what you > are talking about. [Please CC to GTP list] Engine should send response in this way: acquire response lock check if asynchronous command hasn't been aborted/completed if not, send response release lock In other words, there is potential for race condition, as with anything asynchronous. But properly implemented engine doesn't have a race condition situation. Yes, it is more complicated. That's why I'm against making asynchronous stuff required, only optional. Paul

1 0

Re: [computer-go] GTPv3
by Gunnar Farneback 08 Mar '07

08 Mar '07

Paul wrote (on the computer-go list): > About asynchronous move generation. > > I'd propose something like this. Add some form for asynchronous > responses. E.g. '=[id] ...' means success, '?[id] ...' means error > (this is as now) and '%[id] ...' means asynchronous response. Maybe > for asynchronous commands it makes sense to make id mandatory. > Responses must not be mixed, i.e. you cannot start a synchronous > response inside asynchronous or vice versa (else they will be > impossible to parse properly.) This is in the same direction I've been thinking. To make it consistent with GTP version 2 and fully backwards compatible it can be designed like this: * Asynchronous responses from the engine are encoded like Paul proposes but with "!" as first character (there is precedence in a protocol GTP was originally inspired by). Naturally one response must be complete before starting on another, whether synchronous or asynchronous. * Asynchronous messages may only be sent as responses to asynchronous commands. Thus a GTP version 2 controller would never become confused by asynchronous responses it knows nothing about since it would only send synchronous commands. * Asynchronous responses have the same id as the command initiating them. The id may as usual be omitted by the controller if it is confident that it don't need it. * An asynchronous command must first be acknowledged by a synchronous response (would usually be an empty response if there are no problems and otherwise an error response). * An asynchronous command may additionally have zero, one, or multiple asynchronous responses, depending on the nature of the command and the situation. For example an asynchronous genmove command would normally have one asynchronous response, but zero if the command is aborted. A command requesting debug output could produce any number of asynchronous responses. * Whether an engine is capable of doing asynchronous responses can as usual be tested by known_command or list_commands to see whether it supports specific (asynchronous) commands. * The asynchronous genmove command would be named async_genmove. In contrast to the normal genmove command it would only generate a move, not actually play it. (To keep sanity and avoid undos when the ordering of move generation and abort command depends on race conditions.) * To abort the asynchronous genmove, the controller should send the (synchronous) command abort_async_genmove. If the engine has not returned the asynchronous genmove response before responding to the abort command, it is no longer allowed to return a move. I'm open for discussion on the exact name and whether it should return an error if the move had already been sent (I don't think it should). Example 1: Asynchronous genmove with an intervening synchronous command. Command 3 is sent after receiving the asynchronous move. Controller: 1 async_genmove black 2 version 3 play black E5 Engine: =1 =2 4.0 !1 E5 =3 Example 2: Asynchronous genmove, aborted. The controller plays an own move instead. Controller: 1 async_genmove black 2 abort_async_genmove 3 play black C3 Engine: =1 =2 =3 Example 2b (BAD): Like example 2, but the engine makes an incorrect response. Controller: 1 async_genmove black 2 abort_async_genmove 3 play black C3 Engine: =1 =2 !1 E5 =3 Example 3: Like example 2, but abort command comes too late. Controller: 1 async_genmove black 2 abort_async_genmove 3 play black C3 Engine: =1 !1 E5 =2 =3 Example 4: Asynchronous genmove sent to an engine not supporting it. Controller: 1 async_genmove black Engine: ?1 unknown command /Gunnar

4 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

gtp