[Computer-go] issues on 19x19

Ken Friedenbach kenliz at cruzio.com
Wed Apr 27 09:58:42 PDT 2011

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, etc.

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

More information about the Computer-go mailing list