On 21-nov-08, at 09:34, Denis fidaali wrote:
I think that most people trying go-programming will try at least
to experiment once with UCT.
The first logical step, is to build an amaf-bot. The other logical
step, is to build a UCT bot. That's exactly the path i followed.
And i bet many others have done that too. So it may be guessed that
many more will do so. I feel that the most important thing is to be
able to be rightly confident that the implementation is roughly
right. It's true that an implementation can also serves as a basis
for something else. But that will not be possible if you can't get
a strong confidence that it is rightly done.
So i guess that you should keep things as simple as you can in
your reference-implementation. Litles tweaks will be easily doable
after you get the specification understandable once. For exemple, i
do not think that the "explore the pass" lines are a must have. You
can test an UCT implementation that never pass as long as there are
"valid" moves left. (valid in the sense nor suicide, nor pseudo-
eyes). That's simple. And yet i think the program can play strongly
enougth (given enougth simulations are made - Say 50 000).
UCT has many constants built in. (By the way, i don't really
understand those 2 and 10 factors. Wouldn't that go in the
exploration-factor ?? as *sqrt(1/5) ). I guess that any value would
be good enougth, as long as it makes the behavior of the bot rather
clear. So other people can adjust this factor, and compare their
results. If later on, after the implementation has cought some
attention, if one value get to be known as better, it'll still be
time to put it in. It probably won't be a big fuss to adjust
anyone's implementation to it anyway. You have to set up a
conventionnal value that people can use as a reference, be it bad.
SO 1.0 (or sqrt(1/5) would be Okay i suppose).
I don't think that wasting simulations in the end-game is really a
problem for a reference implementation.
The main problem i spot, is that you may need a fair number of
simulations, to get some inter implementations reproducible data.
Not everyone will be able or willing to put so much computing power
to that usage. But even then, to have a reference specification
will never be a loss. Especially once the AMAF-reference-
specification start to get it's own pages (if it's not already the
case : i have always have great trouble to track out all the links.
Maybe it would be good to put it as a CGOS partner or something :)
Then all people have to know is where to find CGOS. So the goal of
the UCT-reference would be to be presented along with the AMAF-
reference, with all the data that has been collected about how to
make "sure" that one implementation behavior is correct. And also
maybe, along with some popular boost (like the weight for the AMAF-
ref), or a Basic way of making RAVE work with it. But that'll be
later.
Denis,
I agree with most of what you write. But there's a bit of friction
between two of the goals. On the one hand a reference implementation
is ideally as simple as possible. On the other hand you need to take
limited computing power into account for testing. For testing new
ideas you want your base-line (which will be something similar to the
reference-bot) to have as good a strength/CPU-time ratio as possible.
The simplest and cleanest would be a UCT-search without AMAF (or
RAVE). But if it turns out AMAF would give a big boost in strength
for virtually the same performance I think it should be considered.
In my search implementation AMAF adds something like 20-30 lines of
code in a single place, so the impact on the complexity is not so
large. So far I'm still testing whether AMAF actually adds much or
not. But if it turns out it doesn't it will be easy to remove.
With regards to the formula sqrt( 2 * (log(parent-visits) / (10*
visits)) I admit I simply copied it from somewhere and never properly
thought about it. so you're correct that in fact I'm using a
exploration-factor of sqrt(1/5) instead of 1.0. I'll modify my code
to make this more clear.
Mark
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
