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
N
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
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
>>
Assumming good_quality_int_rand() ranges [0..15] and N is 9, the
mapping is 0->0, 1->1, ..., 8->8, 9->0, ..., 15->6. This shows 0 to 6
have twice of the chance of 7 and 8. This is the bias caused by
the modulo operation.
In addition,
>multiplication + rounding.
may return N. Use trancate instea
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 random number ge
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 random number gener
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
AIL 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
Subject: R
CTED] <[EMAIL PROTECTED]> wrote:
>
> > From: [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-
> &g
.
--- On Wed, 5/14/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> From: [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-
>
> -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 cur
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 fu
Is it true that most programs using heavy playouts use a probability
distribution on the moves to pick the next move? I thought Mogo needed a
uniform distribution of nonlocal moves to make RAVE work well.
David
>
> But the problem is that when you do heavy playouts you have the same
> problem e
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 processo
How do L&D modules generally function? Is this discussed in the literature
somewhere? The only open source L&D 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 no
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
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 May 14, 2008, at 9:47 AM, "Norbert Gábor Papp" <[EMAIL PROTECTED]
m> 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 (in
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; i:
> That's a function of how smart your bot is. If you play until
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 strategy.
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 Pa
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
---
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/
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 proba
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;
> >
>
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_candidate
Á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_candi
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
illis
-Original Message-
From: Christoph Birk <[EMAIL PROTECTED]>
To: computer-go
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 the search arou
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
Sent: Tue, 13 May 2008 3:40 pm
Subject: Re: [computer-go] 10k UCT bots
On Tue, 13 May 2008, Mark
On May 13, 2008, at 3:20 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
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 sh
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 poi
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 circ
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 lis
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 numbe
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 a
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 thi
On May 13, 2008, at 3:02 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
Á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 after each failed
lookup.
Shuffled da
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 after each failed
lookup.
Shuffled data has no impact on future use of the array of
Á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 after each failed lookup.
Shuffled data has no impact on future use of the array of empty points.
OK, I und
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
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 lik
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 the same as
Jason. I
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 after each failed lookup.
> Shuffled data has no impact on future use of the array of empty points.
>
> OK, I understand now why
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 picked.
Mark Boon wrote:
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 be
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 pos
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
"l
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--;
swap(empties[picked],empt
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.
Occa
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 con
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
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
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 p
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 introduc
I think Christoph just described the eye rule most of us are using.
It's pretty much standard and I think it's mainly just a mechanism to
prevent the play-outs from going on and on for hundreds of moves.
You can probably improve on the rule, but this is probably not going to
make any
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.
Christoph
___
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 st
On May 13, 2008, at 12:57 PM, Carter Cheng <[EMAIL PROTECTED]>
wrote:
I am curious about the eye rule situation since I am at that stage
of my implementation of the board/playout code. currently I have
only implemented the basic rules of the game so that no illegal
moves are possible (no
y 13, 2008 8:51 AM
To: computer-go
Subject: Re: [computer-go] 10k UCT bots
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
I am curious about the eye rule situation since I am at that stage of my
implementation of the board/playout code. currently I have only implemented the
basic rules of the game so that no illegal moves are possible (no superko rule)
but undesirable stuff like filling your own eye spaces still ar
On May 13, 2008, at 9:00 AM, David Fotland wrote:
When you say pure uct, what is the playout policy? Pure random
moves except
don't fill one point eyes?
Yes.
What's your eye rule?
all four neighbors occupied by "my" stones and not more 1 diagonal
occupied by opponent (center) or no diag
, May 13, 2008 8:51 AM
> To: computer-go
> Subject: Re: [computer-go] 10k UCT bots
>
>
> 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
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
___
computer-g
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 implementat
65 matches
Mail list logo
