magnus, I hate to ask the obvious, but how much time does each simulation take?
If 100 simulations would be enough information to get it out of its rut, why not just check every legal move for (say) 100 simulations before doing anything else? on another note, i think that it's cool that you have a board situation that exhibits such borderline behavior (i.e. that it takes relatively few simulations to fix the problem, but that the code as it stood would never find the problem on its own). steve. On Fri, Apr 11, 2008 at 4:25 AM, Magnus Persson <[EMAIL PROTECTED]> wrote: > Quoting Michael Williams <[EMAIL PROTECTED]>: > > > > Magnus Persson wrote: > > > > > Yesterday I noticed an odd phenomena in Valkyria wich was caused by > high selectivity and AMAF. > > > > > > > > > > > > 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. > > > > > > > > > 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. > > > > No, it does not because the AMAF score for move 2 is strictly lower than > the evaluation for move 1 and all other moves for some reason. It will try > other moves deeper in the tree instead and the position is sufficently > complex to generate a very large tree until it gives up on the move at the > root level. The thing is that if it searches move 2 for at least 100 > simulations it will discover it is a good move. But because of the AMAF > score is so low and all other moves are indeed losing moves it sticks to > move 1 because it at least makes it into a fight although at bad odds. > > Otherwise I am quite happy with the current implementation since it is > strong in testing, this only happens when there are two hot candidates and > the first one is searched first because of a limitation in move ordering, > and a particularly strong bias works against the second best. > > The annoying thing is that is can suddenly lose a game it was winning. > > But I found a better fix. I also tried to enter my pattern priorities as > the priors of the AMAF scores. And I now strongly believe that this is also > better in general and not for this particular situation. In the position I > wrote about yesterday this version get the right move almost immediately. I > tested as Valkyria 3.2.0 overnight on CGOS and it seems to be just as strong > as the previous version, and I can still tune the parameters of it. > > This means that the search of position will be guided in order by > > 1) My pattern priorities disguised as priors of AMAF scores. > 2) Then AMAF score will take over > 3) If a move is searched, then the true winrates for those moves will be > used and there is no bias from the pattern priorities except very weakly > from the AMAF scores. > > -Magnus > > > > -- > Magnus Persson > Berlin, Germany > > > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ > _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
