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 > [email protected] > http://dvandva.org/cgi-bin/mailman/listinfo/computer-go Ken Friedenbach [email protected] http://web.me.com/kenliz/Memoirs/Welcome.html _______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
