Quoting Don Dailey [EMAIL PROTECTED]:
Do you think any version of gnugo is suitable as an anchor?
My problem with Gnugo is that it might be too deterministic. It is in general
easier to overfit the parameters to gnugo than an MC-program. But perhaps the
gnugo team could make a version that at
Hello Don, Nick, Magnus,
I here answer the 3 previous emails.
2007/3/18, Don Dailey [EMAIL PROTECTED]:
Another possible candidate is Mogo, running at 3K play-outs, like the
version running on CGOS right now.
I thought about that, the good thing is the resources taken (between
0.6 and 0.3 s
I'm not so sure we need to have a really strong Anchor. The Anchor's
role is to prevent rating drift over the long term.It I turned
CGOS lose without any anchor, it could inflate or deflate over time
and that was the only reason I wanted to have an anchor.
However, it makes sense for an
Hello Heikki,
2007/3/18, Heikki Levanto [EMAIL PROTECTED]:
On Sun, Mar 18, 2007 at 01:09:27PM +0100, Sylvain Gelly wrote:
There is also the perspective of the 13x13 and 19x19 servers where (1)
gnugo will be much stronger, (2) we can have easily handicaps.
Where are those? Are they used the
2007/3/18, Don Dailey [EMAIL PROTECTED]:
I'm not so sure we need to have a really strong Anchor. The Anchor's
role is to prevent rating drift over the long term.
You are right about this Anchor's role. However, to be able to
accurately rate players, there is a need of opponents not too far
UCT, alpha-beta, Monte-Carlo, and many others (not related to game playing) are
all methods of optimization. In college we all did it countless times to find
the maximum or minimum of a function. It's the simplest form of optimization.
In an optimization two things are usually required: the
There is the possibility of more than one anchor.
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Sun, 18 Mar 2007 7:42 AM
Subject: Re: Re:[computer-go] MoGo
I'm not so sure we need to have a really strong Anchor. The Anchor's
role is to prevent
Hi,
On 3/17/07, Peter Christopher [EMAIL PROTECTED] wrote:
Hi LL or any others who know,
I've been playing with libego. Nice work, thanks for distributing it.
I am working on understanding some of the details of uct.cpp, in
particular how it does playouts in life-death and ko situations. I
On Sun, 2007-03-18 at 19:09 +0100, Sylvain Gelly wrote:
Hi Don,
I think what you are looking isn't a strong Anchor player, but
strong players who are always available.
In some sense you are right. In fact, I was not talking about anchor
with fixed rating, but floating anchor, which
Taking a look at computer go documentation, I see that there are (at
least) three pages that exist in wiki format for top level computer go
wiki pages-
wikipedia.org - computer go
sensei - computer go
sensei - computer go programming
It seems obvious that these are redundant. It seems
heavy playouts should yeild a lower number of moves because moves are
slightly more efficient bringing the end of the game sooner. I'm actually
surprised it isn't a larger difference.
On 3/18/07, Don Dailey [EMAIL PROTECTED] wrote:
On Sun, 2007-03-18 at 22:33 -0400, John Tromp wrote:
I've
On Sun, 2007-03-18 at 22:34 -0500, Nick Apperson wrote:
heavy playouts should yeild a lower number of moves because moves are
slightly more efficient bringing the end of the game sooner. I'm
actually surprised it isn't a larger difference.
I never tested it until now - but I expected it to
John,
Did that 107.3 number come from me? I seem to remember
that I used to get that - if I'm remembering correctly.
But I remember making a little change, that addressed
what appeared to be a minor implementation bug. One
of the speed enhancements is to put away moves you
already tried which
13 matches
Mail list logo
