On 20-nov-08, at 15:20, Magnus Persson wrote:
Quoting Mark Boon <[EMAIL PROTECTED]>:
What is not exactly clear to me is what you mean by 'postponing
expansion'. Let me write it in my own words to see if that's what you
mean. When you have selected a best node based on the UCT + wins/
visits
value which has no children yet, you first simply do a simulation and
collect the playout result in the current node, including the AMAF
value that you call 'virtual win-visit ratio, and only when that is
done a certain number of times (in your case 10) do you suddenly
create
all the children and weight them based on the virtual win-visit
ration
and possibly weight them based on other move-priorities that resulted
from 'heavy' playout selection?
Yes I "suddenly" create all children, but at the creation I have no
simulation and thus no virtual win-visit ratios for the children
(although one might copy such values from higher up in the tree,
which I think the Mogo team tried but with little or no success).
The virtual win-visit ratios are initialized to some default value.
But one can initialize the ratios differently depending on static
evaluation the position using patterns for example. Or the
proximity heuristic. It is not clear to me how to best do this. And
I need to test the parameters for biasing. The nice thing is that
one can initialize the virtual win-visits ratios and keep real win-
visits ratios unbiased. You can afford to make mistakes here
because if the position is searched a lot the virtual values get
data much quicker than the real ones.
OK, things start to fall in place for me. I was wondering all this
time what would happen with the information of the simulations that
happen before expansion. So the answer is: nothing. But at least the
result of the playout gets percolated up the tree, so I suppose you
get the most important bit of information of the playout in your tree
anyway. I have also been wondering before what was meant when I read
that CrazyStone uses ownership information in the patterns (if I
remember that correctly). I was always wondering how you got
ownership information before doing playouts. So it turns out these
come from simulations done before expansion. Somehow I had
disregarded that idea because I was under the assumption it would
discard too much information. But I suppose keeping the playout
results in the tree is valuable enough by itself. And like you say,
you win back a lot by not having to do at least a playout for every
single move at every level in the tree.
From the beginning I have been experimenting with ownership
information and I think I have a few interesting ideas. But they
didn't fit in yet. Maybe with my new understanding I can go back and
try out a few of those ideas again. It means rewriting my search-code
a bit. Hopefully it's not too much work.
Mark
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
