gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] GnuGo violates time_settings?


From: Gunnar Farnebäck
Subject: Re: [gnugo-devel] GnuGo violates time_settings?
Date: Tue, 26 Jun 2012 23:21:51 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4

On 06/21/2012 03:04 PM, TS wrote:
1) Eg "time_settings 0 4 1" -> gnugo will play maybe 3 fast moves, then
take 10 seconds for his next move.
Any idea what might be causing this? I don't believe that this is just a
"normal bug", since that would've surfaced a long time ago and been
fixed by now.

GNU Go wasn't designed for time control from the start and when it was
added it was very difficult to retrofit in a good way, not least
because it does several local searches, where it's no good to have
just half of them, and those are done depth first and thus not easily
terminated with a meaningful result. The way time control was
implemented was as a control loop around the level setting, which has
a very non-linear and not easily predicted relation to the actual time
needed for move generation.

In this particular case it probably noticed it was way behind, reduced
the level significantly, then after a few quick moves decided it could
increase the level again but overcompensated to something too slow.

2) Also, easily reproducable:
Try to change params while a game is in progress by just calling "level
10" and "time_settings 0 <whatever> 1" before calling the actual
"genmove white" (assuming gnugo is w here) and gnugo will always just
timeout and not generate any move anymore.

Doesn't sound surprising, it never gets a chance to tune in the level
settings.

I'm actually more surprised that the time control mechanisms do work
reasonably robustly in many scenarios. They are kind of crude (and I'm
only criticizing myself here) and could certainly be improved in
various ways, although I don't think it's easy to do. The most
sensible approach to get something significantly better is probably to
try to keep the classical searches bounded by a good margin and let
the time control mostly act on the Monte Carlo move generation, which
is much more easily time controlled. But for that to make sense the
Monte Carlo part needs to be much better and do meaningful work on
boards larger than 9x9.

/Gunnar



reply via email to

[Prev in Thread] Current Thread [Next in Thread]