I'm testing a future Anchor player for CGOS. I am calling
it FAT for Future Anchor Test!
It plays fixed depth and I pre-calculated what level to make
it play at 1800 strength. I came pretty close, Fat-25 is
playing at 1836 at the moment and doesn't require too much
CPU power. It's Lazarus
On Mon, 2007-03-19 at 22:45 -0400, John Tromp wrote:
> dear Don,
>
> > Crazy me. I just remembered why my numbers are not matching. I forgot
> > that what I call the lite play-out version is not random. It's mostly
> > lite but it favors capture moves.
>
> Yes, I can see how that will shorten
dear Don,
Crazy me. I just remembered why my numbers are not matching. I forgot
that what I call the lite play-out version is not random. It's mostly
lite but it favors capture moves.
Yes, I can see how that will shorten the games somewhat...
Is it easy to temporarily turn off that bias?
-
Crazy me. I just remembered why my numbers are not matching. I forgot
that what I call the lite play-out version is not random. It's mostly
lite but it favors capture moves.
- Don
On Mon, 2007-03-19 at 15:57 -0400, [EMAIL PROTECTED] wrote:
> Here are some numbers from AntIgo. Alvaro's s
Here are some numbers from AntIgo. Alvaro's suggestion seems like a good
one-we're almost there anyway. (I'm not in favor of permitting suicide, but
that's a minor detail.)
I lose a lot more time in UCT than Don does. I think his data structures
are nicer than mine. I haven't tried the
On Mon, 2007-03-19 at 09:54 -0400, John Tromp wrote:
> hi Don,
>
> > > Are you trying to make a Monte Carlo program?
>
> Guilty:-)
> Since about a week and a half, me and my colleague Alvaro Begue are
> working on a Go program, which (like many others) wil try to imitate
> Mogo's success...
I ex
UCT-MC performed better on CGOS is also due to the fact that the depth of the
game and the branch factor is much larger.
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Mon, 19 Mar 2007 9:00 AM
Subject: [computer-go] UCT performance
I'm reading the p
I'm reading the paper by Kocsis and Szepesvari. From Figure 2 the significant
imporvement of UCT over alpha-beta happens when the error tolerance is about
10%, where the improvement is a factor of 100. From the results of CGOS UCT-MC
performed seemly better than this. It's propabaly due to the r
hi Don,
> Are you trying to make a Monte Carlo program?
Guilty:-)
Since about a week and a half, me and my colleague Alvaro Begue are
working on a Go program, which (like many others) wil try to imitate
Mogo's success...
regards,
-John
___
computer-
Sensei and Wikipedia serve somewhat different purposes and I
believe they should both be kept up to date.
I don't believe the detail of Sensei's Library should be
covered by Wikipedia. If I first wanted to get acquainted
with some subject I might look it up in an encyclopedia to
get an overvie
Peter Christopher wrote:
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
On Mon, 2007-03-19 at 07:42 -0400, Álvaro Begué wrote:
> Hi, everyone. This is my first post to the list.
>
> Beginning chess programmers have something called "perft" at their
> disposal, which is just a count node of a search tree of fixed depth,
> with no prunning whatsoever and no extensions.
Hi, everyone. This is my first post to the list.
Beginning chess programmers have something called "perft" at their
disposal, which is just a count node of a search tree of fixed depth,
with no prunning whatsoever and no extensions. It's easy to detect
errors in your move generation or do/undo fu
My thoughts about average moves is directly related to
the move selection algoritm you use.
Using totally random move generator, I'm sure
everybody should get the same average of moves.
But using diferent heuristics in order to get not 'so'
random moves (i.e. ataries getting double possibility,
p
14 matches
Mail list logo