Thanks for the input. It is a very interesting idea. Since I don't have a
transposition table but only a stupid tree, I can't apply the same mechanic.
I can image that with a transposition table, nodes are very equally distri-
buted, so pruning one of the 16 moves almost always is a good choice.
B
> Pebbles prunes least recently used nodes. This eliminates nodes
> from previous searches first, and then nodes from the current search.
Why do you keep nodes from previous searches? By search, do you mean a
"genmove"? How do you store which nodes are oldest (queue, heap)?
--
GRATIS für alle GM
Nice to hear that :)
2009/6/5 Michael Williams :
> Łukasz Lew wrote:
>>
>> On Wed, Jun 3, 2009 at 00:56, Michael Williams
>> wrote:
>>>
>>> Two things: Firstly, I'm storing (only in RAM) the precalculated Winrate
>>> and InvSqrtVisits and keeping them updated.
>>> So my UCT formula went from
>>>
Łukasz Lew wrote:
On Wed, Jun 3, 2009 at 00:56, Michael Williams
wrote:
Two things: Firstly, I'm storing (only in RAM) the precalculated Winrate
and InvSqrtVisits and keeping them updated.
So my UCT formula went from
Wins / Visits + sqrt(lnParentVisits / Visits)
to
WinRate + s
Jason House wrote:
On Jun 2, 2009, at 6:56 PM, Michael Williams
wrote:
Two things: Firstly, I'm storing (only in RAM) the precalculated
Winrate and InvSqrtVisits and keeping them updated.
So my UCT formula went from
Wins / Visits + sqrt(lnParentVisits / Visits)
to
WinRate + sqrtLnP
On Jun 2, 2009, at 6:56 PM, Michael Williams > wrote:
Two things: Firstly, I'm storing (only in RAM) the precalculated
Winrate and InvSqrtVisits and keeping them updated.
So my UCT formula went from
Wins / Visits + sqrt(lnParentVisits / Visits)
to
WinRate + sqrtLnParentVisits * InvSq
On Wed, Jun 3, 2009 at 00:56, Michael Williams
wrote:
> Two things: Firstly, I'm storing (only in RAM) the precalculated Winrate
> and InvSqrtVisits and keeping them updated.
> So my UCT formula went from
>
> Wins / Visits + sqrt(lnParentVisits / Visits)
>
> to
>
> WinRate + sqrtLnP
Two things: Firstly, I'm storing (only in RAM) the precalculated Winrate and
InvSqrtVisits and keeping them updated.
So my UCT formula went from
Wins / Visits + sqrt(lnParentVisits / Visits)
to
WinRate + sqrtLnParentVisits * InvSqrtVisits;
This has a memory cost, but I don't
That sounds like a good optimization. What did you do?
Sent from my iPhone
On Jun 2, 2009, at 3:16 PM, Michael Williams > wrote:
Update: After concentrating on tightening the UCT loop, I've
optimized myself back into needing the SDD :/
But now I should be able to get to 20B nodes in just
I mean "SSD".
Michael Williams wrote:
Update: After concentrating on tightening the UCT loop, I've optimized
myself back into needing the SDD :/
But now I should be able to get to 20B nodes in just one day.
(still only doing 7x7 Go)
Michael Williams wrote:
Yes, when memory is full, I save
Update: After concentrating on tightening the UCT loop, I've optimized myself
back into needing the SDD :/
But now I should be able to get to 20B nodes in just one day.
(still only doing 7x7 Go)
Michael Williams wrote:
Yes, when memory is full, I save and free all leaf nodes (which is the
Yes, when memory is full, I save and free all leaf nodes (which is the vast
majority). Nodes are loaded as needed.
Don Dailey wrote:
On Mon, Jun 1, 2009 at 4:57 PM, Michael Williams
mailto:michaelwilliam...@gmail.com>> wrote:
I've optimized my disk access to the point where I'm mostly
On Mon, Jun 1, 2009 at 4:57 PM, Michael Williams <
michaelwilliam...@gmail.com> wrote:
> I've optimized my disk access to the point where I'm mostly CPU limited
> now, even when using a standard hard disk instead of an SSD. I can now
> create trees of up to about 30 billion nodes, which would tak
I've optimized my disk access to the point where I'm mostly CPU limited now, even when using a standard hard disk instead of an SSD. I can now create trees of
up to about 30 billion nodes, which would take about a week. The simulation rate is continuously going down because so much time is spent
mputer-go.org [mailto:computer-go-
> boun...@computer-go.org] On Behalf Of Isaac Deutsch
> Sent: Monday, June 01, 2009 9:23 AM
> To: computer-go
> Subject: Re: [computer-go] UCT tree pruning
>
>
> > But is it better? I think it's not so obvious without thorough
testing.
I prune nodes with few visits. Most of the nodes in the tree have very few
visits, so there is usually lots of opportunity for pruning.
David
> -Original Message-
> From: computer-go-boun...@computer-go.org [mailto:computer-go-
> boun...@computer-go.org] On Behalf Of Isaac Deutsch
> Sent
> But is it better? I think it's not so obvious without thorough testing.
> - Don
OK. It seems difficult to find a good rule to prune moves/nodes.
I just had an additional idea. You could make the treshold for expanding a
node a function of the tree size AND the depth the node is at in the t
On Mon, Jun 1, 2009 at 11:22 AM, Isaac Deutsch wrote:
>
> > Well, I'll take that over crashing with an out-of-memory error. :)
>
> Still, pruning seems better to me and has the same effect. ;p
But is it better? I think it's not so obvious without thorough testing.
Pruning throw away informat
Valkyria simply do not expand the tree when it runs out of unused nodes.
That would be the most simple thing to prevent crashing.
Then one could consider pruning the tree in order to be able to expand
the tree even deeper.
-Magnus
Quoting Isaac Deutsch :
Well, I'll take that over crashin
> Well, I'll take that over crashing with an out-of-memory error. :)
Still, pruning seems better to me and has the same effect. ;p
--
Nur bis 31.05.: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und
Telefonanschluss nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
On Mon, Jun 1, 2009 at 10:10 AM, Isaac Deutsch wrote:
>
>> No. We use a threshold that is a function of how large the tree
>> already is. It starts at 5 and then we increase it as the tree grows
>> larger. I think the exact formula scaled with something like the
>> log(tree_size)^2, but I would ha
> No. We use a threshold that is a function of how large the tree
> already is. It starts at 5 and then we increase it as the tree grows
> larger. I think the exact formula scaled with something like the
> log(tree_size)^2, but I would have to check when I get home.
>
> Álvaro.
Ah, now I underst
On Mon, Jun 1, 2009 at 9:38 AM, Isaac Deutsch wrote:
>
>
>> In dimwit we simply increase the number of visits to a node before it
>> is added to the UCT tree, to slow down its growth. I wasn't too happy
>> about how selective the tree got with a long time to think, but it's
>> unclear if this part
> In dimwit we simply increase the number of visits to a node before it
> is added to the UCT tree, to slow down its growth. I wasn't too happy
> about how selective the tree got with a long time to think, but it's
> unclear if this particular hack had anything to do with that.
>
> Álvaro.
I al
In dimwit we simply increase the number of visits to a node before it
is added to the UCT tree, to slow down its growth. I wasn't too happy
about how selective the tree got with a long time to think, but it's
unclear if this particular hack had anything to do with that.
Álvaro.
On Mon, Jun 1, 20
25 matches
Mail list logo
