gtp August 2001

gtp@lists.lysator.liu.se

20 participants
58 discussions

Re: [gtp] Random thoughts
by Dave Denholm 06 Aug '01

06 Aug '01

Daniel Bump <bump(a)match.Stanford.EDU> writes: > > That different systems tend to use different newline conventions is a > > problem that must be addressed by the standard. Personally I prefer > > the unix convention of a single LF but it probably would invite > > problems not to accept the presence of CR. My proposal is that all > > occurences of CR are simply ignored and that an LF defines a > > newline. This would work with systems using only LF or CRLF but > > obviously not with systems using only CR. Would this be a > > (significant) problem? Are there any better solutions? I'd really > > appreciate input on this point. > > Are there any other conventions besides the DOS and Unix ones? ISTR that Mac-os uses CR only ..? But just because a machine uses that for text files doesn't necessarily mean that convention has to work across GTP. Oh : BTW, it does mean that things like \n should not be used in GTP code, since that expands to something platform-specific, and on a Mac gives CR. dd > > It seems to me that this solution (discard CR) is best. > But it means that applications have to be coded somewhat > carefully. > > Dan > > _______________________________________________ > gtp mailing list > gtp(a)lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/gtp -- dave.denholm(a)insignia.com http://www.insignia.com

1 0

Re: computer-go: gnugoclient 2.0
by Daniel Bump 05 Aug '01

05 Aug '01

I'm cross-posting this to the computer and gtp lists. Perhaps that is the best thing to do until the gtp list gets critical mass. Heikki wrote: > I do agree that it is important to specify the behaviour of the undo command > now, to avoid different implementations. But I also agree that the command > is of limited use, probably only in human-computer games, which is but one > use for the protocol. Thus I do not agree that "undo" must belong to the > minimal set of commands all programs must implement. Let me point out some possibilities that require undo. An undo command opens up a world of possibilities. For example we could create a meta-machine that asks GNU Go for its top 2 or 3 moves, tries them, evalutes the board and then chooses the one with the top score. My guess is that it will be slow but immediately stronger than GNU Go. More ambitiously, make a metamachine that does limited global search. Slow, but computers don't get bored if the game is slow. One could code this in a couple of hours using perl and the gtp. But it would require undo. One could do experiments involving multiple engines along the lines of Althofer's n-Hirns. (I don't think the exact n-Hirn idea that was successful in Chess will work immediately in Go, though Althofer has been trying it, but there are possibilities of doing something using multiple engines.) Dan

2 4

Two synonyms
by Daniel Bump 05 Aug '01

05 Aug '01

I want to add synonyms for two gtp commands in GNU Go 2.7.248. I don't want to remove the old names but I prefer the name "captures" to "prisoners" and "new_score" should be called "estimate_score". Dan

4 4

Random thoughts
by Gunnar Farneb�ck 05 Aug '01

05 Aug '01

Here's an unstructured list of some things that need to be addressed in a standards document. More will follow later. 1. Private extensions. Obviously the protocol is easy to extend just by adding new commands. To bring some order I suggest the following: Standard commands are limited to use the characters [a-z_0-9] and must start with a character in [a-z], i.e. only lower case English letters, underscore, and digits, starting with a lower case letter. Private commands are limited to the same characters plus hyphen and are suggested to be of the form "x-y" where "x" is a program specific prefix, e.g. gg for GNU Go and "y" is the rest of the command name. One example of a private command could be "gg-owl_attack". I don't think we need to keep any official list of prefixes. These commands should be program-specific anyway. 2. Newline conventions That different systems tend to use different newline conventions is a problem that must be addressed by the standard. Personally I prefer the unix convention of a single LF but it probably would invite problems not to accept the presence of CR. My proposal is that all occurences of CR are simply ignored and that an LF defines a newline. This would work with systems using only LF or CRLF but obviously not with systems using only CR. Would this be a (significant) problem? Are there any better solutions? I'd really appreciate input on this point. 3. Case sensitivity Should the protocol in general be case sensitive or not? 4. Unknown command versus unimplemented command. I don't think it's useful to distinguish between unknown commands and unimplemented commands. Thus a program should respond with "?[id] unknown command" to everything it doesn't recognize or knows it can't handle. Currently GNU Go does like this: | 1 fds | ?1 unknown command: 'fds' I think we should skip everything following "unknown command". /Gunnar

3 2

Re: computer-go: gnugoclient 2.0
by Gunnar Farneb�ck 05 Aug '01

05 Aug '01

Don wrote: > And even if an engine doesn't keep track of the moves, > the driving program could use gtp commands to reset the > state and replay the moves..? > > It's my opinion that this would be poor engineering, a bad way to > implement takeback. This absolutely requires something in the minimal > protocol a lot more complicated that "undo." I'm really against the > idea of requiring a GUI to perform this complicated operation in order > to trick a program into taking back a move. No, this doesn't require anything extra in the protocol, only that the GUI keeps tracks of the moves that have been made. The "black" and "white" commands suffice to set up a position. > Also, some programs will lose important state if the position is just > reset as if it's from a completely different game. Even though this > can be preserved by making the engine more complicated, it's a pretty > ugly hack and the goal is to simplify the engine, not complicate it. > And what if the engine is keeping a log of the game? Is it to view > this a brand new position? This on the other hand is a valid point. My opinion is that the first revision of the GTP needs to be split into one minimal set, containing the absolutely necessary (*) commands for making it useful for tournament kind of use, and an extended set with useful but less critical commands that would be good to standardize early. Undo doesn't get into the first group but well into the second. This message is cross-posted to the computer-go, gnugo, and gtp lists. From now on I will continue discussion about gtp only on the latter list. Those who want to take part in this should subscribe to the gtp list, see http://lists.lysator.liu.se/mailman/listinfo/gtp It's also possible to follow the discussion through the list archive, available from the same page. Currently the list is configured to allow posting from non-members, but this may change later (i.e. if necessary for spam reasons). /Gunnar (*) Plus some completely trivial ones like name and version.

2 1

Re: [gtp] Re: computer-go: gnugoclient 2.0
by Gunnar Farneb�ck 05 Aug '01

05 Aug '01

> I agree there should be an "undo", or as I call it, a "takeback" command. At > worse, the GTP (server) can respond with an "not implemented" error message. Undo is the better name. > Also, we need a way to determine if a command is implemented. I was thinking > that a command prefixed by a question mark, like "[id] ?[command]" would > return either a successful response "=" if implemented, otherwise a "?" if > not. No need for such special cases. This could easily be implemented within the standard syntax with a command "is_implemented" taking a command name as argument. But I think a better solution is to have a command "known_commands" which would return a list of all the known commands, just like the GNU Go "help" command works. > I also think it would be valuable to define a way to pass back error and > status codes, and not just a success or failure and an results or error > messages. We could implement this as an optional field; a number before the > result or error message, prefixed with a colon. I was thinking the the > response format could be: "=[id] [status code]: [result]" or "?[id] [error > code]: [error message]". I have not put too much thought into this, so > feedback would be helpful. Keep the protocol simple! Unless someone can convince me that this really is necessary I'm strongly against it. /Gunnar

1 0

Re: computer-go: gnugoclient 2.0
by Phil 05 Aug '01

05 Aug '01

I agree there should be an "undo", or as I call it, a "takeback" command. At worse, the GTP (server) can respond with an "not implemented" error message. Also, we need a way to determine if a command is implemented. I was thinking that a command prefixed by a question mark, like "[id] ?[command]" would return either a successful response "=" if implemented, otherwise a "?" if not. I also think it would be valuable to define a way to pass back error and status codes, and not just a success or failure and an results or error messages. We could implement this as an optional field; a number before the result or error message, prefixed with a colon. I was thinking the the response format could be: "=[id] [status code]: [result]" or "?[id] [error code]: [error message]". I have not put too much thought into this, so feedback would be helpful. Phil ----- Original Message ----- From: "Heikki Levanto" <heikki(a)lsd.dk> To: <computer-go(a)lists.uoregon.edu> Sent: Friday, August 03, 2001 10:18 PM Subject: Re: computer-go: gnugoclient 2.0 > On Fri, Aug 03, 2001 at 05:03:14PM -0400, Don Dailey wrote: > > Whether a program has "undo" or not isn't really a big deal. But in > > my opinion the real issue is getting this very basic feature > > documented right away. > > A standard is complete not when there is nothing to add, but when there is > nothing to remove! > > I do agree that it is important to specify the behaviour of the undo command > now, to avoid different implementations. But I also agree that the command > is of limited use, probably only in human-computer games, which is but one > use for the protocol. Thus I do not agree that "undo" must belong to the > minimal set of commands all programs must implement. > > Therefore I propose to add another set of commands, that are recommended but > not required. Currently this command would contain the undo command only, > but I can imagine we might want to add stuff later, for example time > controls, ruleset details, and what not. > > > Other recommendations for the standard. Discuss and discard at will. > - Three possible error responses: > - Unknown command > - Not implemented (like undo above) > - Parameter error (like playing outside the board) > - Naming convention for commands that are specific for debugging one > program, for example prefix by program name or abbreviation > (gg_owl_defend). Should we keep an "official" list of those prefixes? > > > Heikki > leaving for off-line vacation for a week > > -- > Heikki Levanto LSD - Levanto Software Development <heikki(a)lsd.dk> >

2 1

Test
by Gunnar Farneb�ck 03 Aug '01

03 Aug '01

Obligatory test to see whether the list is working and in particular whether the archive will be automatically created. /Gunnar

1 0

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 August 2001