On Fri, 2007-04-06 at 19:40 +0200, Chrilly wrote: > A major problem is quiescence search. We have not found so far a > simple and > efficient rule. Either the rule is too selective or the quiescence > explodes. > Again in chess MVLV is very effective.
Of course the best programs have improved on this signficantly. Most valuable victim least valuable attacker works amazingly well with no other information available, but the good programs now analyze to see if a capture is a losing capture by doing some kind of SEE (static exchange evaluator.) I was surprised at the huge efficiency this gave my chess program. It was like a brand new program when I discovered this. Even if SEE is not particularly well implemented this works extremely well. I assume suzie either does this already, or if it doesn't it's because it's hard to implement efficiently with your hardware. > Each capture reduces the search tree > and the quiescence-search terminates by itself. Generating just > captures is > in Go not sufficient. The tactical searcher in the evaluation takes > captures > already into account. But if one generates forcing moves like e.g. > building/destroying 2-eyes, semiais ... there is no natural > termination > limit. In go it's all messed up - no simple self-terminating rules. There is one idea - only deal with what was there before the quies search began. Limit what you are trying to discover to the groups that existed at the point the quies search began. I don't really know if it works or not - but it does follow the principle of "tapering", where more focus is spent on early decisions (more pruning close to leaf nodes, less pruning near root nodes.) A similar idea in chess was to look at all captures in the first N ply of quies, then only look at recaptures (and possibly up-captures.) - Don _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
