Hi Eric, I think there are rules and there is etiquette. Rules you can control, but etiquette you cannot. You can never stop bad behavior and have the additional problem that you must "judge" it. You have to decide in which case a player exercised bad manners and so on. It's a tough thing.
I totally disagree with you on whether playing out a game to the bitter end is defensible or not. If it's in the rules, of course it's perfectly defensible. Nobody (or no program) should be criticized for following the rules or even trying to use them to it's advantage. That's the whole idea of rules - to define what behavior is acceptable and what is not. For example - if it's known that my program allocates too much time to the early moves, it should not be YOUR responsibility to resign or pass just so that I don't have to mange my time. Is it childish to play out a game hoping for a time-control win in a dead lost position? I don't think so. You may very well be losing the game because the opponent took too much time building up a won position. This is not a corner case, it is very common. I've seen this happy to Lazarus when I was testing time-control and trying to tune it. Lazarus would get a won position and the opponent would resign - and surely would have won if it had kept playing due to the fact that Lazarus didn't have much time left. Now should I have felt good or bad about that win? I felt bad even though the game was won. To see why, imagine that I kept the aggressive time-control in my program. Then I could have waved my hands and complained every time I lost a "won" game. I could have mumbled something about the opponent not resigning or passing when he "should have" and so on. In other words, I can pass the buck, or I can just make sure Lazarus doesn't lose games this way - or I can take my chances. I can use aggressive time-control logic in my program and hope that it causes me more wins than losses. But I cannot have it both ways. In other words, I have to play by the rules and the constraints they impose. It wouldn't be any fun otherwise. If we don't like the rules, we can talk about changing them in order to get behavior that fits our sensibilities better. But we have been over this ground many times before. It seems like the only reasonable way to properly score games is to play them out - and hence the use of tromp taylor rules. In order to help the situation I made suicide illegal on CGOS. - Don Eric Boesch wrote: > 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/ > > _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
