On Sat, Mar 17, 2007 at 02:12:21PM -0700, Christoph Birk wrote:
>
> On Sat, 17 Mar 2007, Chris Fant wrote:
> >What does that have to do with it? My engine does not play
> >multi-stone suicides, it only allows them in the playouts. As a
> >result, it plays stronger. This is desirable, no?
>
> I
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 Anch
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 same way as cgos? I would like to see
what my MC does on a lar
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 th
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 fr
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 accu
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 ratin
Just curious: in the playout, what happens when you allow it to play a
multi-stone suicide? Does the group die, or do the stones remain on
the board with no liberties? What happens to the final score?
Group dies. I don't know what you mean about final score. It's
Chinese scoring.
___
On Sun, 2007-03-18 at 10:48 -0400, [EMAIL PROTECTED] wrote:
> There is the possibility of more than one anchor.
At the moment, CGOS doesn't support more than 1 anchor player,
but that is easily solved.
However, I am in the testing stage of a new CGOS server. It
does support as many anchors as yo
Hi Sylvain,
I think what you are looking isn't a strong Anchor player, but
strong players who are always available.
However, I do want to upgrade the Anchor player too, perhaps putting
up 2 Anchors. I will prepare a version of Lazarus - it will take a
few days. I'm not sure what my goal rating
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 would be a player with
fixed strength, always connected. It is an
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 3/18/07, Peter Christopher <[EMAIL PROTECTED]> wrote:
Hi,
I plan to do some basic work documenting libego. My plan is as follows.
1) I will write what I have figured out and also the open issues on
the sensei.xmp.net wiki. Anyone else obviously welcome to contribute,
especially fix my erro
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,
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 prud
I fully agree with your plan. Merging it all onto wikipedia seems like a
good plan to me. Certainly forwarding the others is a must too.
On 3/18/07, Peter Christopher <[EMAIL PROTECTED]> wrote:
Taking a look at computer go documentation, I see that there are (at
least) three pages that exist
I've seen the number 107.3... reported earlier
for the average length, without the 2 final passes.
Is this allowing multi stone suicides or not?
And what's the outcome in the other case?
Thanks!
regards,
-John
___
computer-go mailing list
computer-go@c
I think they serve different purposes. Wikipedia has its "no original
research" policy meaning that theoretically everything in a Wikipedia
article should be backed up by a citation. That's certainly not true
now, but it should be a goal. So it seems like there will be lots of
details (such as
On Sun, 2007-03-18 at 22:33 -0400, John Tromp wrote:
> I've seen the number 107.3... reported earlier
> for the average length, without the 2 final passes.
> Is this allowing multi stone suicides or not?
> And what's the outcome in the other case?
> Thanks!
This does not allow multi-stone suicide.
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 whic
24 matches
Mail list logo
