[computer-go] A problem with selectivity and AMAF bias

[Magnus Persson]

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