What I did (was a long time ago, I don't know if it is still used in
Mogo), is to compute the m best moves every so often and most of the
time just do the max over those m moves.
m was on the order of 5, and every so often was an increasing
function like sqrt or log (I don't remember).
That speeds
On Wed, Dec 3, 2008 at 05:17, Mark Boon [EMAIL PROTECTED] wrote:
I had set myself as an arbitrary goal that it should do at least 20K
playouts. But with real liberties, AMAF and a RAVE formula I got stuck in
the 16K-17K range. According to my profiler that is mostly due to the
expensive
On 3-dec-08, at 06:09, Sylvain Gelly wrote:
What I did (was a long time ago, I don't know if it is still used in
Mogo), is to compute the m best moves every so often and most of the
time just do the max over those m moves.
m was on the order of 5, and every so often was an increasing
function
On Wed, Dec 03, 2008 at 09:55:07AM -0200, Mark Boon wrote:
I thought about that, but I was afraid the code would become too
obscure. After all, this is supposed to be a reference
implementation. But maybe I should actually give it a try to see what
it would look like.
I agree that the
On 3-dec-08, at 10:31, Heikki Levanto wrote:
Having said that, I can't help responding to one detail:
I had seen people write about memory usage of the tree, but never
understood the concerns.
One thing to remember is that more memory use means more cache
misses, and
more access to the
On Wed, Dec 03, 2008 at 11:24:22AM -0200, Mark Boon wrote:
Heikki wrote:
One thing to remember is that more memory use means more cache misses,
and more access to the main memory. On modern computers, those can cost
as much as executing a thousand instructions! So memory optimizing can
I had a chess program years ago that was blindingly fast on some
computers, very slow on others. It was all about the cache. The move
generator was hard coded for each piece on each square. For instance a
white pawn on d7 had it's very own move specialized move generator.
There was a function
On Wed, 2008-12-03 at 11:24 -0200, Mark Boon wrote:
If this is because I use Java, then
Don's concise C implementation of the MC-AMAF bot should be a lot
faster than my bloated Java version.
I don't remember the numbers, but my own java and C implementation were
written in the same style -
Mark Boon wrote:
Yes, I asked that question.
So GnuGo already uses a comment-node to store the information in the SGF
tree. But twogtp uses information from the .tst file. So why the
difference?
No, GNU Go does not put the tests in the sgf files. We did so for a
short while long ago, but it
