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

[Michael Williams]

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.