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,
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
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. It's
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
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
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
___
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
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
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 expect your
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
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?
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
12 matches
Mail list logo
