Currently, at least with GNU Go there doesn't seem to be any way to get the engine's opinion about boardsize, komi, etc.
Normally the gtp controller will know these before the engine does but there is an exception after the command loadsgf is executed.
Because of this exception, there should be a way of getting the boardsize from the engine.
Actually there should be a way of getting the whole position from the engine but for my purposes just getting the boardsize will be enough.
There seem to be two obvious ways of doing this:
(1) allow the command 'boardsize' without arguments. The gtp response is to return the boardsize without setting it.
(2) a new command query_boardsize with obvious functionality:
loadsgf games/nicklas/nicklas9.sgf = black
query_boardsize = 9
I've patched GNU Go 3.1.2 to add this command (because I need it) but I wonder if this is something that is likely to become part of the protocol or not.
Dan
Dan wrote:
Normally the gtp controller will know these before the engine does but there is an exception after the command loadsgf is executed.
Because of this exception, there should be a way of getting the boardsize from the engine.
Actually there should be a way of getting the whole position from the engine
This already exists in GNU Go.
but for my purposes just getting the boardsize will be enough.
There seem to be two obvious ways of doing this:
(1) allow the command 'boardsize' without arguments. The gtp response is to return the boardsize without setting it.
(2) a new command query_boardsize with obvious functionality:
loadsgf games/nicklas/nicklas9.sgf = black
query_boardsize = 9
I've patched GNU Go 3.1.2 to add this command (because I need it) but I wonder if this is something that is likely to become part of the protocol or not.
In principle there's no need for a loadsgf command since the controller could read the sgf file and feed the moves to the engine. Then it would also have full knowledge of board size and other information. On the other hand, the experience from the GNU Go regression system clearly shows that loadsgf is worth having and then, as you say, some query commands are needed (at least boardsize and komi).
Those would also be useful for testing purposes, so they should be included in the protocol, although not part of the tournament subset.
In the choice between 'boardsize' without argument and 'query_boardsize', I definitely prefer the latter.
/Gunnar
Gunnar wrote:
Actually there should be a way of getting the whole position from the engine
This already exists in GNU Go.
How? Not through showboard, which writes its output to stderr and is therefore invisible to the controller.
A perusal of the commands listed by help doesn't show anything else that you could be referring to.
In principle there's no need for a loadsgf command since the controller could read the sgf file and feed the moves to the engine. Then it would also have full knowledge of board size and other information. On the other hand, the experience from the GNU Go regression system clearly shows that loadsgf is worth having and then, as you say, some query commands are needed (at least boardsize and komi).
This presumes that the controller has access to the same files as the engine.
In the choice between 'boardsize' without argument and 'query_boardsize', I definitely prefer the latter.
That's my opinion too. Such a command is added in the patch metamachine_1_3.1 currently up at the development page.
Metamachine is a program that sits between a GTP client and a GTP engine, passing commands back and forth and modifying them in some cases.
To the client it appears to be a GTP engine.
stdin pipe a GTP client ----> metamachine -----> GTP engine <---- <----- stdout pipe b
Most commands are passed verbatim to the engine. The exception is gg_genmove, which is intercepted then processed differently. The top two moves are both tried, the position evaluated by estimate_score, and the move yielding the higher score is selected. Usage: no arguments gives normal GTP behavior. 'metamachine --debug' sends diagnostics to stderr.
Unfortunately this program does not work with twogtp for reasons that are mysterious to me. The requisite processes get spawned then swiftly and suddenly vanish away, to never be heard from again.
But it does work with the regressions (and does poorly on them, at least for the time being).
Dan
-
Daniel Bump -
Gunnar Farneb�ck