[Computer-go] issues on 19x19
dshawul at gmail.com
Thu Apr 28 13:12:51 PDT 2011
What I am doing is a general scheme based the move ordering ( however that
I currenlty do not use patterns. But I do test for other stuff such as atari
ladder attack, edge distance, CFG distance, cut move , connect moves, fill
All that brings my pps down to 1000 on the big 19x19 board.
After that I just select the first k moves for UCT selection using the
formula: k = kinit + (log(n) - log(A)) / log(B)
This is the same formula from the original paper rearranged .
I do use RAVE and combine it with the real UCT score. I do not use it for
move ordering yet
which is what I am asking here. The dynamic nature of it lead me to belive
it can avoid the predictability issues
I am facing.
I also tried biasing the rave score of the first 10 moves (sort of
rave += ((rave / 2) * (1 - order / 10.0f));
Hope I am clear enough
On Wed, Apr 27, 2011 at 2:10 PM, Petr Baudis <pasky at ucw.cz> wrote:
> On Wed, Apr 27, 2011 at 11:23:41AM -0400, Daniel Shawul wrote:
> > 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),
> > 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
> > tends to prefer these moves and put stones
> > all over the board. Which is when I realized it is impossible to fix it
> > 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
> > for consideration, so I had to add 20 additional moves
> > to make it work for my engine.
> You should explain in more detail exactly what you are doing right
> now, as the terminology is highly muddled. I assume that now, in n-th
> tree descent through given node, you consider only f(n) children for
> next move instead of all children. Also, I assume you use just plain UCT
> for node evaluation?
> I think progressive bias (considering all children, but giving extra
> bonuses to values of some or all children) is much better explored
> approach (at least in literature). However, it's certain that just using
> a single criterion for the ordering is not going to work well. You can
> either use a mix of patterns, hints from some other engine, or (best)
> RAVE values. Plus some extra coefficients for tactical checks (e.g.
> atari), last move CFG-distance and distance from edge.
> I think you will find it very difficult to achieve reasonable
> performance on 19x19 without RAVE. But if you are reluctant to do that
> yet, at least try combining last move CFG-distance, distance from edge,
> basic tactics and Mogo 3x3 patterns. The larger the mix, the more
> diverse your array of considered moves will be. In particular, I have
> found last move CFG-distance to be immensely important for gaining
> strength on 19x19.
> Petr "Pasky" Baudis
> UNIX is user friendly, it's just picky about who its friends are.
> Computer-go mailing list
> Computer-go at dvandva.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Computer-go