Dear Go programmers,
The 13th Computer Olympiad (CO) will be held from September 28 to
October 5 in Beijing, China.
This event will be held together with the Conference on Computers and
Games 2008 (CG 2008) (September 29 - October 1), and the 16th World
Computer-Chess Championship (WCCC)
I'm testing my bot on CGOS using pure UCT, no pondering, and 10,000
playouts per move. Can someone put up a comparable bot?
A while back, someone else made a similar request, and I discovered
that my bot had somehow broken. I've scoured for bugs and I believe I
have a functional
On May 13, 2008, at 7:25 AM, Jason House wrote:
I'm testing my bot on CGOS using pure UCT, no pondering, and 10,000
playouts per move. Can someone put up a comparable bot?
I will re-start 'myCtest-10k-UCT' later today.
Christoph
___
On Tue, May 13, 2008 at 1:04 PM, Jason House
[EMAIL PROTECTED] wrote:
[,,,]
I have a list of empty points. I pick one at random and then scan until I
find a legal one. Others reduce the list size (swap to end?) and repick.
What others do is the right thing to do. Your method will introduce
Christoph Birk wrote:
On May 13, 2008, at 10:04 AM, Jason House wrote:
On May 13, 2008, at 12:57 PM, Carter Cheng [EMAIL PROTECTED]
wrote:
I have a list of empty points. I pick one at random and then scan
until I find a legal one.
That's not random.
Yes, it's not random at all. The
On May 13, 2008, at 10:00 AM, Jason House wrote:
On May 13, 2008, at 12:00 PM, David Fotland [EMAIL PROTECTED]
games.com wrote:
When you say pure uct, what is the playout policy? Pure random
moves except
don't fill one point eyes?
That's exactly what I meant. I'd also assume other stuff
It's not clear how bad Jason's method is however. The points near the
end of the list are LESS likely to be chosen but probably not much less
likely and this method is probably pretty fast.I wonder how bad it
really is?
The point after an illegal move is quite a bit more likely to be
On 13-mei-08, at 14:10, Álvaro Begué wrote:
What others do is the right thing to do. Your method will introduce
some biases.
Could you elaborate what bias it could lead to? I also do the same as
Jason. I did consider the possibility of a bias but couldn't
immediately think of one.
What
On Tue, May 13, 2008 at 1:51 PM, Mark Boon [EMAIL PROTECTED] wrote:
On 13-mei-08, at 14:10, Álvaro Begué wrote:
What others do is the right thing to do. Your method will introduce
some biases.
Could you elaborate what bias it could lead to? I also do the same as Jason.
I did consider the
Hi Mark,
Did you read my last email post? Using Jason's method, the point
immediately AFTER an illegal point (perhaps an eye space) is TWICE as
likely to be selected because you are scanning sequentially forward.
Hitting on either point is going to lead to the same move selection.
Ooops! I hit sent before I finished writing the pseudo code. Sorry.
int pick(Move *empties, int num_empties) {
int num_candidates = num_empties;
int picked;
while(1) {
picked = rand()%num_candidates;
if(!acceptable(empties[picked])) {
num_candidates--;
On 13-mei-08, at 14:15, Don Dailey wrote:
Yes, it's not random at all. The points near the end of the list
are much less likely to be chosen for instance.
OK, I'm not very good at statistics, but I don't see how the last
points are much less likely to be picked. At best they are a
On May 13, 2008, at 1:51 PM, Mark Boon [EMAIL PROTECTED] wrote:
On 13-mei-08, at 14:10, Álvaro Begué wrote:
What others do is the right thing to do. Your method will introduce
some biases.
Could you elaborate what bias it could lead to? I also do the same
as Jason. I did consider the
On 13-mei-08, at 15:08, Jason House wrote:
The range of the random number is reduced by one after each failed
lookup. Shuffled data has no impact on future use of the array of
empty points.
OK, I understand now why a point at the end (or beginning) is a
little less likely to be
Mark Boon wrote:
On 13-mei-08, at 15:08, Jason House wrote:
The range of the random number is reduced by one after each failed
lookup. Shuffled data has no impact on future use of the array of
empty points.
OK, I understand now why a point at the end (or beginning) is a little
less
Don Dailey wrote:
Jason House wrote:
On May 13, 2008, at 1:51 PM, Mark Boon [EMAIL PROTECTED] wrote:
On 13-mei-08, at 14:10, Álvaro Begué wrote:
What others do is the right thing to do. Your method will introduce
some biases.
Could you elaborate what bias it could lead to? I also do
If this asymmetry really bothers you, you could very easily fix this by
wrapping the search around. There's no asymmetry in a circle.
That doesn't fix anything.
Why not? The whole argument is about a bias against points towards the
end. In a circular list there is no 'end'.
I missed
I don't care much about it being noticeable. This thread is about
putting bots on CGOS that use a reproducible algorithm, to help people
detect bugs in their implementations. As part of specifying what these
bots do, we should all pick the next move in a playout using the same
criteria. If we
On Tue, May 13, 2008 at 3:08 PM, Mark Boon [EMAIL PROTECTED] wrote:
On 13-mei-08, at 15:44, Álvaro Begué wrote:
On Tue, May 13, 2008 at 2:28 PM, Mark Boon [EMAIL PROTECTED]
wrote:
On 13-mei-08, at 15:08, Jason House wrote:
The range of the random number is reduced by one
On Tue, 13 May 2008, Mark Boon wrote:
If this asymmetry really bothers you, you could very easily fix this by
wrapping the search around. There's no asymmetry in a circle.
That doesn't fix anything.
Why not? The whole argument is about a bias against points towards the end.
In a circular
On 13-mei-08, at 16:17, Don Dailey wrote:
I missed this from you. I assumed that you did this anyway. If
you choose a random point and then traverse linearly to the end,
what do you do when you reach the end? Do you just pass?I
assumed you viewed the empty point list as a
Mark Boon wrote:
On 13-mei-08, at 16:17, Don Dailey wrote:
I missed this from you. I assumed that you did this anyway. If
you choose a random point and then traverse linearly to the end,
what do you do when you reach the end? Do you just pass?I
assumed you viewed the empty
For those currently coding this up, I think the most important thing about this
playout algorithm is that it is *temporary*. You will almost certainly
be?replacing it with something different and better just a little bit down the
road.
Creating an MC-UCT bot has a well worn path and its kind
Thanks for all the comments so far. Hopefully you don't mind a few more
questions.
1) Do UCT bots check for atari and urgency? my understanding was that first
generation Mogo did this to some extent IIRC. I am curious if anyone does this
it seems like it might be important but so far I cannot
[EMAIL PROTECTED] wrote:
For those currently coding this up, I think the most important thing about this
playout algorithm is that it is *temporary*. You will almost certainly
be?replacing it with something different and better just a little bit down the
road.
Creating an MC-UCT bot has a
On Tue, May 13, 2008 at 01:34:37PM -0400, Don Dailey wrote:
The point after an illegal move is quite a bit more likely to be
selected. If the list had just 1 illegal point, then the point after
it in the list is twice as likely to be selected as any other point.
Perhaps if you added a
Álvaro Begué wrote:
On Tue, May 13, 2008 at 4:22 PM, Carter Cheng
[EMAIL PROTECTED] wrote:
2) When generating random variables for the case where the values
of placing a stone on different points on the board are
different. Are there good ways to throw and determine which
point
This could be extended rather easily to an n-ary tree. With 9x9 a
natural choice is 3, but unfortunately 19 is prime.
It's basically a tradeoff between how many adds and how many compares
you want to do. I suppose you would do one update for every pick
(unless you pick an illegal point and want
On Tue, May 13, 2008 at 7:08 PM, Gunnar Farnebäck [EMAIL PROTECTED] wrote:
And I agree, don't even think of doing this with floating point
numbers.
This is a bit tangential to computer go. But you have piqued my curiosity
Offhand, that sounds rather extreme to me. Perhaps I haven't
On Tue, May 13, 2008 at 8:10 PM, Weston Markham
[EMAIL PROTECTED] wrote:
On Tue, May 13, 2008 at 7:08 PM, Gunnar Farnebäck [EMAIL PROTECTED] wrote:
And I agree, don't even think of doing this with floating point
numbers.
This is a bit tangential to computer go. But you have piqued my
Álvaro Begué: [EMAIL PROTECTED]:
Ooops! I hit sent before I finished writing the pseudo code. Sorry.
int pick(Move *empties, int num_empties) {
int num_candidates = num_empties;
int picked;
while(1) {
picked = rand()%num_candidates;
This code introduces few bias unless num_candidates is
31 matches
Mail list logo
