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 st
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 t
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
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) ELO
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 d
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-ligh
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 debug
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 w
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.
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 110k-
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
On Tue, 11 Mar 2008, Petr Baudis wrote:
BTW: I count the new-node threshold like Don from the parent
node, so 50 not far from your '2'.
Hmm, I really wonder where this comes from, the idea seems quite
unnatural to me.
Well, child-nodes are created by the parent. The parent keeps
a count
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 f
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
un
16 matches
Mail list logo
