Quoting Peter Drake <[EMAIL PROTECTED]>:
I've noticed that Orego has done very poorly in the last couple of
competitions. This is partly due to the improvements in others'
programs, but I think the fact that Orego currently doesn't have a
transposition table is crippling. Since I'm rewriting this stuff in
Java, I'm thinking about how to handle this, and would like to offer
up the following plan for all of you to poke holes in. I'm not sure
if I'm reinventing the CrazyStone structure here, but I think this
one is slightly different.
I do not think a transposition table will make Orego much stronger, since
Valkyria seems to do fine without one. Maybe there will be a noticable speedup
but I think it may only become significant with very deep effective search
depths. I hope I am wrong because then I know a simple way to improve
Valkyria!
The interesting point is how to handle overwrites in the transpositions table,
there I cannot help you since I have not tried it myself. As I understand it
there is a tradeoff between shrinking the effective tree with transpositions
and not being able to expand the tree where collisions occur.
Valkyria quickly runs out of memory if it is allowed to think a litte
more than
about one minute. When this happens it makes a garbage collection by pruning
terminal leaves to free up nodes. Since the tree is explicit in memory it is
cheap to traverse the entire tree. This means that some information is
lost but
only at terminal leaves where it does not matter much. I fear that collisions
all over the tree in a transposition table might be a worse problem. Or
perhaps
it does not matter much as long as the nodes near the root are unaffected. It
will be interesting to see what you find out.
-Magnus
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
