AMAF certainly helps to do move ordering when there is little other information. With good prior heuristics or enough actual playouts, it should not be weighted very highly. AMAF finds good moves, but it often bias heavily for or against moves. In ManyFaces, AMAF (actually RAVE) is worth between 5% and 10% wins against gnugo.
I've seen similar ladder problems, and it is not AMAF, it's caused by the playouts, when they can't read ladders. It's easy to add various hacks to prevent playing out simple ladders, but the one in this game had an extra liberty (if I remember correctly). A general solution is a little tricky. David > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:computer-go- > [EMAIL PROTECTED] On Behalf Of Don Dailey > Sent: Monday, September 22, 2008 6:23 AM > To: computer-go > Subject: Re: [computer-go] MoGo v.s. Kim rematch > > I think AMAF is a feature not a bug. It's only a matter of how > judiciously it's applied. > > Also, almost any evaluation feature in a game playing program is a bug > - meaning it is an imperfect approximation of what you really want. > > Of course it could turn out that AMAF got them in trouble in this game. > The Mogo team will probably analyze the reason for the problem. But > as long as they are playing strong professional players they are going > to have something to debug and analyze! > > - Don > > > > On Mon, 2008-09-22 at 06:06 -0700, terry mcintyre wrote: > > Consider this as tentative, since I heard it about 3rd-hand, but I > believe the number of processors used to have been 3000. > > > > > > Congratulations to the Mogo team; good luck improving your program to > deal with the ladder and life-and-death issues. > > > > Looking forward to further information! > > > > I have always wondered if AMAF is a feature or a bug. There are many > situations where the order of moves is crucial; A before B wins, B > before A loses; ladders are a classic example where the ordering of > moves is utterly important. AMAF seems to assume that order doesn't > matter. Of course, there are many other positions where this assumption > is true; that is why it sometimes yields an improvement in processing > speed, but it seems risky. > > > > Ladders are also a classic case where two patterns can look very > similar, but be very different. When you capture a ladder, you are in a > very good position. But if the stones under attack have just one extra > liberty, the position may "look like" a ladder, but your target will > escape, and your stones will be full of cutting points; the proper > evaluation for that position would be much harsher. More generally, > whenever I see a Monte Carlo program lose, it is usually a semeai where > being one liberty behind or one ahead makes all the difference. We call > these "capturing races" in English for a reason; being ahead or behind > by one liberty matters a great deal. To make life interesting, there > are "loose ladder" constructs where an extra liberty does not help the > fleeing stones; they still get corraled and captured. > > > > These corner cases are tough, but many games hinge on correctly > reading out the exact consequences of life-and-death struggles. > > > > Terry McIntyre <[EMAIL PROTECTED]> > > > > > > "Go is very hard. The more I learn about it, the less I know." -Jie > > Li, 9 dan > > > > > On Mon, 2008-09-22 at 13:59 +0200, Magnus Persson wrote: > > > > Quoting Mark Boon : > > > > > > > > > Playing out that fake ladder in the first game meant an instant > loss. > > > > > Surprising. And embarassing. Any information on the number of > > > > > processors used? > > > > > > > > _______________________________________________ > > 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/
