[computer-go] Please have your bot resign, for your own good
Don Dailey
drdailey at cox.net
Wed Jan 2 12:29:53 PST 2008
I am considering to implement Fischer time on CGOS, but I would like it
to be painless. I don't believe GTP has a provision to handle it -
but I will check to see what it does have. (I have no intentions of
doing the byo-yomi stuff.)
However, even without a change to your program Fischer time would still
work. You just wouldn't utilize time quite as effectively.
The client could have a mode that "helps" the engine allocate time more
wisely by reporting some of the future surplus time that will be
available in advance. Of course there would probably have to be an
extended GTP command that programs could optionally use.
Fischer time is a wonderful time control for computer players. It
takes most of the burden and uncertainty involving game length out of
the equation.
- Don
steve uurtamo wrote:
> i like don's idea about using fischer time. byo-yomi seems to be
> the obvious solution to the problem (just make it a small byo-yomi time,
> something like 5 seconds), but fischer time has some pretty magical
> features that computers can easily take advantage of. time management
> should be quite a bit easier under fisher time, for instance, than with
> something as complicated as byo-yomi, or something as delta-function as
> absolute time. even canadian time management is more complicated.
>
> just a few nits...
>
>
>> 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.
>>
>
> although it doesn't matter much, i doubt that anyone connecting their bot
> to CGOS has 2 seconds of net lag per move, every move. so it's kind've
> a straw-man argument. 500-750ms is a reasonable upper-bound on the
> average delay between two arbitrary machines when one is well-connected and
> the other isn't in a third-world country.
>
>
>> 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,
>>
>
> by "basically forever" are you imagining a situation where legal moves are
> played one after the other that both:
>
> i) don't violate superko
> ii) don't create a massive disadvantage for the person playing the move.
>
> i guess i'm not imaginative enough today, but i am having trouble envisioning
> a board where you would have both of these conditions hold *for both players*
> for "basically forever" (where basically forever can be defined to be some huge
> number of moves).
>
> also, i don't think that it should delay anything for anyone else on CGOS, would it?
> is this even a practical/pragmatic concern in tournaments? have there been KGS
> tournaments (or otherwise) that were held up "basically forever" because of extremely
> unfortunate play between two opponents?
>
>
>> because two players in a "Who can play stupid moves fastest?" battle
>> could swamp the network and cause lag for programs playing real games.
>>
>
> this sounds wrong to me. if the server can dequeue the packets at roughly
> the same rate that they're coming in (and keep in mind that player B won't send
> a new move packet until the server has already dealt with player A's move packet), the
> packet sizes and bitrates involved should never swamp any reasonably well-connected
> machine on a modern network. you would need very many people doing this
> simultaneously for it to be a real problem. either that, or a very, very stupid protocol.
>
> s.
>
>
>
> ____________________________________________________________________________________
> 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 at computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>
More information about the computer-go
mailing list