On Thu, Jul 2, 2009 at 7:20 PM, Peter Drake dr...@lclark.edu wrote:
Okay, so I've finally built a transposition table. There is a big pool of
nodes, allocated at startup. To find a node, I:
1) Play the move on the board and get the new Zobrist hash (incorporating
the simple ko point and
It seems that every Go study notes the importance of distance to the last
move as a predictor. Several heuristic measures of distance have been
proposed in the literature. I tested three:
1) The Manhattan distance dx+dy.
2) dx + dy + max(dx,dy), which is Manhattan plus a term that
Considering that memory keeps getting cheaper, would it make sense to
dynamically choose how much space to use?
Nowadays most new computer purchasers start with 2 GB, and go up from there.
Terry McIntyre terrymcint...@yahoo.com
“We hang the petty thieves and appoint the great ones to
The problem with making it dynamic with respect to how much memory is
available is that this does not play well with other software. Since
modern operating systems are designed for multiple processes, you don't want
the amount allocated to be a function of which program got loaded first.
Can
Okay, I've almost got it.
I'm also looking into implementing a transposition table. Some things
are still unclear to me.
If you're hashing by chaining, you presumably go to the appropriate
slot in the table, then traverse the (short) linked list of nodes
hanging from that slot. If the
On Fri, Jul 3, 2009 at 7:28 PM, Ray Tayekrta...@ca.rr.com wrote:
please join us for an afternoon of surf, sand, and go.
saturday, august 22'nd 2009, from 11 a.m. to 6 p.m or so, at 26918 malibu
cove colony drive
Sounds good. If the earth wasn't curved maybe we could wave at each other :)
I have a really basic question about how MC works in the context of Go.
Suppose the problem is to make the first move in a game, and suppose we
have accepted as a constraint that we will abstain from just copying
some joseki out of a book -- we are going to use MC to figure out the
first move de
Fred Hapgood wrote:
I have a really basic question about how MC works in the context of Go.
Suppose the problem is to make the first move in a game, and suppose we
have accepted as a constraint that we will abstain from just copying
some joseki out of a book -- we are going to use MC to figure
I think he is missing the tree search part. Just doing a one-ply
lookahead and then doing playouts will not make a strong bot. I would
like to defer an explanation of UCT (or something else) to someone who
is more of an expert.
- George
On Mon, Jul 6, 2009 at 8:25 PM, Raymond
That's the beauty of MC! It really is a beautiful system. Initially, they were totally random playouts. But the more powerful MC Go engines do not do
completely random playouts; they do heavy playouts. But if you were to look at a heavy playout, it would still look like a very weak Go
George Dahl wrote:
I think he is missing the tree search part. Just doing a one-ply
lookahead and then doing playouts will not make a strong bot. I would
like to defer an explanation of UCT (or something else) to someone who
is more of an expert.
UTC would add little if MC itself were not a
On Jul 6, 2009, at 9:26 AM, Isaac Deutsch wrote:
If you're hashing by chaining, you presumably go to the appropriate
slot in the table, then traverse the (short) linked list of nodes
hanging from that slot. If the node you want isn't present, though,
you have to find another node you can
Well, there is one slight catch...
Nodes do not contain pointers to their children. To find the node
after making a move, I make the move on the board, then use the
Zobrist hash of the new board as a key to search for the child node in
the hash table. So traversing the tree would involve
I thought you had really heavy nodes? Like 1k bytes or so? But no 8 byte
pointers to children?
Peter Drake wrote:
Well, there is one slight catch...
Nodes do not contain pointers to their children. To find the node after
making a move, I make the move on the board, then use the Zobrist
Correct. Following David Fotland's suggestion, each node contains
arrays of the run and win counts of its (potential) children. This
way, searching the children of a node does not cause a cache miss.
When using RAVE (on which I'm still working), I also need arrays for
RAVE runs and counts
15 matches
Mail list logo
