[Computer-go] quiescence in UCT search

Michael Williams michaelwilliams75 at gmail.com
Tue Nov 8 20:53:43 PST 2011

I don't see much point in pruning the nodes at the root like this because
UCT selection at the root is a very small part of program execution.
Making it quicker will not matter.  And you can't do the same thing at
other nodes because the root is the only node in which you have an idea how
much effort will be directed through it.

On Tue, Nov 8, 2011 at 8:11 PM, Dave Dyer <ddyer at real-me.net> wrote:

> My starting point is that the root node is different from all
> other nodes.  The purpose of any particular search is to select
> the next move.  Once a particular child is far enough behind
> the leaders, it's effectively eliminated, and any additional
> effort spent to investigate it is a waste.
> For example, suppose we're going to search for 10 seconds, 5 seconds
> have passed, the leading node has 10,000 visits, and some other node
> has 100.  It's mathematically impossible for the weak node to ever
> replace the strong one.
> I'm looking for a mathematical framework for making that kind of
> decision on an ongoing basis.  Ideally, the top level nodes will
> be eliminated one by one, as the probability that they would have
> eventually been the winning choice falls below a chosen threshold.
> _______________________________________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://computer-go.org/pipermail/computer-go/attachments/20111108/b27627b3/attachment.html>

More information about the Computer-go mailing list