How much improvement should one see in a UCT program after adding a
transposition table?
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
On 5/11/07, Chris Fant [EMAIL PROTECTED] wrote:
How much improvement should one see in a UCT program after adding a
transposition table?
Hard to say in general because this depends on how deep the tree goes,
the allocated search time, etc. For shallow trees I suspect that you
might even play
I didn't notice much improvement in Orego, because the tree is pretty
shallow. Of course, now that I've made speed improvements to the
program (and bought a faster computer), and now that I understand the
sum-of-children thing, the rules may have changed...
Peter Drake
When you say transposition tables I assume you mean structuring the
tree as a hash table instead of a tree with pointers.
I have done both, but currently Lazarus does the tree for several
reasons. I do not claim it's better either way.
Here are the problems with hash tables as a tree:
1.
Going along with this, the numbers won't add up (although I don't know
if that is important.) In other words, if you do 10,000 simulations at
the root, all grandchildren will add up to more (due to transpositions.)
If you propogate this up the tree you might come up with many more than
10,000
On May 11, 2007, at 9:20 AM, Don Dailey wrote:
Going along with this, the numbers won't add up (although I don't know
if that is important.) In other words, if you do 10,000
simulations at
the root, all grandchildren will add up to more (due to
transpositions.)
If you propogate this up
On 5/11/07, Brian Slesinsky [EMAIL PROTECTED] wrote:
Going along with this, the numbers won't add up (although I don't know
if that is important.) In other words, if you do 10,000 simulations at
the root, all grandchildren will add up to more (due to transpositions.)
If you propogate this
Yes,
Jason expresses my very concern about the hash table approach. I feel
that is technically wrong, but it's not clear to me whether it's the
type of problem that will have a large impact on performance.
Lazarus tries to be a KISS program, so I took the easy way out and kept
it real
On 5/11/07, Jason House [EMAIL PROTECTED] wrote:
On 5/11/07, Brian Slesinsky [EMAIL PROTECTED] wrote:
Going along with this, the numbers won't add up (although I don't know
if that is important.) In other words, if you do 10,000 simulations at
the root, all grandchildren will add up to
On 5/11/07, Álvaro Begué [EMAIL PROTECTED] wrote:
On 5/11/07, Jason House [EMAIL PROTECTED] wrote:
On 5/11/07, Brian Slesinsky [EMAIL PROTECTED] wrote:
Going along with this, the numbers won't add up (although I don't know
if that is important.) In other words, if you do 10,000
CGOS has been having a lot of trouble over the last few days and I am
looking into it.
It appears that there may be a physical problem with the disk array that
boardspace uses - still checking into this and other things.
CGOS may be down for a while so please bear with me. I'll let you know
On 5/11/07, Jason House [EMAIL PROTECTED] wrote:
Consider a node who's had one child extensively evaluated through
transpositions. When UCT does come to visit it, the sqrt(sum(child
simulations)) will be very high. That will artificially favor exploration
of children with less simulations.
12 matches
Mail list logo
