In chess, playing the game out to the bitter end can be defensible, but in go, it isn't. The meaning of the "end of the game" in go is fluid, but it's not "when it's no longer possible to play a move". In absolute time limit games, when significant per-move lag exists (which is true in all human matches and some computer ones), it is impossible to schedule correctly to deal with the possibility that the opponent will continue playing for as long as possible after the game is already over. Either you allocate too little time for the real game, putting yourself at a disadvantage if you and your opponent play reasonably, or you leave yourself without enough time to handle unreasonable play. All go players know how to keep playing after the game ends, but it's as childish and outside the spirit of the rules as starting a no time limit game, realizing you have fallen behind, and never returning to the board. In the eyes of most players, a time win in a lost position well after the game has ended isn't even a win-with-an-asterisk -- it's a dead loss, even moreso if the player with the winning position played as quickly as lag would permit. This is why byo yomi can actually shorten games: compared to absolute time, it removes much of the incentive for children to keep playing after the game is over.
All methods of compensating for net lag require some level of trust. Even if a fraud-proof way to detect net lag existed, it would interfere with time controls and scheduling. If it takes a second before program B knows what move program A played, then that's a second during which program A has better information about the game than program B has. You can say that it hopefully averages out in the wash, but the possibility that a program might gain an advantage from its poor network connection is still there. Any compensation for net lag at all means that a program that ponders gains a greater advantage than the official time controls would suggest: imagine 1 second per move, plus 2 seconds of net lag, in which case the programs have 1 second per move to think, plus 2+1+2 seconds between moves to ponder. So I think Peter was right to direct his request to other programmers, instead of asking Don to compensate for net lag. I was going to suggest copying KGS's "no time cost for a pass within a reasonable number of seconds" rule, but I see Erik just did that. Well, I'll just second the suggestion. Unfortunately, the "reasonable number of seconds" would probably have to be low, just so it doesn't increase the game durations to unreasonable levels. One player passing over and over while the other keeps playing dumb moves is a scenario that is certain to occur over and over, and the only reason it's not a bigger issue is that long delays by the passing player ought to be infrequent. With a little bit of go knowledge, it is possible for the server to punish programs that play time-wasting moves, but if you can't count on the players to be smart enough to know when they're wasting time, that could mean assigning a loss to programs that are actually winning. A simpler approach would be if the server just ended the game as soon as it became statically solvable -- though exotic sekis aren't statically solvable, so if they appeared then you'd have to fall back on the two-passes-end-the-game rule. (In theory, superko can break static analysis -- superko might forbid capturing a surrounded chain, for example -- but in practice, I bet it never would.) Finally, I'm still not aware of any go programs that keep playing after they have obtained a dead lost position because the programmer wants them to do it. It's just easier to write a program that doesn't know when to resign than to write a program that does. On this point, I disagree with Erik. We get enough stupid games by accident that we don't need programs that play asinine games on purpose. Peter already identified some reasons. Also, if programs prolong the game as much as possible, it means that the next round of ALL programs will be delayed, and the more programs you have that deliberately refuse to resign, the greater the probability that you will get two that, because of a failure on the part of the leader to correctly bring the game to a close, play a match that goes on basically forever. In that case, only a double-forfeit is sufficient -- switching to true absolute time limits would not be good enough, because two players in a "Who can play stupid moves fastest?" battle could swamp the network and cause lag for programs playing real games. One could even temporarily block the accounts so other programs can continue while the programmers in question debug their broken programs. On Jan 2, 2008 8:22 AM, Don Dailey <[EMAIL PROTECTED]> wrote: > Hi Peter, > > CGOS doesn't count the first 1/4 second of thinking time and this could > help a little. > > This isn't the same as Fischer time however because you are not given > the time if it adds to your surplus. It is designed so that if you > play fast enough (less than 1/4 second per move) you will not lose time > on the clock provided your network is not too slow. Apparently that > is not enough in your case. > > I agree with resigning - it's the most friendly and cooperative way to > play. I recently saw my bot win a dead lost game on time because I > have not yet put resignation in it. > > Actually, I would personally not resign if I thought the opponent might > lose on time - I consider it part of the game. My bot would play > stronger if I took more time to win games too and I feel it's completely > fair to penalize programs that spend too much time getting a won game > and then expect you to resign so that they do not lose. > > However, yours is a special case - you have no control over the network > lag factor and it's not fair for you to lose this way. > > I have heard of protocols that attempt to deal fairly with network lag - > but I don't know how they work. I don't know how to design one that is > not subject to tampering with. > > I wish I knew how to deal with your problem in a fair way. But then on > the other hand some people have very fast computers - which might also > seem unfair. If your computer is twice as fast as mine, you are > effectively getting twice as much thinking time. So CGOS is just > what it is. You do the best with the "equipment" you have. > > I will think about the problem. I would like network lag not to be an > issue, but it seems like it will always be. How does KGS deal with > this? What do you do when you play on KGS? > > - Don > > > > > Peter Christopher wrote: > > I realize there are some legitimate reasons to have your bot play out > > the games on cgos until the bitter end. Here I would like to present > > one reason why you may want to have your bot resign instead. I live > > in the Philippines. My ping from my computers here is usualy about > > .3-.4 seconds. I do often put some bots on cgos from here, tend to be > > rated around 1600-1700. Because of the long ping & the tromp-taylor > > rules, my bots often lose won games on time. Playing from my computer > > here, I typically set a buffer around 45 seconds when the bot assumes > > the game is a won game & almost immediately plays filler moves. > > Nevertheless, with this buffer or even a larger buffer, the bot often > > captures massive groups, and at 2 moves per second (all network lag), > > the bot can't fill the whole board again & again, and if my bot passes > > & yours doesn't, that's also slow to fill the board. The end result > > is that in your records, you may be testing your bot's new features > > and want to have an accurate elo rating to know whether it is working. > > If your bot is playing my bot, and your bot doesn't resign lost > > games, you won't have an accurate rating of its new features. Sorry > > for the inconvenience. This is happening today quite a lot vs. > > challenger. Some other days it's a different bot. Just something to > > keep in mind. > > Peter > > _______________________________________________ > > 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/ > _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
