Re: [computer-go] A thought about Bot-server communications
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. Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
On Dec 13, 2007 12:17 PM, Jacques Basaldúa [EMAIL PROTECTED] wrote: 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 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
In message [EMAIL PROTECTED], Matthew Woodcraft [EMAIL PROTECTED] 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[EMAIL PROTECTED] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
Take this with a grain of salt, since I am a novice, but my understanding 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 [EMAIL PROTECTED] 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. Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
On Dec 11, 2007 4:00 AM, Don Dailey [EMAIL PROTECTED] wrote: Erik van der Werf wrote: On Dec 10, 2007 6:48 PM, Don Dailey [EMAIL PROTECTED] 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 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
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? 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! Erik ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
On Dec 11, 2007 2:18 PM, Don Dailey [EMAIL PROTECTED] wrote: 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. Erik ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
Nick Wedd wrote: 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. /Gunnar ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
Perhaps servers should have test suites and regression tests for participants. These would enable bugs to be worked out before engaging in tournament play. Terry McIntyre [EMAIL PROTECTED] They mean to govern well; but they mean to govern. They promise to be kind masters; but they mean to be masters. -- Daniel Webster - Original Message From: Gunnar Farnebäck [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Tuesday, December 11, 2007 10:12:57 AM Subject: Re: [computer-go] A thought about Bot-server communications Nick Wedd wrote: 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. /Gunnar ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] A thought about Bot-server communications
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? 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[EMAIL PROTECTED] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
As I understand it, gtp is for one way communication. I've heard of this as an issue when developers try to provide output for the benefit of players (or bot developer debugging the bot) 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. On Dec 10, 2007 8:23 AM, Nick Wedd [EMAIL PROTECTED] 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.htmlhttp://www.lysator.liu.se/%7Egunnar/gtp/gtp2-spec-draft2/gtp2-spec.htmlis 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[EMAIL PROTECTED] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
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
Re: [computer-go] A thought about Bot-server communications
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. - Don Don Dailey wrote: 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
Re: [computer-go] A thought about Bot-server communications
On Dec 10, 2007 10:07 AM, Don Dailey [EMAIL PROTECTED] wrote: 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. At least in chess there are irreversible moves (pawn moves and captures) which guarantee that any position achieved before will not happen again. So one could write an UCI engine that would send the last position after an irreversible move followed by the sequence of moves since then. In GO, this is probably a more serious problem. Yes, there is no such thing as an irreversible move in go. I think we are stuck with sending the whole list of moves every time we want to describe the current state of the game. Álvaro. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
On Dec 10, 2007 4:35 PM, Álvaro Begué [EMAIL PROTECTED] wrote: 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 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
On Dec 10, 2007 11:05 AM, Erik van der Werf [EMAIL PROTECTED] wrote: On Dec 10, 2007 4:35 PM, Álvaro Begué [EMAIL PROTECTED] wrote: 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 always think of go as meaning Tromp/Taylor rules. If you are talking about some other set of rules, please be as specific as possible about what game exactly you are talking about. Even for other rule sets, your observation doesn't really change my argument much. 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). I am not sure what you mean by normal rules. Are three kos a draw? What about other long cycles? It is not my intention to sound confrontational. I really don't know how other rule sets deal with tricky situations. Álvaro. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
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. - Don Álvaro Begué wrote: On Dec 10, 2007 11:05 AM, Erik van der Werf [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Dec 10, 2007 4:35 PM, Álvaro Begué [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: 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 always think of go as meaning Tromp/Taylor rules. If you are talking about some other set of rules, please be as specific as possible about what game exactly you are talking about. Even for other rule sets, your observation doesn't really change my argument much. 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). I am not sure what you mean by normal rules. Are three kos a draw? What about other long cycles? It is not my intention to sound confrontational. I really don't know how other rule sets deal with tricky situations. Álvaro. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
In message [EMAIL PROTECTED], Álvaro Begué [EMAIL PROTECTED] 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[EMAIL PROTECTED] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
On Dec 10, 2007 11:48 AM, Don Dailey [EMAIL PROTECTED] wrote: 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. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
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. According to Terry Benson: Natural Situational Superko -- robert jasiek ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
On Dec 10, 2007 11:56 AM, Nick Wedd [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Álvaro Begué [EMAIL PROTECTED] 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. Thanks for the brief summary of all these rulesets! 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. Álvaro. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
In message [EMAIL PROTECTED], Robert Jasiek [EMAIL PROTECTED] 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[EMAIL PROTECTED] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
On Dec 10, 2007 5:23 PM, Álvaro Begué [EMAIL PROTECTED] wrote: On Dec 10, 2007 11:05 AM, Erik van der Werf [EMAIL PROTECTED] 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). 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. Erik ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
On Dec 10, 2007 6:07 PM, Álvaro Begué [EMAIL PROTECTED] 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. Erik ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
Erik van der Werf wrote: On Dec 10, 2007 6:07 PM, Álvaro Begué [EMAIL PROTECTED] 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 Erik ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
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. (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 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] A thought about Bot-server communications
Erik van der Werf wrote: On Dec 10, 2007 6:48 PM, Don Dailey [EMAIL PROTECTED] 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 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. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
