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 <[email protected]> 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, > 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 >
_______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
