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. 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/
