I think the general distaste for modulo is based on the historical tendency for
the low-order bits to be less random than the high-order bits.
Hideki Kato wrote:
Thank you for detailed explanation. I've understood well now.
It's essentially the mapping problem from [0..N) to [0..M) where
I wrote:
Hideki Kato wrote:
Gunnar Farnebäck: [EMAIL PROTECTED]:
Hideki Kato wrote:
I didn't against you, Álvaro, rather I just made a caution for
programmers who will use your pseudo code as is. :)
First, I prefer SFMT (SIMD-oriented Fast Mersenne Twister) rather
than integer pseudo
Thank you for detailed explanation. I've understood well now.
It's essentially the mapping problem from [0..N) to [0..M) where
N M and N % M != 0 or N is greater than M and M don't divide N.
The frequencies of the mapping have to have the least difference, one
(unless discarding extra part of
Hideki Kato wrote:
I didn't against you, Álvaro, rather I just made a caution for
programmers who will use your pseudo code as is. :)
First, I prefer SFMT (SIMD-oriented Fast Mersenne Twister) rather
than integer pseudo random number generators in practice where the
quality of play-out is
I was waiting for this one... :)
Joel
On Wed, May 14, 2008 at 1:57 PM, Hideki Kato [EMAIL PROTECTED] wrote:
Á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 =
On Tue, May 13, 2008 at 11:57 PM, Hideki Kato [EMAIL PROTECTED] wrote:
Á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) {
Don Dailey wrote:
[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. So you
Hi!
Can you tell me some algorithm to compute the score ? (Both players pass,
and who is the winner...)
Thanks, Norbert
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
This probably explains it better than I could:
http://senseis.xmp.net/?TrompTaylorRules
- Don
Norbert Gábor Papp wrote:
Hi!
Can you tell me some algorithm to compute the score ? (Both players pass,
and who is the winner...)
Thanks, Norbert
That's a function of how smart your bot is. If you play until you only
have eye-filling moves, you can safely assume all of your opponent's
stones are alive, all your groups with two eyes are alive, and
everything else is dead. Note the asymetry - your opponent may use a
different
Thanks! How can I identify dead stones?
I haven't seen algorithm for this, and it is a very important part of
a go program
2008/5/14, Don Dailey [EMAIL PROTECTED]:
This probably explains it better than I could:
http://senseis.xmp.net/?TrompTaylorRules
- Don
Norbert Gábor Papp wrote:
Thanks for your fast reply,but sorry, I don't really understand this...
The situation - both player pass, end of the game, I need the score.
I want to remove dead-stones which means :
if (IsGameEnded) {
for (int i=0, int ,j=0; itable.sizeX,ytable.sizeZ;i++,j++){
if dead(i,j)
{
On Wed, May 14, 2008 at 03:47:55PM +0200, Norbert Gábor Papp wrote:
I want to remove dead-stones which means :
[...]
I'm interested in the function dead(), which is true when a stone is dead
after both player pass,and the game is ended.
The simple answer is that there is no such function!
On Wed, May 14, 2008 at 10:12 AM, Heikki Levanto [EMAIL PROTECTED] wrote:
On Wed, May 14, 2008 at 03:47:55PM +0200, Norbert Gábor Papp wrote:
I want to remove dead-stones which means :
[...]
I'm interested in the function dead(), which is true when a stone is dead
after both player pass,and
How do LD modules generally function? Is this discussed in the literature
somewhere? The only open source LD module I am aware of is the one in GNU-go
and I am not certain how good or bad it is since my own playing strength isn't
that good. I have found some papers on this topic but most do not
I didn't against you, Álvaro, rather I just made a caution for
programmers who will use your pseudo code as is. :)
First, I prefer SFMT (SIMD-oriented Fast Mersenne Twister) rather
than integer pseudo random number generators in practice where the
quality of play-out is important. Modern
Norbert Gábor Papp wrote:
Thanks for your fast reply,but sorry, I don't really understand this...
The situation - both player pass, end of the game, I need the score.
I want to remove dead-stones which means :
There is no known perfect algorithm for doing this in every case and
it's a
-Original Message-
From: Jacques Basaldúa [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Wed, 14 May 2008 6:38 am
Subject: Re: [computer-go] 10k UCT bots
Don Dailey wrote:
[EMAIL PROTECTED] wrote:
For those currently coding this up, I think the most important
: [EMAIL PROTECTED] [EMAIL PROTECTED]
Subject: Re: [computer-go] 10k UCT bots
To: computer-go@computer-go.org
Date: Wednesday, May 14, 2008, 10:44 AM
-Original Message-
From: Jacques Basaldúa [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Wed, 14 May 2008 6:38 am
: Re: [computer-go] 10k UCT bots
To: computer-go@computer-go.org
Date: Wednesday, May 14, 2008, 10:44 AM
-Original Message-
From: Jacques Basaldúa [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Wed, 14 May 2008 6:38 am
Subject: Re: [computer-go] 10k UCT bots
Don Dailey 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?
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
probably don't want to worry about hair-splitting tweaks except as an
academic exercise.
- Dave Hillis
-Original Message-
From: Christoph Birk [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Tue, 13 May 2008 3:40 pm
Subject: Re: [computer-go] 10k UCT bots
On Tue, 13 May
-Original Message-
From: Christoph Birk [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Tue, 13 May 2008 3:40 pm
Subject: Re: [computer-go] 10k UCT bots
On Tue, 13 May 2008, Mark Boon wrote:?
If this asymmetry really bothers you, you could very easily fix this by?
wrapping
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é: [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
45 matches
Mail list logo
