[computer-go] A thought about Bot-server communications
Nick Wedd
position. I can always find out what it is by looking at the client
window on my screen.
When a bot plays on a Go server, it does remember the position. This is
something that programs are good at, so it seems reasonable to require
them to do it.
But there can be, very rarely, circumstances where a bot would like to
ask the server "what is the current board position?". Here are some
examples.
(1) My bot's opponent has just made a suicide move. My bot does
not realise that, under the ruleset we are using, suicide is permitted.
Therefore its board-update routine fails. It knows that its opponent
has moved, and it knows that it does not know the current position. It
would like to ask the server to send the current position.
(2) As (1), but with a move that my bot thinks, wrongly, is
forbidden by superko.
(3) My bot, or the platform on which it is running, has had a
serious accident. I have relaunched my bot and it wants to resume its
game but has no knowledge of the position.
If my understanding of the GTP spec at
http://www.lysator.liu.se/~gunnar/gtp/gtp2-spec-draft2/gtp2-spec.html is
correct, it is not possible for a bot to say "please tell me the
position". Should it be possible?
A similar question applies to time. When I play in a tournament, I am
allowed to look at my clock to find out how much time I have left. I am
surprised to find that GTP provides no way for a bot to ask this. (Maybe
I am misunderstanding the spec. I see that there are commands
'time_settings' and 'time-left' that the server can use to inform the
bot of its remaining time, but I can find no indication of when, if
ever, these commands will be issued.)
Nick
--
Nick Wedd ni...@maproom.co.uk
_______________________________________________
computer-go mailing list
compu...@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Jason House
There's typically work-arounds that we use to overcome this.
On kgs, to inform the players, the version command is typically made very long to provide instructions. Similarly, kgsGtp's config supports a few lines of text to print at key points in the game. I don't know if it's possible to get kgs to display all of them.
time_left is at the whim of the server. KGS and CGOS both provide it prior to every move (even when replaying a game). Neither provide the opponent's time left, which could be useful.
A flat picture of the board erases super ko details. kgsGtp does support replaying the entire game from the beginning (such as when the bot does not support undo). I agree, however, that your additional functionality could be useful.
Don Dailey
Nick Wedd wrote:
> When I play Go on a Go server, I do not try to remember the board
> position. I can always find out what it is by looking at the client
> window on my screen.
>
> When a bot plays on a Go server, it does remember the position. This
> is something that programs are good at, so it seems reasonable to
> require them to do it.
>
> But there can be, very rarely, circumstances where a bot would like to
> ask the server "what is the current board position?". Here are some
> examples.
> (1) My bot's opponent has just made a suicide move. My bot does
> not realise that, under the ruleset we are using, suicide is
> permitted. Therefore its board-update routine fails. It knows that
> its opponent has moved, and it knows that it does not know the current
> position. It would like to ask the server to send the current position.
> (2) As (1), but with a move that my bot thinks, wrongly, is
> forbidden by superko.
> (3) My bot, or the platform on which it is running, has had a
> serious accident. I have relaunched my bot and it wants to resume its
> game but has no knowledge of the position.
>
> If my understanding of the GTP spec at
> http://www.lysator.liu.se/~gunnar/gtp/gtp2-spec-draft2/gtp2-spec.html
> is correct, it is not possible for a bot to say "please tell me the
> position". Should it be possible?
>
Hi Nick,
Of course with GTP the engine can never take the initiative to
communicate with a controller due to the asynchronous nature of GTP.
This keeps things simple but has some drawbacks.
UCI deals with this by always sending the position. A UCI program
does not need to track the state of the game since the controller does
it. For example UCI sends the whole game via a list of moves before it
gives the command to search a position. But even a UCI-like go
protocol wouldn't solve the issue you are talking about unless the rule
was to accept any kind of KO or suicide as a legal move for purposes of
setting up board state. I think UCI also has a setup mode.
I don't know how you would make a GTP compatible command because of the
asynchronous nature of GTP other than having it be initiated by the
controller. I suggest that such a command should send a list of
moves (not a board image) because you can construct a proper board state
from a list of moves for any rule-set - but you cannot do this with a
board image.
In computer chess there is a standard way to record a board position,
but it is flawed. It's still very useful and heavily used. The same
format could be used for GO with the same exact drawback. In chess it
looks like this:
r2q1rk1/p3b1pp/2p5/1pn5/1n1Bp1b1/1P6/PQ1PPP2/2RNKBNR b K -
If we did this for GO, the opening position in 9x9 go might be
represented like this:
9/9/9/9/9/9/9/9/9 b -
The hyphen at the end would be ko point - it might be 'e5' if it is now
illegal to capture e5 due to simple ko, otherwise it is a hyphen
placeholder. This represents black to move from the opening position
with no simply ko capture possible.
Digits represent sequences of empty intersections and we scan them 1 row
at a time starting with the A9-J9 row (the top row in a digram view.)
Slashes separate rows but this is not technically needed if we want to
save a few bytes (but it makes it more readable.)
On 19x19 boards we have a problem because we cannot represent 19 empty
spaces with a single digit character. Even if we use hex digits we are
limited to 15 distinct digits or 16 if we change the meaning of
zero. Even if we use hex digits we have to decide what represents
white and black stones. We can of course extend the hex system with
additional letters. Or we can ignore the problem and use 2 digits to
make up the difference. If we do that, I suggest the 0 digit is used
to extend the alphabet and it simply means 10. If there are 10 or more
we insist on using 0 first, then an addition digit just to be
consistent. So the opening position in 19x19 might look like this:
09/09/09/09/09/09/09/09/09/09/09/09/09/09/09/09/09/09/09 b -
Although 2 digits is wasteful, much of this goes away once the positions
become complicated.
The next issue is how to represent stones. In chess white pieces are
represented with upper-case characters and black pieces are represented
with lower case letters. If we follow that conventions we might pick
an arbitrary letter of the alphabet to represent a stone and use
upper/lower case to determine - or we could just choose "w" and "b" to
mean white/black stone. I prefer "w" and "b".
You might think positions look a little cryptic with this notation, but
in my opinion the real value of fen notation is that you can physically
type in a board position in just seconds. In chess, you basically scan
the board and type the piece and digits as you scan. If there are 3
empty squares you just type 3 and you are done.
In fact, this whole notation is based on what was done way before
computers came along to quickly record chess positions on paper when
games are adjourned. It was invented by David Forsyth and it was
called not suprisingly "Forsyth notation." FEN notation is short for
"Forsyth Edwards Notation" because Steven Edwards modifed it slightly
for computer notation. You can record a chess position on paper in
about 10-15 seconds and by keyboard using FEN notation in about 5
seconds.
The question comes up: Is it really practical for go? I cannot
answer that. In the old days before computers, were games adjourned
and restarted at later times? How was the position preserved? Did
someone draw a diagram on a piece of paper? Or did they just replay
the game?
Although even in chess we use graphical tools now to set up positions,
it's still much faster to create a fen diagram with a text editor.
This is for the same reason that "real programmers" are command line
junkies - command line interface is almost always the better and faster
way to do things that do not directly involve graphics or complex
interactions where visual cues make a lot of difference. Admittedly,
it would be more error prone with GO as the board is bigger and more
complicated and you can see at a glance how many empty squares there are
on a chess board without barely a thought but it's not quite as trivial
in Go. It's still probably faster using something like FEN in GO,
but I think creating positions manually in GO is done far less often
simply because it's more painful no matter how you do it.
Before I go too much farther - is there already a commonly accepted
simple and user friendly way to actually record a board position on
paper that is roughly equivalent to FEN?
FEN has similar characteristics to RLE (run length encoding) where
sequences of the same "digits" are stored as a single data value with a
count. It's much more common in GO to have long sequences of the same
piece type (several white or black stones on the same row.) So we could
encode a position in a very straightforward way with a different scheme
- there are 3 kinds of intersections in GO, white/black/empty. So we
could encode the type and count in pairs perhaps in the same scan order
as in FEN. For readability we should probably stop at the end of each
row and thus have something like this:
e2bweweb3/b4w2beb/ew2b2w2b2/e2bebw2be/b4w3be/w2bwewb2e/wewew3be/ew2e2wb2e/e5w2be
b -
I typed this in from one of the 9x9 cgos games and it went pretty fast -
and would be very fast with some practice. Here is how it works:
e - empty
b - black stone
w - white stone
For each row, I type in the type and number of them. If there is
only 1, I ignore the count. If you ignore the slash separator between
rows, this is guaranteed to be at least as compact as if you layed them
out 1 character at a time.
You could of course ignore the separate line separates and get very high
compression ratio's in some types of positions. the opening 19x19
board would look like this:
"e381 b -"
Of course you could take such a representation and apply huffman
encoding and such - but it would be interesting to find a very
compressible system that only required the use of ascii printable
symbols and was not unduly difficult to decode and encode.
Of course I have not researched this - perhaps such things have already
been discussed or even created.
- Don
> A similar question applies to time. When I play in a tournament, I am
> allowed to look at my clock to find out how much time I have left. I
> am surprised to find that GTP provides no way for a bot to ask this.
> (Maybe I am misunderstanding the spec. I see that there are commands
> 'time_settings' and 'time-left' that the server can use to inform the
> bot of its remaining time, but I can find no indication of when, if
> ever, these commands will be issued.)
>
> Nick
Don Dailey
the complete state of the game. It records en-passant information and
color to move, but it's does not capture position history so you
cannot detect draws due to positional repetition.
In GO, this is probably a more serious problem.
- Don
Álvaro Begué
I forgot mention why FEN is flawed. It's because it fails to capture
the complete state of the game. It records en-passant information and
color to move, but it's does not capture position history so you
cannot detect draws due to positional repetition.
In GO, this is probably a more serious problem.
Álvaro.
Erik van der Werf
> > In GO, this is probably a more serious problem.
> Yes, there is no such thing as an irreversible move in go.
Well there is the opening move... (unless suicide is legal you can
never recreate the empty board).
> I think we are
> stuck with sending the whole list of moves every time we want to describe
> the current state of the game.
Or simply don't use superko. Normal rules work fine with only some
minimal knowledge of the last move. Long cycles are not an issue
because they may repeat multiple times without altering the inevitable
outcome (which, e.g., can be decided on the server side after n-fold
repetition).
Erik
Álvaro Begué
On Dec 10, 2007 4:35 PM, Álvaro Begué <alvaro...@gmail.com> wrote:Well there is the opening move... (unless suicide is legal you can
> > In GO, this is probably a more serious problem.
> Yes, there is no such thing as an irreversible move in go.
never recreate the empty board).
Or simply don't use superko. Normal rules work fine with only some
> I think we are
> stuck with sending the whole list of moves every time we want to describe
> the current state of the game.
minimal knowledge of the last move. Long cycles are not an issue
because they may repeat multiple times without altering the inevitable
outcome (which, e.g., can be decided on the server side after n-fold
repetition).
It is not my intention to sound confrontational. I really don't know how other rule sets deal with tricky situations.
Don Dailey
But none of this is any good for a general solution (a simple text based position notation.)
We could talk about systems for compressing move lists of course but there is probably no simple text based system that will give you anything amazing.
Here is an interesting domain specific scheme (that is not text based):
1. Build a deterministic engine that is good at prediction moves of strong players.
2. The engine ranks all playable moves in a deterministic way.
3. A huffman-like encoding is used where the most popular moves take the least number of bits.
If the prediction rate is high, the number of bits per move might be quite low.
- Don
Álvaro Begué wrote:
Nick Wedd
<7b0793ea0712100823g542...@mail.gmail.com>, Álvaro
Begué <alvaro...@gmail.com> writes
>It is not my intention to sound confrontational. I really don't know
>how other rule sets deal with tricky situations.
For long-cycle repetitions:
Japanese: A repetition lead to "no result". The game is replayed.
Chinese: A player may not repeat a previous board position and
when he does the game counts as half a win to each
player. (KGS interprets this as Positional Superko.)
Ing/SST: Some repetitions are forbidden by the SST ko rule, which
very few people understand.
AGA: Positional Superko
Tromp-Taylor: Positional Superko
NZ: Situational Superko
France: Natural Situational Superko
Suicide is permitted by Ing/SST, Tromp-Taylor and NZ rules, and
forbidden by the others listed above.
Nick
--
Nick Wedd ni...@maproom.co.uk
Álvaro Begué
Of course if only simple KO is used, then repetition is not an issue - you only have to store the simple ko state fen style.
But none of this is any good for a general solution (a simple text based position notation.)
We could talk about systems for compressing move lists of course but there is probably no simple text based system that will give you anything amazing.
Here is an interesting domain specific scheme (that is not text based):
1. Build a deterministic engine that is good at prediction moves of strong players.
2. The engine ranks all playable moves in a deterministic way.
3. A huffman-like encoding is used where the most popular moves take the least number of bits.
If the prediction rate is high, the number of bits per move might be quite low.
I don't think this is domain specific at all. It's just a very general way in which compression algorithms work: predict the next symbol (as a probability distribution), and encode it using a number of bits close to -log2(probability).
By the way, finding a probability distribution that results in good compression using this scheme is basically what Remi did with CrazyStone.
Álvaro.
Robert Jasiek
> Chinese: A player may not repeat a previous board position and
> when he does the game counts as half a win to each
> player.
According to influentual Chinese professionals, the superko rule is a
fake overridden by the referee ko rules section. Or: pos. superko
applies to sending-2-returning-1 shapes only.
> Ing/SST: Some repetitions are forbidden by the SST ko rule, which
> very few people understand.
Fewer than 1 :)
> AGA: Positional Superko
According to most interpretors: Situational Superko.
According to Terry Benson: Natural Situational Superko
--
robert jasiek
Álvaro Begué
In message
<7b0793ea0712100823g542...@mail.gmail.com>, Álvaro
Begué < alvaro...@gmail.com> writesFor long-cycle repetitions:
>It is not my intention to sound confrontational. I really don't know
>how other rule sets deal with tricky situations.
Japanese: A repetition lead to "no result". The game is replayed.
Chinese: A player may not repeat a previous board position and
when he does the game counts as half a win to each
player. (KGS interprets this as Positional Superko.)
Ing/SST: Some repetitions are forbidden by the SST ko rule, which
very few people understand.
AGA: Positional Superko
Tromp-Taylor: Positional Superko
NZ: Situational Superko
France: Natural Situational Superko
Suicide is permitted by Ing/SST, Tromp-Taylor and NZ rules, and
forbidden by the others listed above.
Thanks for the brief summary of all these rulesets!
Álvaro.
Erik van der Werf
> On Dec 10, 2007 11:05 AM, Erik van der Werf <erikvan...@gmail.com>
> > minimal knowledge of the last move. Long cycles are not an issue
> > because they may repeat multiple times without altering the inevitable
> > outcome (which, e.g., can be decided on the server side after n-fold
> > repetition).
> I am not sure what you mean by "normal rules".
Most human players I know use informal Japanese rules (so this is what
is normal for me, and probably most players in the Netherlands). OC
formalizing them is non-trivial, but certainly not impossible. In
practice w.r.t. long-cycles these rules are in pretty good agreement
with traditional Asian rules (Chinese/Japanese).
> Are three kos a draw? What
> about other long cycles?
To formalize this in the following I assume repetitions are always on
even plies (so the player to move must be the same).
For long cycles (anything greater than two moves) you need to
distinguish between the following 3 types:
1) Winning cycle: Each cycle you gain prisoners. (or equivalently, you
pass more, underlining your intent not to continue the cycle)
2) Balanced cycle: both sides capture the same number of opponent stones.
3) Losing cycle: Each cycle you loose prisoners. (or equivalently, you
pass less, underlining your malicious intent to prevent a normal
game-end)
The outcome, to be determined after one or possibly more than one
cycle, is (1) win, (2) draw, or (3) loss.
> It is not my intention to sound confrontational. I really don't know how
> other rule sets deal with tricky situations.
No problem.
Nick Wedd
writes
>Nick Wedd wrote:
>> Chinese: A player may not repeat a previous board position and
>> when he does the game counts as half a win to each
>> player.
>
>According to influentual Chinese professionals, the superko rule is a
>fake overridden by the referee ko rules section. Or: pos. superko
>applies to sending-2-returning-1 shapes only.
>
>> Ing/SST: Some repetitions are forbidden by the SST ko rule, which
>> very few people understand.
>
>Fewer than 1 :)
>
>> AGA: Positional Superko
>
>According to most interpretors: Situational Superko.
Yes, my mistake, Robert is right here.
>According to Terry Benson: Natural Situational Superko
Nick
--
Nick Wedd ni...@maproom.co.uk
Erik van der Werf
> It looks like even under non-superko rules, something special happens if a
> position is repeated, which means that a program should know the entire
> history of the game, or it may accidentally repeat a previous position, even
> if it is winning the game by a large margin.
Yes, but my point was that this special thing does not necessarily
have to happen directly.
If both sides have played the full cycle at least once then they have
had every opportunity needed for analysis and for playing elsewhere.
If neither side chooses to abandon the cycle (and look-ahead can show
there is a cycle anywhere in the cycle!) then there is no need to play
forever and the server (referee) can simply decide the result based on
a long-cycle analysis.
Erik
Don Dailey
Erik van der Werf wrote:
> On Dec 10, 2007 6:07 PM, Álvaro Begué <alvaro...@gmail.com> wrote:
>
>> It looks like even under non-superko rules, something special happens if a
>> position is repeated, which means that a program should know the entire
>> history of the game, or it may accidentally repeat a previous position, even
>> if it is winning the game by a large margin.
>>
>
> Yes, but my point was that this special thing does not necessarily
> have to happen directly.
>
> If both sides have played the full cycle at least once then they have
> had every opportunity needed for analysis and for playing elsewhere.
> If neither side chooses to abandon the cycle (and look-ahead can show
> there is a cycle anywhere in the cycle!) then there is no need to play
> forever and the server (referee) can simply decide the result based on
> a long-cycle analysis.
>
>
This is exactly how it's used in chess. In both games a repetition can
be "game changing", leading to a draw in chess or an illegal move (or
loss) in Go. But when use to record positions it is assumed that
nothing relevant is behind you. Even if it is, the game isn't
fundamentally changed. In chess you are given 3 repeats before a draw
can be claimed so one could just view this a a couple more chances.
Same in Go.
There is an important difference in chess. In chess, it's not illegal
to repeat the same position even hundreds of times. A draw MUST be
claimed by the player who is about to repeat the position. If he fails
to claim the draw, the opponent may have the opportunity to claim the
draw (when it is his move) but neither player is absolutely obligated
to claim it.
In Go however, even if the fundamental game is unchanged you may be
playing illegal moves if you are not aware of the superko situation.
Such a system is perfectly fine for recording interesting positions such
as test suites and such.
- Don
Dave Dyer
Arguing whether method "A" or method "B" rates a program more
correctly is really close to arguing how many angels can dance
on the head of a Pin. Ratings, at best, are based on mathematical
models with many simplifying assumptions. Ratings are not reality.
steve uurtamo
i think that we can probably say that a rating system
for, say, 19x19 go with komi relative to handicap and
time controls roughly the same for each contest (or not,
you choose!) is anything that turns a set of:
(p1,p2,h,t,r) [player 1, player 2, handicap, time, result]
5-tuples
into a set of:
(p1,k) [player 1, rank]
2-tuples, where rank might be some function as opposed
to a constant.
which preserves some minimal assumptions about how
the p_i's should be ordered. (a universally accepted set
of such assumptions is hard to state, which is why
disagreement about ranking systems exists at all).
which is a pretty gigantic set of functions.
however, one particularly nice way of looking at ranking
is that it would be nice if two different players' ranks could
be used to predict the probability that one or the other of them
would win a contest between them if it were to take place right now.
minimizing the error in such a model gives a pretty sweet
(in the sense of usefulness for calculating stone difference, for
instance) ranking system.
s.
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
steve uurtamo
i should have said that i mean "time" here to be the
actual date/time that the contest occurred, since skill
can (and often does) change over time.
also the p1,p2 should be taken to be ordered, so that we
know who was black and who was white.
Don Dailey
Dave Dyer wrote:
> Arguing whether method "A" or method "B" rates a program more
> correctly is really close to arguing how many angels can dance
> on the head of a Pin. Ratings, at best, are based on mathematical
> models with many simplifying assumptions. Ratings are not reality.
>
Nobody really believes ratings are 100% "right on the money" accurate.
But it's silly not to use the most correct method possible. Ratings
are "a very useful approximation to reality" and you might as well get
as close to that reality as you can.
- Don
Edward de Grijs
> Nobody really believes ratings are 100% "right on the money" accurate.
>
> But it's silly not to use the most correct method possible. Ratings
> are "a very useful approximation to reality" and you might as well get
> as close to that reality as you can.
>
>
> - Don
(nr of cpu and speed of cpu's) into account.
This has a major influence on UCT/MC programs.
Otherwise we only test the package of progam+computer together
and not the progam alone.
Speed differences of more then 10 exists in the rating pool...
--Edward
Windows Live Mail: Nu 2gb aan opslag - dat zijn maar liefst 1000 foto's - en nog steeds gratis! Windows Live Mail
Ian Osgood
On Dec 10, 2007, at 11:53 AM, Edward de Grijs wrote:
>
>
> > Nobody really believes ratings are 100% "right on the money"
> accurate.
> >
> > But it's silly not to use the most correct method possible. Ratings
> > are "a very useful approximation to reality" and you might as
> well get
> > as close to that reality as you can.
> >
> >
> > - Don
>
> But then we have to take the amount of computing power
> (nr of cpu and speed of cpu's) into account.
> This has a major influence on UCT/MC programs.
> Otherwise we only test the package of progam+computer together
> and not the progam alone.
> Speed differences of more then 10 exists in the rating pool...
>
> --Edward
In the many chess computer rating lists, the entities in the list are
determined by:
1) Program, including version and settings (e.g. standard vs. hyper-
modern)
2) Platform, including processor, clock speed, number of cores, and
amount of memory devoted to transposition tables
Sometimes the entities are even distinguished by which opening book
or endgame database is in use.
Ian
Gunnar Farnebäck
> When I play Go on a Go server, I do not try to remember the board
> position. I can always find out what it is by looking at the client
> window on my screen.
>
> When a bot plays on a Go server, it does remember the position. This is
> something that programs are good at, so it seems reasonable to require
> them to do it.
>
> But there can be, very rarely, circumstances where a bot would like to
> ask the server "what is the current board position?". Here are some
> examples.
> (1) My bot's opponent has just made a suicide move. My bot does
> not realise that, under the ruleset we are using, suicide is permitted.
> Therefore its board-update routine fails. It knows that its opponent
> has moved, and it knows that it does not know the current position. It
> would like to ask the server to send the current position.
Sorry, but I can't take this seriously. If your board update routine
fails, just fix it. As long as you trust the controller to send legal
moves, it's well defined how the board will look. The same board
update logic can be used for all rulesets. If you don't agree about
the legality, complain in a logfile. If you don't trust the controller
to send legal moves, you have a problem that is hardly properly solved
by asking it for a different board state description.
> (2) As (1), but with a move that my bot thinks, wrongly, is
> forbidden by superko.
Same as (1).
> (3) My bot, or the platform on which it is running, has had a
> serious accident. I have relaunched my bot and it wants to resume its
> game but has no knowledge of the position.
It's standard practice for the controller to send "play" commands up
to the point of resumption. If the engine has to be restarted the
controller knows that it has lost state, there's no need for the
engine to ask. KgsGtp knows how to do this, the CGOS client knows how
to do this.
> If my understanding of the GTP spec at
> http://www.lysator.liu.se/~gunnar/gtp/gtp2-spec-draft2/gtp2-spec.html is
> correct, it is not possible for a bot to say "please tell me the
> position". Should it be possible?
No it shouldn't. GTP is designed to make it easy for engine authors to
implement what the engine needs to play a game. For a go server
protocol it can be useful to have methods to negotiate komi, negotiate
opponents, ask the server all kinds of questions, and so on, but this
is out of scope for GTP.
> A similar question applies to time. When I play in a tournament, I am
> allowed to look at my clock to find out how much time I have left. I am
> surprised to find that GTP provides no way for a bot to ask this. (Maybe
> I am misunderstanding the spec. I see that there are commands
> 'time_settings' and 'time-left' that the server can use to inform the
> bot of its remaining time, but I can find no indication of when, if
> ever, these commands will be issued.)
For a game with time controls the controller is expected to send
time_left commands once per move to keep the engine informed about the
time situation. While thinking on a move the engine is expected to
keep track of time by itself.
By the way, if this has anything to do with KGS, the real problem
there is that people who want to do advanced things with bots cannot
modify kgsGtp, nor speak the server protocol themselves, since those
are both proprietary.
And just to be clear, the normal mode of communication between a bot
and a server, if GTP is involved, is
Server <---server protocol---> Client <---GTP---> Engine
The server protocol and GTP have very different roles, capabilities,
and complexities. In some cases the server protocol can be near GTP in
complexity (CGOS), in some cases the server protocol is not available
(KGS), and in some cases the server protocol can be hugely complex
(IGS and NNGS clones). For the best result the client should have open
code and be very configurable.
/Gunnar
Don Dailey
We usually associate playing strength directly with the software, but
it's clear that this is not really correct. We have to consider the
whole game playing system, the machine or machines it runs on as well
as the software. CGOS doesn't really distinguish this.
To truly evaluation software you have to run on the same platform but
this is not practical either for things like CGOS, although tournaments
can be organized around this idea.
It was painfully obvious in chess. Even from the early day of computer
chess then well funded companies would come to big tournaments with big
hardware. I remember the "fidelity" machines. They were never
the machines you could buy at stores but often were "thick" because they
had cooling gadgets so that they could run seriously over-clocked.
When such a gadget won a tournament, it was never advertised what it
run on. The ad would say something like "The program that won the
microcomputer chess championship can be yours!"
- Don
Edward de Grijs wrote:
>
>
> > Nobody really believes ratings are 100% "right on the money" accurate.
> >
> > But it's silly not to use the most correct method possible. Ratings
> > are "a very useful approximation to reality" and you might as well get
> > as close to that reality as you can.
> >
> >
> > - Don
>
> But then we have to take the amount of computing power
> (nr of cpu and speed of cpu's) into account.
> This has a major influence on UCT/MC programs.
> Otherwise we only test the package of progam+computer together
> and not the progam alone.
> Speed differences of more then 10 exists in the rating pool...
>
> --Edward
>
>
>
>
>
> ------------------------------------------------------------------------
> Windows Live Mail: Nu 2gb aan opslag - dat zijn maar liefst 1000
> foto's - en nog steeds gratis! Windows Live Mail
> <http://imagine-windowslive.com/mail/launch/default.aspx?Locale=nl-nl%29>
> ------------------------------------------------------------------------
Nick Wedd
<gun...@lysator.liu.se> writes
>Nick Wedd wrote:
>> When I play Go on a Go server, I do not try to remember the board
>> position. I can always find out what it is by looking at the client
>> window on my screen.
>>
>> When a bot plays on a Go server, it does remember the position. This is
>> something that programs are good at, so it seems reasonable to require
>> them to do it.
>>
>> But there can be, very rarely, circumstances where a bot would like to
>> ask the server "what is the current board position?". Here are some
>> examples.
>> (1) My bot's opponent has just made a suicide move. My bot does
>> not realise that, under the ruleset we are using, suicide is permitted.
>> Therefore its board-update routine fails. It knows that its opponent
>> has moved, and it knows that it does not know the current position. It
>> would like to ask the server to send the current position.
>
>Sorry, but I can't take this seriously. If your board update routine
>fails, just fix it. As long as you trust the controller to send legal
>moves, it's well defined how the board will look. The same board
>update logic can be used for all rulesets. If you don't agree about
>the legality, complain in a logfile. If you don't trust the controller
>to send legal moves, you have a problem that is hardly properly solved
>by asking it for a different board state description.
I agree that the server knows better than me about the legality. I
trust the server to make legal moves. I just might not know how to
update the board state after a move I had not realised was possible.
In 1998, running the Ing Cup, I tested all the entrants for their
behaviour when someone played a suicide move at them. Many Faces put up
a polite dialog box explaining that this was an illegal move. Go++ was
more amusing: it allowed the move (which you would approve) but left
the suicided stones on the board, where they became almost unkillable,
it could not capture them by removing their last liberty as they didn't
have one, the only way to lose them was to capture exactly one of their
surrounding stones, in a perverted kind of snapback. I would have
preferred these programs to have been able to respond "wtf is going on,
please tell me the current board state".
>> (2) As (1), but with a move that my bot thinks, wrongly, is
>> forbidden by superko.
>
>Same as (1).
>
>> (3) My bot, or the platform on which it is running, has had a
>> serious accident. I have relaunched my bot and it wants to resume its
>> game but has no knowledge of the position.
>
>It's standard practice for the controller to send "play" commands up
>to the point of resumption. If the engine has to be restarted the
>controller knows that it has lost state, there's no need for the
>engine to ask. KgsGtp knows how to do this, the CGOS client knows how
>to do this.
It's good to know that.
>> If my understanding of the GTP spec at
>> http://www.lysator.liu.se/~gunnar/gtp/gtp2-spec-draft2/gtp2-spec.html is
>> correct, it is not possible for a bot to say "please tell me the
>> position". Should it be possible?
>
>No it shouldn't. GTP is designed to make it easy for engine authors to
>implement what the engine needs to play a game. For a go server
>protocol it can be useful to have methods to negotiate komi, negotiate
>opponents, ask the server all kinds of questions, and so on, but this
>is out of scope for GTP.
>
>> A similar question applies to time. When I play in a tournament, I am
>> allowed to look at my clock to find out how much time I have left. I am
>> surprised to find that GTP provides no way for a bot to ask this. (Maybe
>> I am misunderstanding the spec. I see that there are commands
>> 'time_settings' and 'time-left' that the server can use to inform the
>> bot of its remaining time, but I can find no indication of when, if
>> ever, these commands will be issued.)
>
>For a game with time controls the controller is expected to send
>time_left commands once per move to keep the engine informed about the
>time situation. While thinking on a move the engine is expected to
>keep track of time by itself.
I see. And that is up to the controller, so it's not mentioned in the
GTP spec.
>By the way, if this has anything to do with KGS, the real problem
>there is that people who want to do advanced things with bots cannot
>modify kgsGtp, nor speak the server protocol themselves, since those
>are both proprietary.
>
>And just to be clear, the normal mode of communication between a bot
>and a server, if GTP is involved, is
>
>Server <---server protocol---> Client <---GTP---> Engine
>The server protocol and GTP have very different roles, capabilities,
>and complexities. In some cases the server protocol can be near GTP in
>complexity (CGOS), in some cases the server protocol is not available
>(KGS), and in some cases the server protocol can be hugely complex
>(IGS and NNGS clones). For the best result the client should have open
>code and be very configurable.
Thank you for the explanations.
Nick
>/Gunnar
>_______________________________________________
>computer-go mailing list
>compu...@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
Nick Wedd ni...@maproom.co.uk
Erik van der Werf
> In Go however, even if the fundamental game is unchanged you may be
> playing illegal moves if you are not aware of the superko situation.
And you think superko is part of the fundamental game???
In my terminology *repetition*, and having some rules to prevent
infinite games, is a fundamental aspect of the game. Superko is not
fundamental.
BTW Several authors here use the words repetition and superko as
synonyms; I believe this is misleading.
Superko refers to a special class of rules for dealing with repetition
(to avoid infinite games).
Superko rules share the property that they declare moves that create
repetition illegal. (They differ only in how they define a
repetition.)
Superko rules always do what they are supposed to do (prevent infinite
games), but sometimes they do a bit more...
E.
Don Dailey
Erik van der Werf wrote:
> On Dec 10, 2007 6:48 PM, Don Dailey <drda...@cox.net> wrote:
>
>> In Go however, even if the fundamental game is unchanged you may be
>> playing illegal moves if you are not aware of the superko situation.
>>
>
> And you think superko is part of the fundamental game???
>
Well, I seem to be saying here that it is NOT part of the fundamental
game. Really, the game is not changed a bit if you start from a
arbitrary position and ignore history but only because you will
presumably play the same moves for the same reasons and once again
encounter the superko situations that you discarded when you stored the
position without the state.
So what I'm stating here has nothing to do with whether superko is a
fundamental part of the game or not.
> In my terminology *repetition*, and having some rules to prevent
> infinite games, is a fundamental aspect of the game. Superko is not
> fundamental.
>
I'm not making an argument either way. It clearly influences the game
but whether it's fundamental or not I'll leave to the philosophers.
> BTW Several authors here use the words repetition and superko as
> synonyms; I believe this is misleading.
>
They are essentially synonyms - I don't see your point. There is some
question about how you define a position (a board state, or a board
configuration i.e. SSK or PSK) but you can nitpick if you want and say
that superko has nothing to do with positions repeating but I think when
a position repeats it's superko.
Are you just trying to nitpick semantics?
- Don
Erik van der Werf
> Erik van der Werf wrote:
> > On Dec 10, 2007 6:48 PM, Don Dailey <drda...@cox.net> wrote:
> >
> >> In Go however, even if the fundamental game is unchanged you may be
> >> playing illegal moves if you are not aware of the superko situation.
> >>
> >
> > And you think superko is part of the fundamental game???
> >
> Well, I seem to be saying here that it is NOT part of the fundamental
> game.
I'm sorry, then I misunderstood what you were trying to say.
> > BTW Several authors here use the words repetition and superko as
> > synonyms; I believe this is misleading.
> >
> They are essentially synonyms - I don't see your point.
I think you've just proven my point ;-)
In my opinion repetition is a more neutral word. It avoids mixing
conditions with consequences.
> There is some
> question about how you define a position (a board state, or a board
> configuration i.e. SSK or PSK) but you can nitpick if you want and say
> that superko has nothing to do with positions repeating but I think when
> a position repeats it's superko.
And when you say it's superko my first thought is that the game is
over because one player just made an illegal move...
> Are you just trying to nitpick semantics?
In a loose informal context this would certainly be nitpicking (e.g.
the difference between 'ko' and 'ko-rule'). However when it is about
formalizing rules it really helps to be precise and minimize ambiguity
(I would think TT-proponents should at least agree with me on this). I
really do think it is important to distinguish clearly between
conditions (what constitutes a repetition) and consequences (direct
loss / continued analysis / no result, etc.).
Erik
Don Dailey
>> There is some
>> question about how you define a position (a board state, or a board
>> configuration i.e. SSK or PSK) but you can nitpick if you want and say
>> that superko has nothing to do with positions repeating but I think when
>> a position repeats it's superko.
>>
>
> And when you say it's superko my first thought is that the game is
> over because one player just made an illegal move...
>
>
>
>> Are you just trying to nitpick semantics?
>>
>
> In a loose informal context this would certainly be nitpicking (e.g.
> the difference between 'ko' and 'ko-rule'). However when it is about
> formalizing rules it really helps to be precise and minimize ambiguity
> (I would think TT-proponents should at least agree with me on this). I
> really do think it is important to distinguish clearly between
> conditions (what constitutes a repetition) and consequences (direct
> loss / continued analysis / no result, etc.).
>
simply forbidden or is it part of the rules that you lose immediately if
you play it? In card games that is called an irregularity and there
are separate rules to deal with these.
If you make some other illegal move what happens? For instance if you
take one the opponents stones and place it on the board? Do you lose
immediately or do you get your hand slapped with the objection that "you
can't make that move, play something real!"
Erik van der Werf
>
> >> There is some
> >> question about how you define a position (a board state, or a board
> >> configuration i.e. SSK or PSK) but you can nitpick if you want and say
> >> that superko has nothing to do with positions repeating but I think when
> >> a position repeats it's superko.
> >>
> >
> > And when you say it's superko my first thought is that the game is
> > over because one player just made an illegal move...
> >
> >
> >
> >> Are you just trying to nitpick semantics?
> >>
> >
> > In a loose informal context this would certainly be nitpicking (e.g.
> > the difference between 'ko' and 'ko-rule'). However when it is about
> > formalizing rules it really helps to be precise and minimize ambiguity
> > (I would think TT-proponents should at least agree with me on this). I
> > really do think it is important to distinguish clearly between
> > conditions (what constitutes a repetition) and consequences (direct
> > loss / continued analysis / no result, etc.).
> >
> Ok, let's get into semantics. Is superko an illegal move?
Again, I regard superko as a concept that refers to a special class of
rules for dealing with repetition.
So no, it is not an illegal move.
> Is it
> simply forbidden or is it part of the rules that you lose immediately if
> you play it? In card games that is called an irregularity and there
> are separate rules to deal with these.
>
> If you make some other illegal move what happens? For instance if you
> take one the opponents stones and place it on the board? Do you lose
> immediately or do you get your hand slapped with the objection that "you
> can't make that move, play something real!"
OC we have general tournament rules and rules for dealing with
unsportsmanships behavior...
However, slapping you on the hand and giving you the option to alter
your move does not fundamentally change anything to the assumed
illegality of a particular move. For optimal play you still had to
play elsewhere, hence for a sufficiently informed player the effect is
the same. Traditional rules (without superko) can have fundamentally
different game outcomes. Social etiquette alone does not suffice to
remove these differences.
The fundamental problem with superko is failure to distinguish between
balanced and unbalanced cycles.
In an unbalanced cycle, such as send-2-return-1, your suggestion "you
can't make that move, play something real!" is fine.
In a balanced cycle, such as triple-ko, this is not the obvious thing to say.
Gunnar Farnebäck
>> Sorry, but I can't take this seriously. If your board update routine
>> fails, just fix it. As long as you trust the controller to send legal
>> moves, it's well defined how the board will look. The same board
>> update logic can be used for all rulesets. If you don't agree about
>> the legality, complain in a logfile. If you don't trust the controller
>> to send legal moves, you have a problem that is hardly properly solved
>> by asking it for a different board state description.
>
> I agree that the server knows better than me about the legality. I
> trust the server to make legal moves. I just might not know how to
> update the board state after a move I had not realised was possible.
>
> In 1998, running the Ing Cup, I tested all the entrants for their
> behaviour when someone played a suicide move at them. Many Faces put up
> a polite dialog box explaining that this was an illegal move. Go++ was
> more amusing: it allowed the move (which you would approve) but left
> the suicided stones on the board, where they became almost unkillable,
> it could not capture them by removing their last liberty as they didn't
> have one, the only way to lose them was to capture exactly one of their
> surrounding stones, in a perverted kind of snapback. I would have
> preferred these programs to have been able to respond "wtf is going on,
> please tell me the current board state".
Well, the thing is that fixing the board update logic should in most
cases be a matter of adding a small number of lines, or in extreme cases
even removing some lines. In terms of programming it's a much bigger
operation to obtain information by external communication and then
trying to recover the internal data structures.
terry mcintyre
They mean to govern well; but they mean to govern. They promise to be kind masters; but they mean to be masters. -- Daniel Webster
Matthew Woodcraft
> Ok, let's get into semantics. Is superko an illegal move? Is it
> simply forbidden or is it part of the rules that you lose immediately if
> you play it? In card games that is called an irregularity and there
> are separate rules to deal with these.
>
> If you make some other illegal move what happens? For instance if you
> take one the opponents stones and place it on the board? Do you lose
> immediately or do you get your hand slapped with the objection that "you
> can't make that move, play something real!"
In serious tournament go the convention is that you lose immediately.
(I haven't heard of a case of someone playing a stone of the wrong colour in
such a tournament, but certainly playing a move forbidden by the ko rule
forfeits the game).
-M-
Nick Wedd
Woodcraft <mat...@woodcraft.me.uk> writes
>Don Dailey wrote:
>> Ok, let's get into semantics. Is superko an illegal move? Is it
>> simply forbidden or is it part of the rules that you lose immediately if
>> you play it? In card games that is called an irregularity and there
>> are separate rules to deal with these.
>>
>> If you make some other illegal move what happens? For instance if you
>> take one the opponents stones and place it on the board? Do you lose
>> immediately or do you get your hand slapped with the objection that "you
>> can't make that move, play something real!"
>
>In serious tournament go the convention is that you lose immediately.
>
>(I haven't heard of a case of someone playing a stone of the wrong colour in
>such a tournament, but certainly playing a move forbidden by the ko rule
>forfeits the game).
It may depend what you mean by "serious tournament".
In one of the British Championship Match games, a bit over ten years
ago, Zhang Shutai made an illegal ko move against Matthew Macfadyen, and
immediately conceded that he had lost the game.
In the "Candidates' Tournament", a preliminary round for the British
Championship, last year. I observed a player play a stone of the wrong
colour. The players had no doubt about the correct action: the stone
was removed from the board and replaced by one of the correct colour.
Nick
--
Nick Wedd ni...@maproom.co.uk
terry mcintyre
of the distinction is this: violating the ko rule flows from an incorrect
decision made by the player; playing a stone of the wrong color from external
mishap - the stone should not have been in the player's bowl. Usually one spots
such a mishap and hands the stone to the opponent, but it's possible to be so
focused on the board that one doesn't actually look at the stone itself until it
has been placed. Hence the two different levels of penalty.
Now, for a computer program, there are no such mitigating circumstances;
if a white stone appears where a black stone ought to be, that's a bug; best to
stomp on it before it wreaks more havoc.
From: Nick Wedd <ni...@maproom.co.uk>
>In serious tournament go the convention is that you lose immediately.
>
>(I haven't heard of a case of someone playing a stone of the wrong colour in
>such a tournament, but certainly playing a move forbidden by the ko rule
>forfeits the game).
It may depend what you mean by "serious tournament".
In one of the British Championship Match games, a bit over ten years
ago, Zhang Shutai made an illegal ko move against Matthew Macfadyen, and
immediately conceded that he had lost the game.
In the "Candidates' Tournament", a preliminary round for the British
Championship, last year. I observed a player play a stone of the wrong
colour. The players had no doubt about the correct action: the stone
was removed from the board and replaced by one of the correct colour.
Jacques Basaldúa
> In one of the British Championship Match games, a bit over ten years
> ago, Zhang Shutai made an illegal ko move against Matthew Macfadyen, and
> immediately conceded that he had lost the game.
Is the game record available? I am interested because I have only found 2
situations in real games:
a. Triple ko
b. Double ko when the group sharing the kos has nothing better than life in seki.
Both have cycles smaller than 8 ply and my software doesn't check longer cycles.
I guess any human player would recognize these situations. So if a strong player
didn't it must be something more complicated.
Jacques.
Nick Wedd
<jac...@dybot.com> writes
>Nick Wedd wrote:
>
>> In one of the British Championship Match games, a bit over ten years
>>ago, Zhang Shutai made an illegal ko move against Matthew Macfadyen,
>>and immediately conceded that he had lost the game.
>
>Is the game record available?
This was an ordinary ko, there was nothing remarkable about the game.
(Anyway the record is no longer available.)
Nick
>I am interested because I have only found 2
>situations in real games:
>
>a. Triple ko
>b. Double ko when the group sharing the kos has nothing better than
>life in seki.
>
>Both have cycles smaller than 8 ply and my software doesn't check
>longer cycles.
>
>I guess any human player would recognize these situations. So if a
>strong player
>didn't it must be something more complicated.
>
>
>Jacques.
>
>_______________________________________________
>computer-go mailing list
>compu...@computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/
--
Nick Wedd ni...@maproom.co.uk
Vlad Dumitrescu
> Nick Wedd wrote:
> > In one of the British Championship Match games, a bit over ten years
> > ago, Zhang Shutai made an illegal ko move against Matthew Macfadyen, and
> > immediately conceded that he had lost the game.
>
> Is the game record available? I am interested because I have only found 2
> situations in real games:
>
> a. Triple ko
> b. Double ko when the group sharing the kos has nothing better than life in seki.
>
> Both have cycles smaller than 8 ply and my software doesn't check longer cycles.
>
> I guess any human player would recognize these situations. So if a strong player
> didn't it must be something more complicated.
It doesn't have to be. It can simply be so that he recaptured the ko directly.
I remember (but can't find it) that it was relatively recently that a
japanese 9 dan pro did the same mistake.
regards,
Vlad