Jonas Kahn wrote:
out, kos can go on for long. I don't know what depth is attained in the
tree (by the way, I would really like to know), but I doubt it is that
MoGo displays the depth of the principle variation in the stderr stream.
___
computer-go
On Mon, Mar 10, 2008 at 02:33:03AM -0400, Michael Williams wrote:
Jonas Kahn wrote:
out, kos can go on for long. I don't know what depth is attained in the
tree (by the way, I would really like to know), but I doubt it is that
MoGo displays the depth of the principle variation in the stderr
On Mon, Mar 10, 2008 at 02:33:03AM -0400, Michael Williams wrote:
Jonas Kahn wrote:
out, kos can go on for long. I don't know what depth is attained in the
tree (by the way, I would really like to know), but I doubt it is that
MoGo displays the depth of the principle variation in the stderr
On Mon, 10 Mar 2008, Petr Baudis wrote:
MoGo displays the depth of the principle variation in the stderr stream.
I have been wondering, does that include _any_ nodes, or only these
above certain number of playouts? What is the playout threshold?
The 'principal variation' is usually the one
On Mon, Mar 10, 2008 at 01:03:02PM -0700, Christoph Birk wrote:
On Mon, 10 Mar 2008, Petr Baudis wrote:
MoGo displays the depth of the principle variation in the stderr stream.
I have been wondering, does that include _any_ nodes, or only these
above certain number of playouts? What is the
Hi,
On Sat, Mar 08, 2008 at 10:18:34AM +0100, Petr Baudis wrote:
(By the way, pachi1-*-light are UCT bots with completely light
playouts with various UCB1 c values, if anyone wants to use that as
reference. Surprisingly, it seems that my heavy playouts do not make big
difference so far,
On Mon, 10 Mar 2008, Petr Baudis wrote:
With 110k playouts per move and no domain knowledge in the playouts,
the ratings are now:
c=0.2 (pachi1-p0.2-light) ELO 1627 (285 games)
c=1.0 (pachi1-p1.0-light) ELO 1590 (120 games)
c=0.05 (pachi1-p0.05-light)
Petr Baudis wrote:
Hi,
On Sat, Mar 08, 2008 at 10:18:34AM +0100, Petr Baudis wrote:
(By the way, pachi1-*-light are UCT bots with completely light
playouts with various UCB1 c values, if anyone wants to use that as
reference. Surprisingly, it seems that my heavy playouts do not
On Mon, Mar 10, 2008 at 03:40:53PM -0700, Christoph Birk wrote:
On Mon, 10 Mar 2008, Petr Baudis wrote:
With 110k playouts per move and no domain knowledge in the playouts,
the ratings are now:
c=0.2 (pachi1-p0.2-light) ELO 1627 (285 games)
c=1.0 (pachi1-p1.0-light)
On Mon, Mar 10, 2008 at 06:57:07PM -0400, Don Dailey wrote:
I think you may still have a bug. You should get well over 1700 with
110,000 playouts, even if they are light playouts.
Hmmm... That is going to be some tough debugging I suspect.
I'm pretty sure my code is fairly well debugged
Petr Baudis wrote:
On Mon, Mar 10, 2008 at 06:57:07PM -0400, Don Dailey wrote:
I think you may still have a bug. You should get well over 1700 with
110,000 playouts, even if they are light playouts.
Hmmm... That is going to be some tough debugging I suspect.
I'm working on
Hi,
On Mon, Mar 10, 2008 at 08:07:14PM -0400, Don Dailey wrote:
What is the justification of using the parent playout count instead of
the node playout count itself?
I don't know if it makes much difference how this is done, and I don't
know how everybody else is doing it. I
On Tue, 11 Mar 2008, Petr Baudis wrote:
On Mon, Mar 10, 2008 at 06:57:07PM -0400, Don Dailey wrote:
I think you may still have a bug. You should get well over 1700 with
110,000 playouts, even if they are light playouts.
I will run myCtest with 110k-playout, c=0.25 and node creation
after the
On Mon, 10 Mar 2008, Christoph Birk wrote:
On Tue, 11 Mar 2008, Petr Baudis wrote:
On Mon, Mar 10, 2008 at 06:57:07PM -0400, Don Dailey wrote:
I think you may still have a bug. You should get well over 1700 with
110,000 playouts, even if they are light playouts.
I will run myCtest with
On Mon, Mar 10, 2008 at 05:36:14PM -0700, Christoph Birk wrote:
On Mon, 10 Mar 2008, Christoph Birk wrote:
On Tue, 11 Mar 2008, Petr Baudis wrote:
On Mon, Mar 10, 2008 at 06:57:07PM -0400, Don Dailey wrote:
I think you may still have a bug. You should get well over 1700 with
110,000
The key point, good or bad, is that I allocate all the legal children
nodes as a group.I manage my own memory pool and just hand out nodes
sequentially.I don't need to maintain pointers to each child, only a
single pointer to the first child. So instead of needing 4 extra bytes
per node
On Mar 10, 2008, at 8:07 PM, Don Dailey [EMAIL PROTECTED] wrote:
Some programs hash each position and the tree is more abstract, no
pointers just positions leading to other positions by zobrist hash
keys in a hash table.
My scheme probably wastes a lot of space on nodes that are left
17 matches
Mail list logo
