Erik van der Werf wrote: > I'd propose something simpler: > > No time is deducted for pass. > > With this rule your program will only loose time when it absolutely > has to respond to the opponents move. In most games the winning > program can simply play until it has a sufficient number of > unconditionally alive stones on the board and then pass forever > without ever risking a loss on time. > This is not manageable and is also subject to manipulation. The server could wait forever to see if a move might be pass. The only reasonable way to implement this is to allow a liberal time margin for a pass move. For instance if your bot passes, up to 5 seconds is "forgiven."
I'm somewhat opposed to this idea. The decision to pass is still a "considered decision" and I don't see why pass should be treated differently. Better would be some kind of victory declaration. The program claims victory - which means that it agrees that every move from now on (for itself) is a pass move. It would be the counterpart to resignation - with the provision that you give up all rights to defend yourself if you are wrong. - Don > Erik > > > On Jan 2, 2008 3:02 PM, Don Dailey <[EMAIL PROTECTED]> wrote: > >> Of course it's also possible to implement the Fischer clock on CGOS. >> Fischer clock is where you have a fixed time component (such as 5 >> minutes) but you also are given an increment - another fixed time >> component that is added to your clock EACH MOVE. >> >> So it might be expressed as "2 minutes + 5 seconds" which means you >> are given 2 minutes initially, but you are also awarded 5 seconds per >> move - whether you use it or not. It is simply added to your clock. >> >> I've always liked this kind of time control. It prevents games lost >> due to mad time control scrambles. It makes the games feel more >> traditional (like the old days when clocks were not used) because the >> pressure of the clock has been reduced (although not eliminated.) >> >> There are some problems with this on CGOS: >> >> 1. I don't think GTP has Fischer time mode. >> 2. Not traditional in GO. >> 3. Programs do not currently implement it. >> 4. It doesn't really solve your problem. >> >> The fact that it's not traditional isn't a factor from my point of >> view, I am progressive about positive change. >> >> It doesn't solve your problem because you would still be cheated out of >> 2 seconds per move - although it might be much easier for you to deal with. >> >> It would be simple to handle the GTP issues. If your program could not >> handle Fischer time some modes could be added to the client to help you >> manage it. In the simplest case it would just report time remaining >> and there could be modes that factor in the next N moves to this. >> >> - 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/
