[Computer-go] issues on 19x19
dshawul at gmail.com
Wed Apr 27 10:17:48 PDT 2011
Oh thanks a lot! I was letting it search both of the moves but I agree one
should definitely be enough.
I will implement the "helping stone" concept.
Captures are always tried in qsearch that help stop the search when
"standing pat". Will that
be enough to avoid the 'snapback' problem ? Thanks again.
On Wed, Apr 27, 2011 at 12:58 PM, Ken Friedenbach <kenliz at cruzio.com> wrote:
> 1.) Ladder analysis can be reduced to almost linear search with a few
> branching points by doing an analysis of the two liberties available. One
> liberty has a "helping stone" adjacent, and the other has no helping stone
> adjacent, so would usually lead to three liberties for the running string. A
> ladder analysis can usually be limited to just the liberty without a helping
> stone. The only branching occurs if both liberties have a helping stone. And
> of course, you must read through captures to see if there is a snapback,
> 2). Don't know how to help there...
> Ken Friedenbach
> On Apr 27, 2011, at 8:23 AM, Daniel Shawul wrote:
> > I am having problems making my engine play a decent game on 19x19 board.
> Some KGS games
> > exposed the following problems.
> > 1) Ladder problem. It often mis-evaluates ladders despite my best efforts
> to detect them
> > in the playouts. So I resorted to doing qsearch at the root to weed out
> moves which
> > loose tactically, and make winning moves immediately. That helped but
> sometimes the qsearch explodes and engine looses on time.
> > I tried putting a limit to the depth of qsearch but it still runs into
> problems. Using a small depth limit may
> > help in 9x9 but on 19x19, atleast 40 plies is required to detect one
> ladder along the diagonal... so what to do ?
> > 2) My second problem concerns use of progressive widening/unpruning which
> looks like a must to have on 19x19.
> > The problem I have is with the move ordering... If I tell it to moves on
> the 3rd line from the edge are good ones,
> > it continually puts its stones on that line (hence forming a square),
> while the opponent controls the centre and also
> > cuts some parts of the 3rd line.
> > Then I used fillboard to try and fix this issue, but the engine once
> again tends to prefer these moves and put stones
> > all over the board. Which is when I realized it is impossible to fix it
> with static move ordering.
> > Should I use something dynamic like RAVE to order the moves? That will be
> inconvinient because I order the nodes
> > only during first allocation.
> > Also the default progressive unpruning formula seems to select too few
> moves for consideration, so I had to add 20 additional moves
> > to make it work for my engine.
> > _______________________________________________
> > Computer-go mailing list
> > Computer-go at dvandva.org
> > http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
> Ken Friedenbach
> kenliz at cruzio.com
> Computer-go mailing list
> Computer-go at dvandva.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Computer-go