Magnus Persson wrote:
Yesterday I noticed an odd phenomena in Valkyria wich was caused by high
selectivity and AMAF.
In this position
(;GM[1]FF[4]SZ[9]AP[SmartGo:1.4]
KM[7.5]
;B[ee];W[de];B[ed];W[df];B[ef];W[dd];B[dg];W[ge];B[dc];W[cc];B[cd];W[bd]
;B[cb];W[ce];B[bc];W[bb];B[cd];W[cg];B[cc];W[bf];B[gd];W[hd];B[hf];W[gc]
;B[gf];W[fd];B[fb];W[gb];B[fc];W[he];B[fe];W[ib];B[dh];W[ch];B[ad];W[be]
;B[di];W[ci];B[ha];W[ga];B[ie];W[id];B[if];W[fa];B[gd];W[hb];B[eg];W[eb]
;B[ec];W[da];B[ca];W[ae];B[ic])
there are only two possible moves 1) capturing the last black stone
played or 2) capture the ko. Only capturing the ko wins.
In this position valkyria will first search 1) because capturing the
last stone is urgent. But the search locks into to that move only
because there are a strong bias against move 2) in the AMAF evaluation
for Valkyria. I guess what happens with AMAF is that alternative local
moves (local relative to the first move in a repeated sequence) will
always be biased downwards. This is so because playing the alternative
local moves after the first one is played is often inefficient because
of a duplication of effort.
Then since there is nothing in the AMAF scores that indicate that move 2
is any good it is never searched, since the search is so selective that
the bounds will not grow large to compensate for the bias in a
reasonable time.
I do not expect your programs to have the same problem in this
particular position. But the problem could be general and I am curious
if you have solutions for it if you do.
I did implement a crude solution that works in this position and did not
make Valkyria lose rating overnight.
I added
IF (#TotVisits > 500) AND (#Visits > 0.9*#TotVisits) THEN
uctQ := 0.5*uctQ;
before computing
Q := beta*virQ + (1-beta)*uctQ;
the effect of this is simply that as soon as a move has been played more
than 90% of the time after at least 500 moves has been played in the
position then other moves has to be played. This has to the drawback
that the search gets slightly inefficient when it finds forced moves.
One reason I have this problem may be that I bias the Q value towards
local shapes after it has been computed. I should perhaps put weight on
high priority patterns by adjusting the prior value of the AMAF instead.
I realized this when I read the latest easy-to-read paper from the MOGO
team and I will test that as well.
-Magnus
Isn't this fixed by never straying from a move in the tree until it loses and
then trying an untried move?
Or something like that. It wasn't my idea and I don't remember the details,
but it seems like it fixes what you describe.
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
