On 5/7/07, Peter Drake <[EMAIL PROTECTED]> wrote:
Iterating through the children should not be a significant time hit,
because (a) UCT trees tend to be quite shallow, rarely more than 5
moves deep, and (b) the vast majority of nodes are leaves.
Right, but IMO the real reason why you want to exa
On May 7, 2007, at 12:30 PM, Chris Fant wrote:
"it seems natural that I should update the playout count for A" ???
That doesn't seem natural to me. You've done two playouts from A so
why would you update it to 1?
On further thought, I think this is the correct answer.
Iterating through the
Hi,
see below
On 5/7/07, Peter Drake <[EMAIL PROTECTED]> wrote:
In the first playout, my first move is A, so then I have:
ROOT 1
A 1
Now I try move B, updating the tree to:
ROOT 2
A 1
B 1
Fine so far. Now UCT likes A better, so the next playout starts with
A, C, givi
On 5/7/07, Peter Drake <[EMAIL PROTECTED]> wrote:
When I
look through the children of A and count a total of one playout, it
seems natural that I should update the playout count for A:
I would normally try to save all simulation results, but I can certainly see
the value of forcing invariant
I'm contemplating making the change you suggest. The following is my
one concern.
Suppose, to keep the example simple, that there are only two choices
at each ply. My tree is originally
ROOT 0
meaning that there is just one node with no playouts.
In the first playout, my first move is A, so th
On May 2, 2007, at 8:17 AM, Peter Drake wrote:
On May 2, 2007, at 8:07 AM, Erik van der Werf wrote:
Don't you determine the sum of visits by adding all values in the
children? I guess it looks like a nice speedup to get the sum
directly
from their parent, but does that really matter in comp
On May 2, 2007, at 8:07 AM, Erik van der Werf wrote:
On 5/1/07, Peter Drake <[EMAIL PROTECTED]> wrote:
Like most of the UCT programs (I believe), Orego adds one tree
node per
Monte Carlo run. At present, this node includes data from the run
that
created it. Thus, after the first run, my tre
On 5/1/07, Peter Drake <[EMAIL PROTECTED]> wrote:
Like most of the UCT programs (I believe), Orego adds one tree node per
Monte Carlo run. At present, this node includes data from the run that
created it. Thus, after the first run, my tree looks like this:
ROOT: 1/1 wins
CHILD A: 1/1 wins
Igno
>> [...] memory-saving technique of not expanding a leaf until you have
>> been through it many times (100, for example).
>
> I have been wondering about this: If it pays off not to expand a node
> until it has been visited 100 times, why not bite the bullet and make
> those 100 simulations in one
Quoting Chris Fant <[EMAIL PROTECTED]>:
I have been wondering about this: If it pays off not to expand a node
until it has been visited 100 times, why not bite the bullet and make
those 100 simulations in one go? That should save a bit of time
traversing the tree up and down. Of course, it means
I have been wondering about this: If it pays off not to expand a node
until it has been visited 100 times, why not bite the bullet and make
those 100 simulations in one go? That should save a bit of time
traversing the tree up and down. Of course, it means that they all do
get a full 100 simulatio
On Tue, May 01, 2007 at 11:42:46PM -0400, Chris Fant wrote:
> [...] memory-saving technique of not expanding a leaf until you have
> been through it many times (100, for example).
I have been wondering about this: If it pays off not to expand a node
until it has been visited 100 times, why not bit
Like most of the UCT programs (I believe), Orego adds one tree node per
Monte Carlo run. At present, this node includes data from the run that
created it. Thus, after the first run, my tree looks like this:
ROOT: 1/1 wins
CHILD A: 1/1 wins
Ignoring the other children, I eventually do another ru
Like most of the UCT programs (I believe), Orego adds one tree node
per Monte Carlo run. At present, this node includes data from the run
that created it. Thus, after the first run, my tree looks like this:
ROOT: 1/1 wins
CHILD A: 1/1 wins
Ignoring the other children, I eventually do
14 matches
Mail list logo
