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.
_________________________________________________________________
Téléphonez gratuitement à tous vos proches avec Windows Live Messenger !
Téléchargez-le maintenant !
http://www.windowslive.fr/messenger/1.asp
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
