Re: [computer-go] Suicide question

[Don Dailey]

Michael Williams wrote:
> It is a very nice graph.  I wish we could see the next 11 doublings.

You and me both!   

Just a couple of other comments:

The graph was smoothed with gnuplot's smooth bezier function - but the
raw graph looks very similar - just a little more jagged.

If you straighten out the line - you get about 160 ELO per doubling, 
just looking at the graph.   This is being a bit conservative and
rounding down. I am pretty confident that you would continue to get
well over 100 per doubling for many more doublings and that this curve
would gradually taper off. 

I am also confident that if we could run this at 5 or 6 more doublings
and play 9x9 matches and this could be done at a reasonable time
control,the program would give high dan players a difficult
time.   This is one of those claims that sounds ludicrous to most
players probably.   But when chess programs were only 2000 ELO
strength,  projections were made about what it would take to play
grandmaster strength.   Those projections were laughed at because nobody
believed such a silly thing could happen,  but if anything the
projections were conservative and by no means exaggerated.It
actually happened very quickly due to Moores law.The programs
responded dutifully to each new generation of computer with about 80 ELO
per doubling or so.

Computers are now our masters in chess - matches are only given now with
handicaps so that the humans will have a chance. The big surprise is
that a doubling is STILL worth about 60 ELO points,   the curve seems to
be tapering off but it's very gradual. I expect exactly the same in
computer go. This assumes the laws of physics and our ingenuity can
keep Moores law working for a few more doubling's! 

I also did enough of a study on 19x19 UCT GO programs to see that the
improvement is substantial.   It seems to be at least as much as in
9x9. I don't expect the 19x19 curve to taper off for a very long
time and I am confident that if Moores law can hang on for just a few
more years,   we will also be seeing at least mid dan go programs
playing 19x19 Go in a few years - assuming they are playing about 3 kyu
now and don't improve.  

Of course a little ingenuity on our part could speed this up!

- Don





>
>
> Don Dailey wrote:
>> I found the graph,  but I can't find the data and the details,  although
>> it will be on one of the postings.  I think this was at least a year
>> ago, perhaps 2.  
>> Here is what I remember:
>>
>> I played 11 different levels,  each a doubling of the previous.   The
>> weakest level I think was just 1024 play-outs.I ran the study for
>> weeks in order to get substantial data points even from the highest
>> levels.The highest level,  took a significant time to play a single
>> game,  several times longer than the CGOS time control which was 10
>> minutes at the time. 
>> The conditions were CGOS 9x9 conditions - komi 7.5,  and so on, just
>> like CGOS 9x9.
>>
>> I actually tested 2 basic versions,  one with heavy play-outs and one
>> with light play-outs.   The light play-out version basically plays
>> random games.
>>
>> Both programs were reasonably strong UCT programs - versions of Lazarus
>> which probably would play at least 2100 strength on my current computer
>> on the current 5 minute server. 
>> See if this link works to see the graph:
>>
>> http://greencheeks.homelinux.org:8015/~drd/study.jpg  
>> The X axis represents the number of doublings and ELO ratings are on the
>> Y axis.
>>
>> - Don
>>
>>
>>
>>
>>
>>
>> Michael Williams wrote:
>>> Don Dailey wrote:
 Mark,

 I wasn't stating a precise value for a doubling when I said 100
 ELO.But it appears that it is actually worth a bit more than 100
 ELO for a
 doubling.I did a massive study of this at one point a year or
 more ago with thousands of games with UCT based Lazarus program and
 the
 strength improvement per doubling was very  clear and impressive.
>>> Don, what komi did you use when you did that study?  Looking in the
>>> archives, all I can find is you saying that komi=9 is correct.  So
>>> does that mean 8.5 or 9.5?  Or did you allow draws?
>>>
>>> ___
>>> computer-go mailing list
>>> computer-go@computer-go.org
>>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>>
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[Michael Williams]

It is a very nice graph.  I wish we could see the next 11 doublings.


Don Dailey wrote:

I found the graph,  but I can't find the data and the details,  although
it will be on one of the postings.  I think this was at least a year
ago, perhaps 2.   


Here is what I remember:

I played 11 different levels,  each a doubling of the previous.   The
weakest level I think was just 1024 play-outs.I ran the study for
weeks in order to get substantial data points even from the highest
levels.The highest level,  took a significant time to play a single
game,  several times longer than the CGOS time control which was 10
minutes at the time.  


The conditions were CGOS 9x9 conditions - komi 7.5,  and so on, just
like CGOS 9x9.

I actually tested 2 basic versions,  one with heavy play-outs and one
with light play-outs.   The light play-out version basically plays
random games.

Both programs were reasonably strong UCT programs - versions of Lazarus
which probably would play at least 2100 strength on my current computer
on the current 5 minute server.  


See if this link works to see the graph:

http://greencheeks.homelinux.org:8015/~drd/study.jpg   


The X axis represents the number of doublings and ELO ratings are on the
Y axis.

- Don






Michael Williams wrote:

Don Dailey wrote:

Mark,

I wasn't stating a precise value for a doubling when I said 100
ELO.But it appears that it is actually worth a bit more than 100
ELO for a
doubling.I did a massive study of this at one point a year or
more ago with thousands of games with UCT based Lazarus program and the
strength improvement per doubling was very  clear and impressive.

Don, what komi did you use when you did that study?  Looking in the
archives, all I can find is you saying that komi=9 is correct.  So
does that mean 8.5 or 9.5?  Or did you allow draws?

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/


___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/



___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[Don Dailey]

I found the graph,  but I can't find the data and the details,  although
it will be on one of the postings.  I think this was at least a year
ago, perhaps 2.   

Here is what I remember:

I played 11 different levels,  each a doubling of the previous.   The
weakest level I think was just 1024 play-outs.I ran the study for
weeks in order to get substantial data points even from the highest
levels.The highest level,  took a significant time to play a single
game,  several times longer than the CGOS time control which was 10
minutes at the time.  

The conditions were CGOS 9x9 conditions - komi 7.5,  and so on, just
like CGOS 9x9.

I actually tested 2 basic versions,  one with heavy play-outs and one
with light play-outs.   The light play-out version basically plays
random games.

Both programs were reasonably strong UCT programs - versions of Lazarus
which probably would play at least 2100 strength on my current computer
on the current 5 minute server.  

See if this link works to see the graph:

http://greencheeks.homelinux.org:8015/~drd/study.jpg   

The X axis represents the number of doublings and ELO ratings are on the
Y axis.

- Don






Michael Williams wrote:
> Don Dailey wrote:
>> Mark,
>>
>> I wasn't stating a precise value for a doubling when I said 100
>> ELO.But it appears that it is actually worth a bit more than 100
>> ELO for a
>> doubling.I did a massive study of this at one point a year or
>> more ago with thousands of games with UCT based Lazarus program and the
>> strength improvement per doubling was very  clear and impressive.
>
> Don, what komi did you use when you did that study?  Looking in the
> archives, all I can find is you saying that komi=9 is correct.  So
> does that mean 8.5 or 9.5?  Or did you allow draws?
>
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[Don Dailey]

I used 7.5 for that study.You are probably looking at the study
where I use 7x7 in which case the program was too strong to see a good
curve - 8.5 komi is won almost always by black, 9.5 by white if I
remember correctly with 7x7.

Let me see if I can actually find the old graph I created - the data is
quite convincing.

- Don


Michael Williams wrote:
> Don Dailey wrote:
>> Mark,
>>
>> I wasn't stating a precise value for a doubling when I said 100
>> ELO.But it appears that it is actually worth a bit more than 100
>> ELO for a
>> doubling.I did a massive study of this at one point a year or
>> more ago with thousands of games with UCT based Lazarus program and the
>> strength improvement per doubling was very  clear and impressive.
>
> Don, what komi did you use when you did that study?  Looking in the
> archives, all I can find is you saying that komi=9 is correct.  So
> does that mean 8.5 or 9.5?  Or did you allow draws?
>
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[Michael Williams]

Don Dailey wrote:

Mark,

I wasn't stating a precise value for a doubling when I said 100 ELO.
But it appears that it is actually worth a bit more than 100 ELO for a

doubling.I did a massive study of this at one point a year or
more ago with thousands of games with UCT based Lazarus program and the
strength improvement per doubling was very  clear and impressive.


Don, what komi did you use when you did that study?  Looking in the archives, all I can find is you saying that komi=9 is correct.  So does that mean 8.5 or 
9.5?  Or did you allow draws?


___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[Nick Wedd]

In message <[EMAIL PROTECTED]>, Heikki Levanto 
<[EMAIL PROTECTED]> writes

On Wed, Jan 16, 2008 at 04:12:26PM -0500, Don Dailey wrote:

There is no question that there are positions where suicide or eye
filling are correct.


I know suicide can be used as a ko-threat, but are there *any* other
positions where it would be a correct move?

If not, then it makes sense to forbid that in a random playout, since it is
"just" a forcing move, and the (equally) random opponent is quite unlikely to
answer the right way anyway. So the suicide move may look like a better move
than it really is.


I can not think of any situation where filling a one-point eye would be a
correct move (provided that it is a "real" eye and not a "false" one).


Can anyone come with concrete examples?


There's a bunch of them at
http://www.goban.demon.co.uk/go/bestiary/rule_challenge.html

None is at all likely in a real game.  There's also the more plausible 
suicide of three stones as a "minus one point in sente" ko threat.


Nick
--
Nick Wedd[EMAIL PROTECTED]
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[Gunnar Farnebäck]

Erik van der Werf wrote:
> On Jan 16, 2008 10:42 PM, Heikki Levanto <[EMAIL PROTECTED]
> > wrote:
>  > I can not think of any situation where filling a one-point eye 
would be a

>  > correct move (provided that it is a "real" eye and not a "false" one).
>  >
>  >
>  > Can anyone come with concrete examples?
>
> Sure, for example with the following shape filling the eye makes a bulky
> five nakade in the corner
> _
> |. # #
> |# #
>
>
> Under cgos rules you may in rare cases even have to fill eyes of
> pass-alive groups.

This reminds me that one of the games in the January KGS tournament
featured a case of moon-shine life because GNU Go by principle doesn't
play inside unconditional territory unless it needs to remove all dead
opponent stones, but even then only if there are dead stones in the
same eye. The game record can be found at

http://files.gokgs.com/games/2008/1/6/MonteGNU-break.sgf

This is the final position, in cleanup mode after disagreement:

   A B C D E F G H J
 9 . O . O O . . O . 9
 8 . O O . O O . O O 8
 7 O O + . O . + O O 7
 6 O . O O O O . O O 6
 5 . O O . + O . O . 5
 4 O . O . . O O O O 4
 3 O . + O . O X O X 3
 2 O O . O O O X X . 2
 1 . O O O X X X . X 1
   A B C D E F G H J

Black has just captured ko at J3, white passed since it refused to
play inside any of its empty eyes, black of course passed too and the
game was counted as it stood with the black stones considered alive.

/Gunnar
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[Erik van der Werf]

On Jan 16, 2008 10:42 PM, Heikki Levanto <[EMAIL PROTECTED]> wrote:
> I can not think of any situation where filling a one-point eye would be a
> correct move (provided that it is a "real" eye and not a "false" one).
>
>
> Can anyone come with concrete examples?

Sure, for example with the following shape filling the eye makes a bulky
five nakade in the corner
_
|. # #
|# #


Under cgos rules you may in rare cases even have to fill eyes of pass-alive
groups.

E.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[Gunnar Farnebäck]

Heikki Levanto wrote:
> On Wed, Jan 16, 2008 at 04:12:26PM -0500, Don Dailey wrote:
>> There is no question that there are positions where suicide or eye
>> filling are correct.
>
> I know suicide can be used as a ko-threat, but are there *any* other
> positions where it would be a correct move?

Yes, but as far as I know only in obscure positions.
http://www.goban.demon.co.uk/go/bestiary/rule_challenge.html is
mandatory reading.

> If not, then it makes sense to forbid that in a random playout, since 
it is
> "just" a forcing move, and the (equally) random opponent is quite 
unlikely to
> answer the right way anyway. So the suicide move may look like a 
better move

> than it really is.
>
>
> I can not think of any situation where filling a one-point eye would be a
> correct move (provided that it is a "real" eye and not a "false" one).
>
>
> Can anyone come with concrete examples?

This has been discussed before on this list. See e.g.

http://computer-go.org/pipermail/computer-go/2006-August/006180.html
http://computer-go.org/pipermail/computer-go/2006-August/006203.html

/Gunnar
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[Gian-Carlo Pascutto]

terry mcintyre wrote:


That key play might even have been discouraged by some pattern.


MoGo probably does not allow self-ataris. If you do not allow self-atari 
you cannot see such a shape is dead.


--
GCP
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[terry mcintyre]

Yesterday, I played a 9x9 game with Mogo, and a seki developed in the corner. 
Mogo tried to capture my stones; 
I gleefully aided Mogo in this assisted suicide by creating a square four 
shape, which Mogo captured.

Subsequent plays suggested that Mogo believed its group to be alive. When all 
neutral points were played, I passed;
Mogo made some sort of meaningless move; I tossed another stone into that 
single square-four eye. Mogo resigned immediately.

This suggests to me that random playouts  were not discovering that any attempt 
to divide a square-four shape into two eyes would be automatically defeated.
I conjecture that the automatic "play the center of three liberties" response 
was given no greater probability than any of the remaining empty points on the 
board.
That key play might even have been discouraged by some pattern. But once I 
tossed in a stone, Mogo realized that the probability of winning was 
effectively zero.

Are my conjectures in the ballpark? 

How feasible is it to repair such blind spots?

How feasible is it to dynamically boost the probability of such "vital points" 
when they become crucial to the game? 

Terry McIntyre <[EMAIL PROTECTED]> 
“Wherever is found what is called a paternal government, there is found state 
education. It has been discovered that the best way to insure implicit 
obedience is to commence tyranny in the nursery.”
 
Benjamin Disraeli, Speech in the House of Commons [June 15, 1874]

- Original Message 
From: steve uurtamo <[EMAIL PROTECTED]>
To: computer-go 
Sent: Wednesday, January 16, 2008 1:06:09 PM
Subject: Re: [computer-go] Suicide question


maybe this doesn't sound right to everyone,
but i thought that suicide and filling one-point
eyes were both things that could be highly
useful in many corner positions where you either
want to create a nakade (fill the eye), or threaten
one (with suicide).

s.


- Original Message 
From: Don Dailey <[EMAIL PROTECTED]>
To: computer-go 
Sent: Wednesday, January 16, 2008 1:54:30 PM
Subject: Re: [computer-go] Suicide question




David Doshay wrote:
> There are two reasons to consider suicide and its detection..
>
> 1) Some rule sets allow suicide. In such a rule set a suicide can
> be the best move because it can be a huge ko threat.
>
> 2) As David Fotland has pointed out many times, when competing
> under rules that allow suicide, some programs will do one just to
> see if your program refuses to play when you detect its suicide.
But there are very few arguments for putting suicide in the play-outs. 
You can still design your program to accept and even play suicide
without putting these moves in the play-outs. 

The play-outs are imperfect by nature - they try to take a statistical
sample of many possible ways the game might proceed.The path to
improve the quality of this statistical sample is to not play moves
 that
represent very UNLIKELY continuations.Adding these moves randomly
 to
the play-outs doesn't improve it's ability to statically measure the
likely outcome.  

For instance since is "legal" to resign,  we could randomly include
 this
possibility in the play-outs, but it would not increase the resolving
power of the play-outs. 

Moving into 1 point eyes is also legal, but virtually all Monte Carlo
programs forbid this as it's well known to be incredibly stupid in the
vast majority of cases.But in some rare cases it is actually good -
but we still would not want to add it to our play-outs.   

Because of the 1 point eye rule, suicide in the play-outs probably
 isn't
THAT bad.You are probably only suiciding a group that is already
dead - but you are weakening the play-outs.   It may be  worth it if
 you
get enough speed in return.  

In my program I am always looking for an excuse to veto moves that are
obviously bad.   If I had such an obvious class of position like
suicide, I would jump on the opportunity to remove them from the
 play-outs!

- Don


>
>
> Cheers,
> David
>
>
>
> On 16, Jan 2008, at 5:52 AM, Don Dailey wrote:
>
>> I think suicide is insane myself.   But I think the reason programs
>> might use it is only for a speedup - it's faster with some
>> implementations to allow suicide even though it makes the games
 longer.
>>
>> Of course you are right about point B.If suicide is illegal in
 the
>> actual game,  there can be no point in allowing it in the play-outs.
>> It's almost certainly wrong to allow it in the play-outs even if you
 are
>> playing by suicide rules - a lot of work has gone into finding good
>> moves in the play-outs and this would be one of the prime candidates
 for
>> removal!
>>
>> - Don
>>
>>
>> Jacques Basaldúa wrote:
>>> Gian-Carlo Pascutto wrote:
>>>
 Multi-stone suicide is allowed, single stone not.
>>>
>>> I hadn't even considered suicide.(It would be a major change for
 me,
>>> as neither my Gui nor my board system allow such moves.)
>>>
>>> The question is Why do you do it?
>>>
>>> a. Just in case you wanted the entire p

Re: [computer-go] Suicide question

[Heikki Levanto]

On Wed, Jan 16, 2008 at 04:12:26PM -0500, Don Dailey wrote:
> There is no question that there are positions where suicide or eye
> filling are correct.

I know suicide can be used as a ko-threat, but are there *any* other
positions where it would be a correct move?

If not, then it makes sense to forbid that in a random playout, since it is
"just" a forcing move, and the (equally) random opponent is quite unlikely to
answer the right way anyway. So the suicide move may look like a better move
than it really is.


I can not think of any situation where filling a one-point eye would be a
correct move (provided that it is a "real" eye and not a "false" one).


Can anyone come with concrete examples?

 - Heikki

-- 
Heikki Levanto   "In Murphy We Turst" heikki (at) lsd (dot) dk

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] cgos client bug

[Don Dailey]

I inadvertently introduced a bug in the new client program,   so if you
have downloaded it recently you probably have a buggy version.

Please grab the latest and help me test:

http://cgos.boardspace.net/index.html


- Don




   
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[Don Dailey]

There is no question that there are positions where suicide or eye
filling are correct.

- Don


steve uurtamo wrote:
> maybe this doesn't sound right to everyone,
> but i thought that suicide and filling one-point
> eyes were both things that could be highly
> useful in many corner positions where you either
> want to create a nakade (fill the eye), or threaten
> one (with suicide).
>
> s.
>
>
> - Original Message 
> From: Don Dailey <[EMAIL PROTECTED]>
> To: computer-go 
> Sent: Wednesday, January 16, 2008 1:54:30 PM
> Subject: Re: [computer-go] Suicide question
>
>
>
>
> David Doshay wrote:
>   
>> There are two reasons to consider suicide and its detection..
>>
>> 1) Some rule sets allow suicide. In such a rule set a suicide can
>> be the best move because it can be a huge ko threat.
>>
>> 2) As David Fotland has pointed out many times, when competing
>> under rules that allow suicide, some programs will do one just to
>> see if your program refuses to play when you detect its suicide.
>> 
> But there are very few arguments for putting suicide in the play-outs. 
> You can still design your program to accept and even play suicide
> without putting these moves in the play-outs. 
>
> The play-outs are imperfect by nature - they try to take a statistical
> sample of many possible ways the game might proceed.The path to
> improve the quality of this statistical sample is to not play moves
>  that
> represent very UNLIKELY continuations.Adding these moves randomly
>  to
> the play-outs doesn't improve it's ability to statically measure the
> likely outcome.  
>
> For instance since is "legal" to resign,  we could randomly include
>  this
> possibility in the play-outs, but it would not increase the resolving
> power of the play-outs. 
>
> Moving into 1 point eyes is also legal, but virtually all Monte Carlo
> programs forbid this as it's well known to be incredibly stupid in the
> vast majority of cases.But in some rare cases it is actually good -
> but we still would not want to add it to our play-outs.   
>
> Because of the 1 point eye rule, suicide in the play-outs probably
>  isn't
> THAT bad.You are probably only suiciding a group that is already
> dead - but you are weakening the play-outs.   It may be  worth it if
>  you
> get enough speed in return.  
>
> In my program I am always looking for an excuse to veto moves that are
> obviously bad.   If I had such an obvious class of position like
> suicide, I would jump on the opportunity to remove them from the
>  play-outs!
>
> - Don
>
>
>   
>> Cheers,
>> David
>>
>>
>>
>> On 16, Jan 2008, at 5:52 AM, Don Dailey wrote:
>>
>> 
>>> I think suicide is insane myself.   But I think the reason programs
>>> might use it is only for a speedup - it's faster with some
>>> implementations to allow suicide even though it makes the games
>>>   
>  longer.
>   
>>> Of course you are right about point B.If suicide is illegal in
>>>   
>  the
>   
>>> actual game,  there can be no point in allowing it in the play-outs.
>>> It's almost certainly wrong to allow it in the play-outs even if you
>>>   
>  are
>   
>>> playing by suicide rules - a lot of work has gone into finding good
>>> moves in the play-outs and this would be one of the prime candidates
>>>   
>  for
>   
>>> removal!
>>>
>>> - Don
>>>
>>>
>>> Jacques Basaldúa wrote:
>>>   
 Gian-Carlo Pascutto wrote:

 
> Multi-stone suicide is allowed, single stone not.
>   
 I hadn't even considered suicide.(It would be a major change for
 
>  me,
>   
 as neither my Gui nor my board system allow such moves.)

 The question is Why do you do it?

 a. Just in case you wanted the entire program to support suicide go

 or

 b. Because that has some advantage as a random playout.

 If it was b, can anyone explain why suicide is a better evaluation
 
>  for
>   
 a normal (non suicide) game.

 Jacques.


 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/

 
>>> ___
>>> computer-go mailing list
>>> computer-go@computer-go.org
>>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>>   
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>> 
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>
>
>
>
>   
> 
> Never miss a thing.  Make Yahoo your home page. 
> http://www.yahoo.com/r/hs
> _

Re: [computer-go] Suicide question

[steve uurtamo]

maybe this doesn't sound right to everyone,
but i thought that suicide and filling one-point
eyes were both things that could be highly
useful in many corner positions where you either
want to create a nakade (fill the eye), or threaten
one (with suicide).

s.


- Original Message 
From: Don Dailey <[EMAIL PROTECTED]>
To: computer-go 
Sent: Wednesday, January 16, 2008 1:54:30 PM
Subject: Re: [computer-go] Suicide question




David Doshay wrote:
> There are two reasons to consider suicide and its detection..
>
> 1) Some rule sets allow suicide. In such a rule set a suicide can
> be the best move because it can be a huge ko threat.
>
> 2) As David Fotland has pointed out many times, when competing
> under rules that allow suicide, some programs will do one just to
> see if your program refuses to play when you detect its suicide.
But there are very few arguments for putting suicide in the play-outs. 
You can still design your program to accept and even play suicide
without putting these moves in the play-outs. 

The play-outs are imperfect by nature - they try to take a statistical
sample of many possible ways the game might proceed.The path to
improve the quality of this statistical sample is to not play moves
 that
represent very UNLIKELY continuations.Adding these moves randomly
 to
the play-outs doesn't improve it's ability to statically measure the
likely outcome.  

For instance since is "legal" to resign,  we could randomly include
 this
possibility in the play-outs, but it would not increase the resolving
power of the play-outs. 

Moving into 1 point eyes is also legal, but virtually all Monte Carlo
programs forbid this as it's well known to be incredibly stupid in the
vast majority of cases.But in some rare cases it is actually good -
but we still would not want to add it to our play-outs.   

Because of the 1 point eye rule, suicide in the play-outs probably
 isn't
THAT bad.You are probably only suiciding a group that is already
dead - but you are weakening the play-outs.   It may be  worth it if
 you
get enough speed in return.  

In my program I am always looking for an excuse to veto moves that are
obviously bad.   If I had such an obvious class of position like
suicide, I would jump on the opportunity to remove them from the
 play-outs!

- Don


>
>
> Cheers,
> David
>
>
>
> On 16, Jan 2008, at 5:52 AM, Don Dailey wrote:
>
>> I think suicide is insane myself.   But I think the reason programs
>> might use it is only for a speedup - it's faster with some
>> implementations to allow suicide even though it makes the games
 longer.
>>
>> Of course you are right about point B.If suicide is illegal in
 the
>> actual game,  there can be no point in allowing it in the play-outs.
>> It's almost certainly wrong to allow it in the play-outs even if you
 are
>> playing by suicide rules - a lot of work has gone into finding good
>> moves in the play-outs and this would be one of the prime candidates
 for
>> removal!
>>
>> - Don
>>
>>
>> Jacques Basaldúa wrote:
>>> Gian-Carlo Pascutto wrote:
>>>
 Multi-stone suicide is allowed, single stone not.
>>>
>>> I hadn't even considered suicide.(It would be a major change for
 me,
>>> as neither my Gui nor my board system allow such moves.)
>>>
>>> The question is Why do you do it?
>>>
>>> a. Just in case you wanted the entire program to support suicide go
>>>
>>> or
>>>
>>> b. Because that has some advantage as a random playout.
>>>
>>> If it was b, can anyone explain why suicide is a better evaluation
 for
>>> a normal (non suicide) game.
>>>
>>> Jacques.
>>>
>>>
>>> ___
>>> computer-go mailing list
>>> computer-go@computer-go.org
>>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>>
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/





  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Latest client linked from web page

[Don Dailey]

The newest cgos engine client is now available with platform specific
versions also available.   You can get it as a tclkit,  pure tcl
script,  or platform specific binary.

A couple of bugs have already been fixed - so you should use this
version instead of the last one I advertised.

  http://cgos.boardspace.net/index.html


- Don

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[Christoph Birk]

On Jan 16, 2008, at 12:07 PM, Don Dailey wrote:

I have often wondered if UCT and Monte Carlo play-outs would have even
been discovered a few years ago.It could very well be that this
technology HAD to wait for today. Mogo and CrazyStone would not be
impressive on a 386.


I heard about MonteCarlo go in the late-90s when I read a paper
by Bernd Bruegmann (Monte Carlo Go, 1993). This paper is quoted
by most authors as (one of) the earliest.
'Gobble' did of course not play very well for the reason you mention
above.

Christoph

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[Don Dailey]

[EMAIL PROTECTED] wrote:
> Don,
>
> I forgot to mention one additional consideration.
> My top-level driver does check rules for suicide
> and superko, even though the engine may or may not.
> At the top-level, if the engine chooses a bad move,
> then the driver will use the next best move instead.
> (Repeat as necessary) So it will not lose by rules
> and (hopefully) the second best move move is still
> reasonable.
>
> However, I am talking about the actual performance
> of my engine when doing random playouts for MC.
>
> I do know the ELO cost of detection, using a valid
> heuristic. The real ELO benefit of knowing the
> validity of moves is just a wild guess. Yet, I
> stand by my analysis.
>   
You analysis seems to be that it's more important to detect superko in
the play-outs than to eliminate suicide in the play-outs.   

If you want to stand by that,   ok,  but I strongly disagree.

- Don


> Michael Wing
>
>   
>> I think you are off on the relative importance of superko and suicide
>> and it seems that your values are rather arbitrary - just made up.  
>>
>> First of all, we are only talking about detection in the play-outs, not
>> in the tree search portion.
>>
>> In the play-outs,   it is very important to avoid moves that are nearly
>> always horrible.  This clearly includes suicide. I don't know why
>> you estimate that  it is worth only 1 elo weakness. 
>>
>> If you implement a program that doesn't understand superko,  you will 
>> occasionally lose a game due to this - but most of the time it won't be
>> an issue.   Nevertheless, it happens often enough that it is probably
>> worth a few ELO points because your program will LOSE on CGOS if it
>> fails to realize that it is about to play superko.I am guessing that
>> this would amount to perhaps 20 ELO,  I'm just guessing. 
>>
>> HOWEVER,  if your program simply avoids superko moves, without
>> understanding them,  it probably subtracts almost nothing from your
>> rating.  In monte carlo UCT you can STILL include positional superko
>> in the tree search and get 99% of the benefit and simply leave this out
>> of the random play-outs.Including PSK in the play-outs will have no
>> measurable impact on the quality of the play-outs.  
>>
>> My conclusion is different than yours.   If you leave PSK out of the
>> play-outs you lose NOTHING that is likely to be measurable.  If you
>> let your program play suicide moves in the play-outs,   I'm quite you
>> lose many ELO rating points (if speed isn't a consideration.)   
>>
>> Of course speed IS a consideration too and that can change the
>> formula.   In your program there is not question that you should detect
>> suicide and not play it, because this is only 1.5 percent for you.  But
>> evidently some program benefit substantially (in speed) by accepting
>> suicide.
>>
>> - Don
>>
>>
>>
>>   
>>
>> [EMAIL PROTECTED] wrote:
>> 
>>> We can use math to shed some light on the topic:
>>>
>>> * Assume that doubling the speed of a machine
>>>   increases the rank of a program by 100 ELO,
>>>   as Don has previously concluded.
>>>
>>> * Then we have the following table of approximate
>>>   costs, which comes from the equation y = 100 * 2^x
>>>   cost -> lost ELO
>>>   
>>>1%  ->  1.5 ELO
>>>2%  ->  3.0 ELO
>>>3%  ->  4.5 ELO
>>>4%  ->  6.0 ELO
>>>5%  ->  7.5 ELO
>>>6%  ->  9.0 ELO
>>>   10%  -> 15.0 ELO
>>>
>>> * In my program (which implements undo), the cost of
>>>   for suicide detection is around 1%, which means it
>>>   would lose 1.5 ELO points.
>>>
>>> * If I wanted to know whether it was worth it, I would
>>>   want to measure the ELO benefit by making better
>>>   decisions concerning suicide. It is a small but
>>>   real amount, probably at least 1 ELO (using my
>>>   finger in the breeze).
>>>
>>> * Thus the issue of whether you detect suicide may
>>>   be a complete wash.
>>>
>>> * On the other hand detecting superko costs more like
>>>   6% or so, which costs 9 or more ELO. So a benefit
>>>   of 1 ELO for doing superko right may not be worth
>>>   the cost.
>>>
>>> Conclusions
>>>
>>> * The effect of suicide detection is *very* small in
>>>   the scheme of things, and is probably not worth
>>>   arguing over. Superko is also small, but might be
>>>   worth a tiny amount of effort.
>>>
>>> * Some kind of study to measuring the ELO cost of bad
>>>   suicide and ko decisions would be useful.
>>>
>>> * I plan to detect both suicide and superko on principle,
>>>   confident that it doesn't make much difference.
>>>
>>> Michael Wing
>>>
>>> Don Dailey <[EMAIL PROTECTED]> said:
>>>
>>>   
>>>   
> There are two reasons to consider suicide and its detection..
>
> 1) Some rule sets allow suicide. In such a rule set a suicide can
> be the best move because it can be a huge ko threat.
>
> 2) As David Fotland has pointed out many times, when competing
> under rules that allow suicide, some programs will do 

Re: [computer-go] Suicide question

[Don Dailey]

Now that is thinking outside the box :-)


[EMAIL PROTECTED] wrote:
> -Original Message-
> From: Don Dailey [EMAIL PROTECTED]
> ...
>   
>> For instance since is "legal" to resign,? we could randomly include this
>> possibility in the play-outs, but it would not increase the resolving
>> power of the play-outs. 
>>
>> 
>
> Hmm... It would speed things up, though. And if you made the probability of 
> resigning a function of the difference in stone count, you would have a 
> stochastic mercy rule. In case this turns out to help, I name it "Don's 
> escape rule."
>
> - Dave Hillis
>
>
>
>
>
>
> 
> More new features than ever.  Check out the new AIM(R) Mail ! - 
> http://webmail.aim.com
>
>   
> 
>
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[Don Dailey]

Mark,

I wasn't stating a precise value for a doubling when I said 100 ELO.
But it appears that it is actually worth a bit more than 100 ELO for a
doubling.I did a massive study of this at one point a year or
more ago with thousands of games with UCT based Lazarus program and the
strength improvement per doubling was very  clear and impressive.

You can usually see that the 2 or 4 processor versions of Mogo or
CrazyStone jumps way up in strength - so it's very clear that speed is
really quite important for any program that is search based as UCT is
and is properly scalable.  

You will also notice that Mogo and Crazy Stone rarely test their  strong
versions on CGOS,  they often have versions that play super fast or do
tiny numbers of play-outs such as "3k" etc presumably because there is
no competition.You can see that these versions are generally several
hundred ELO weaker - so in every case it is pretty clear that doubling
the number of simulations (or speed) is very important.

I have often wondered if UCT and Monte Carlo play-outs would have even
been discovered a few years ago.It could very well be that this
technology HAD to wait for today. Mogo and CrazyStone would not be
impressive on a 386.

- Don




Mark Boon wrote:
>
> On 16-jan-08, at 17:22, <[EMAIL PROTECTED]> wrote:
>
>> We can use math to shed some light on the topic:
>>
>> * Assume that doubling the speed of a machine
>>   increases the rank of a program by 100 ELO,
>>   as Don has previously concluded.
>>
>> * Then we have the following table of approximate
>>   costs, which comes from the equation y = 100 * 2^x
>>   cost -> lost ELO
>>   
>>1%  ->  1.5 ELO
>>2%  ->  3.0 ELO
>>3%  ->  4.5 ELO
>>4%  ->  6.0 ELO
>>5%  ->  7.5 ELO
>>6%  ->  9.0 ELO
>>   10%  -> 15.0 ELO
>>
>> * In my program (which implements undo), the cost of
>>   for suicide detection is around 1%, which means it
>>   would lose 1.5 ELO points.
>>
>> * If I wanted to know whether it was worth it, I would
>>   want to measure the ELO benefit by making better
>>   decisions concerning suicide. It is a small but
>>   real amount, probably at least 1 ELO (using my
>>   finger in the breeze).
>>
>> * Thus the issue of whether you detect suicide may
>>   be a complete wash.
>>
>> * On the other hand detecting superko costs more like
>>   6% or so, which costs 9 or more ELO. So a benefit
>>   of 1 ELO for doing superko right may not be worth
>>   the cost.
>>
>> Conclusions
>>
>> * The effect of suicide detection is *very* small in
>>   the scheme of things, and is probably not worth
>>   arguing over. Superko is also small, but might be
>>   worth a tiny amount of effort.
>>
>> * Some kind of study to measuring the ELO cost of bad
>>   suicide and ko decisions would be useful.
>>
>> * I plan to detect both suicide and superko on principle,
>>   confident that it doesn't make much difference.
>>
>> Michael Wing
>>
>
> I have a few question-marks here.
>
> First, did Don really say that a doubling of the speed gains 100 ELO?
> Or did he say adding a ply would add 100 ELO? There's a big difference.
>
> Secondly, you say the ELO benefit for not playing suicide is 1.
> Admittedly you say you used your wet finger in the breeze. Thinking
> more about it I'd say Don is right, not playing suicide should be a
> considerable gain. I'd say that (putting my wet finger up) a random
> player that doesn't play suicide beats a random player that does 2:1.
> What's that in ELO? 100 points? Should be easy to verify.
>
> Mark
>
>
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] New CGOS client that allows multiple engines

[Don Dailey]

The feature of being able to rotate players is something that will
interest some programmers,  but the client is still superior for other
reasons.   You don't have to use the rotate feature.  

1.  It is more configurable since you point it to a configuration
file.   You can have multiple configurations setting around for various
testing purposes.

2.  Or you can have all your test bots in one configuration file and
simply deactivate all but one by setting priority to zero for all of
them except for the one you are interested in.

3.  You can have a separate configuration file for the 19x19 server.

4.  If the engine crashes, this client is more likely to detect and
abort the script alerting you to a problem.

5.  You can modify the configuration file during a game without
reloading.   Thus you can switch bots more gracefully,  change
priorities, add bots, etc.  (Of course you should watch for race
conditions.)

6.  If you forget to add a sentinel file, you can set all priorities to
zero and the script will abort on the next cycle.


Here is the deal on the "./cgos3.tcl" way of starting a script:

  1.  The syntax "./script_name"  specifies that the path is in the
current directory.

  2.  But if you have "." in the path for your shell,  you can run any
script in the current directory without requiring the "./" syntax.

Putting "." in your path is considered somewhat of a security risk so I
always use the "./" syntax - you just get used to it and don't have to
think twice about it. However most people put the "." in their PATH
environment variable since it is more convenient.


- Don






Mark Boon wrote:
> Don,
>
> Although I'm not interested in this feature at this point in time I
> applaud the effort you put into this server.
>
> Just some information with regards to Mac clients: it turns out Macs
> come with a tcl runtime out of the box. So you should point Mac users
> simply to the cgos3.tcl file and they'll be fine. It would have saved
> me a little bit of fuss. Oh, and the fact that it has to be started
> with "./cgos3.tcl", simply "cgos3.tcl" doesn't work. But maybe that's
> just showing I hardly ever use the command-line shell.
>
> Mark
>
>
> On 16-jan-08, at 13:55, Don Dailey wrote:
>
>> We have designed a new CGOS engine client that has more features and
>> should be more convenient to use.
>>
>> Here are the primary new features:
>>
>>  You can run multiple engines if you choose.
>>  You can specify server and port.
>>  Works with configuration file - so you have multiple configs for
>> different testing scenarios.
>>
>>
>> I would like volunteers to test the alpha version so that we can get
>> useful feedback.  The feedback we are most interested in concerns
>> bugs, glitches, annoyances that can be easily fixed, not ideas for
>> major upgrades.  If you have great ideas for future features, go to
>> sourceforge and join the  cgos-developers and we would welcome your
>> feedback on this.
>>
>> It would be useful to test this on unix, windows and macs.  I have
>> done some testing on Unix, but want to know especially if there are
>> Windows and Mac issues although I hope for good coverage on all
>> platforms.
>>
>> The new client supports multiple engines, but does not manage
>> simultaneous games with these engines, instead it manages the
>> rotation of any specified number of players.  So you may have several
>> players taking turns playing games on CGOS.
>>
>> The players are selected randomly but you can choose the priority,
>> for instance setting one player up to play twice as often as another
>> if you choose.  The priority number is a positive integer (it can be
>> zero to deactivate a player) and determines how often a given player
>> will play.  The rotation schedule is not predictable, it is
>> probabilistic so if you do set one program to play twice as often as
>> another, this will happen on average, but it won't be a predictable
>> cycle.
>>
>> The probability of a particular engine playing the next game is
>> computed like this:
>>
>> prob = p / s
>>
>> where s is the sum of all the engines priority numbers and p is the
>> priority of the engine in question.
>>
>> The client manages the connections - determining when to log on and
>> off the server to connect a different program so that they can be
>> rotated in a proper way.
>>
>> The client reads the configuration file between rounds, so you can
>> even modify priorities or who plays between rounds without restarting
>> the client or temporarily deactivate a player by setting his priority
>> to zero.
>>
>> To run the client just execute it without arguments to get a usage
>> message which explains everything.
>>
>> The alpha client version can be found here:
>>
>>http://cgos.boardspace.net/public/cgosGtp_alpha.zip
>>
>> Currently only a pure tcl version is available but we will be
>> packaging these up as executables for the various platforms soon.  Or
>> on request we can do this right away.
>>
>>
>> - Don
>> _

Re: [computer-go] Suicide question

[wing]

Don,

I forgot to mention one additional consideration.
My top-level driver does check rules for suicide
and superko, even though the engine may or may not.
At the top-level, if the engine chooses a bad move,
then the driver will use the next best move instead.
(Repeat as necessary) So it will not lose by rules
and (hopefully) the second best move move is still
reasonable.

However, I am talking about the actual performance
of my engine when doing random playouts for MC.

I do know the ELO cost of detection, using a valid
heuristic. The real ELO benefit of knowing the
validity of moves is just a wild guess. Yet, I
stand by my analysis.

Michael Wing

> I think you are off on the relative importance of superko and suicide
> and it seems that your values are rather arbitrary - just made up.  
> 
> First of all, we are only talking about detection in the play-outs, not
> in the tree search portion.
> 
> In the play-outs,   it is very important to avoid moves that are nearly
> always horrible.  This clearly includes suicide. I don't know why
> you estimate that  it is worth only 1 elo weakness. 
> 
> If you implement a program that doesn't understand superko,  you will 
> occasionally lose a game due to this - but most of the time it won't be
> an issue.   Nevertheless, it happens often enough that it is probably
> worth a few ELO points because your program will LOSE on CGOS if it
> fails to realize that it is about to play superko.I am guessing that
> this would amount to perhaps 20 ELO,  I'm just guessing. 
> 
> HOWEVER,  if your program simply avoids superko moves, without
> understanding them,  it probably subtracts almost nothing from your
> rating.  In monte carlo UCT you can STILL include positional superko
> in the tree search and get 99% of the benefit and simply leave this out
> of the random play-outs.Including PSK in the play-outs will have no
> measurable impact on the quality of the play-outs.  
> 
> My conclusion is different than yours.   If you leave PSK out of the
> play-outs you lose NOTHING that is likely to be measurable.  If you
> let your program play suicide moves in the play-outs,   I'm quite you
> lose many ELO rating points (if speed isn't a consideration.)   
> 
> Of course speed IS a consideration too and that can change the
> formula.   In your program there is not question that you should detect
> suicide and not play it, because this is only 1.5 percent for you.  But
> evidently some program benefit substantially (in speed) by accepting
> suicide.
> 
> - Don
> 
> 
> 
>   
> 
> [EMAIL PROTECTED] wrote:
> > We can use math to shed some light on the topic:
> >
> > * Assume that doubling the speed of a machine
> >   increases the rank of a program by 100 ELO,
> >   as Don has previously concluded.
> >
> > * Then we have the following table of approximate
> >   costs, which comes from the equation y = 100 * 2^x
> >   cost -> lost ELO
> >   
> >1%  ->  1.5 ELO
> >2%  ->  3.0 ELO
> >3%  ->  4.5 ELO
> >4%  ->  6.0 ELO
> >5%  ->  7.5 ELO
> >6%  ->  9.0 ELO
> >   10%  -> 15.0 ELO
> >
> > * In my program (which implements undo), the cost of
> >   for suicide detection is around 1%, which means it
> >   would lose 1.5 ELO points.
> >
> > * If I wanted to know whether it was worth it, I would
> >   want to measure the ELO benefit by making better
> >   decisions concerning suicide. It is a small but
> >   real amount, probably at least 1 ELO (using my
> >   finger in the breeze).
> >
> > * Thus the issue of whether you detect suicide may
> >   be a complete wash.
> >
> > * On the other hand detecting superko costs more like
> >   6% or so, which costs 9 or more ELO. So a benefit
> >   of 1 ELO for doing superko right may not be worth
> >   the cost.
> >
> > Conclusions
> >
> > * The effect of suicide detection is *very* small in
> >   the scheme of things, and is probably not worth
> >   arguing over. Superko is also small, but might be
> >   worth a tiny amount of effort.
> >
> > * Some kind of study to measuring the ELO cost of bad
> >   suicide and ko decisions would be useful.
> >
> > * I plan to detect both suicide and superko on principle,
> >   confident that it doesn't make much difference.
> >
> > Michael Wing
> >
> > Don Dailey <[EMAIL PROTECTED]> said:
> >
> >   
> >>> There are two reasons to consider suicide and its detection..
> >>>
> >>> 1) Some rule sets allow suicide. In such a rule set a suicide can
> >>> be the best move because it can be a huge ko threat.
> >>>
> >>> 2) As David Fotland has pointed out many times, when competing
> >>> under rules that allow suicide, some programs will do one just to
> >>> see if your program refuses to play when you detect its suicide.
> >>>   
> >> But there are very few arguments for putting suicide in the play-outs. 
> >> You can still design your program to accept and even play suicide
> >> without putting these moves in the play-outs. 
> >>
> >> The play-outs are imperf

Re: [computer-go] Suicide question

[dhillismail]

-Original Message-
From: Don Dailey [EMAIL PROTECTED]
...
> 
> For instance since is "legal" to resign,? we could randomly include this
> possibility in the play-outs, but it would not increase the resolving
> power of the play-outs. 
>

Hmm... It would speed things up, though. And if you made the probability of 
resigning a function of the difference in stone count, you would have a 
stochastic mercy rule. In case this turns out to help, I name it "Don's escape 
rule."

- Dave Hillis







More new features than ever.  Check out the new AIM(R) Mail ! - 
http://webmail.aim.com
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[wing]

Mark,

Don did say that doubling the speed of a machine is
100 ELO. See the thread at
http://www.mail-archive.com/computer-go@computer-go.org/msg05358.html

I believe that beating someone 2:1 is 100 ELO.
So, if ignoring suicide is at most 1 ELO, then it doesn't matter.

Michael Wing

P.S. I should have used the equation y = 100 * log2(x)

> I have a few question-marks here.
>
> First, did Don really say that a doubling of the speed gains 100 ELO?  
> Or did he say adding a ply would add 100 ELO? There's a big difference.
> 
> Secondly, you say the ELO benefit for not playing suicide is 1.  
> Admittedly you say you used your wet finger in the breeze. Thinking  
> more about it I'd say Don is right, not playing suicide should be a  
> considerable gain. I'd say that (putting my wet finger up) a random  
> player that doesn't play suicide beats a random player that does 2:1.  
> What's that in ELO? 100 points? Should be easy to verify.

> > Conclusions
> > * The effect of suicide detection is *very* small in
> >   the scheme of things, and is probably not worth
> >   arguing over. Superko is also small, but might be
> >   worth a tiny amount of effort.
> >
> > * Some kind of study to measuring the ELO cost of bad
> >   suicide and ko decisions would be useful.
> >
> > * I plan to detect both suicide and superko on principle,
> >   confident that it doesn't make much difference.

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[Don Dailey]

I think you are off on the relative importance of superko and suicide
and it seems that your values are rather arbitrary - just made up.  

First of all, we are only talking about detection in the play-outs, not
in the tree search portion.

In the play-outs,   it is very important to avoid moves that are nearly
always horrible.  This clearly includes suicide. I don't know why
you estimate that  it is worth only 1 elo weakness. 

If you implement a program that doesn't understand superko,  you will 
occasionally lose a game due to this - but most of the time it won't be
an issue.   Nevertheless, it happens often enough that it is probably
worth a few ELO points because your program will LOSE on CGOS if it
fails to realize that it is about to play superko.I am guessing that
this would amount to perhaps 20 ELO,  I'm just guessing. 

HOWEVER,  if your program simply avoids superko moves, without
understanding them,  it probably subtracts almost nothing from your
rating.  In monte carlo UCT you can STILL include positional superko
in the tree search and get 99% of the benefit and simply leave this out
of the random play-outs.Including PSK in the play-outs will have no
measurable impact on the quality of the play-outs.  

My conclusion is different than yours.   If you leave PSK out of the
play-outs you lose NOTHING that is likely to be measurable.  If you
let your program play suicide moves in the play-outs,   I'm quite you
lose many ELO rating points (if speed isn't a consideration.)   

Of course speed IS a consideration too and that can change the
formula.   In your program there is not question that you should detect
suicide and not play it, because this is only 1.5 percent for you.  But
evidently some program benefit substantially (in speed) by accepting
suicide.

- Don



  

[EMAIL PROTECTED] wrote:
> We can use math to shed some light on the topic:
>
> * Assume that doubling the speed of a machine
>   increases the rank of a program by 100 ELO,
>   as Don has previously concluded.
>
> * Then we have the following table of approximate
>   costs, which comes from the equation y = 100 * 2^x
>   cost -> lost ELO
>   
>1%  ->  1.5 ELO
>2%  ->  3.0 ELO
>3%  ->  4.5 ELO
>4%  ->  6.0 ELO
>5%  ->  7.5 ELO
>6%  ->  9.0 ELO
>   10%  -> 15.0 ELO
>
> * In my program (which implements undo), the cost of
>   for suicide detection is around 1%, which means it
>   would lose 1.5 ELO points.
>
> * If I wanted to know whether it was worth it, I would
>   want to measure the ELO benefit by making better
>   decisions concerning suicide. It is a small but
>   real amount, probably at least 1 ELO (using my
>   finger in the breeze).
>
> * Thus the issue of whether you detect suicide may
>   be a complete wash.
>
> * On the other hand detecting superko costs more like
>   6% or so, which costs 9 or more ELO. So a benefit
>   of 1 ELO for doing superko right may not be worth
>   the cost.
>
> Conclusions
>
> * The effect of suicide detection is *very* small in
>   the scheme of things, and is probably not worth
>   arguing over. Superko is also small, but might be
>   worth a tiny amount of effort.
>
> * Some kind of study to measuring the ELO cost of bad
>   suicide and ko decisions would be useful.
>
> * I plan to detect both suicide and superko on principle,
>   confident that it doesn't make much difference.
>
> Michael Wing
>
> Don Dailey <[EMAIL PROTECTED]> said:
>
>   
>>> There are two reasons to consider suicide and its detection..
>>>
>>> 1) Some rule sets allow suicide. In such a rule set a suicide can
>>> be the best move because it can be a huge ko threat.
>>>
>>> 2) As David Fotland has pointed out many times, when competing
>>> under rules that allow suicide, some programs will do one just to
>>> see if your program refuses to play when you detect its suicide.
>>>   
>> But there are very few arguments for putting suicide in the play-outs. 
>> You can still design your program to accept and even play suicide
>> without putting these moves in the play-outs. 
>>
>> The play-outs are imperfect by nature - they try to take a statistical
>> sample of many possible ways the game might proceed.The path to
>> improve the quality of this statistical sample is to not play moves that
>> represent very UNLIKELY continuations.Adding these moves randomly to
>> the play-outs doesn't improve it's ability to statically measure the
>> likely outcome.  
>>
>> For instance since is "legal" to resign,  we could randomly include this
>> possibility in the play-outs, but it would not increase the resolving
>> power of the play-outs. 
>>
>> Moving into 1 point eyes is also legal, but virtually all Monte Carlo
>> programs forbid this as it's well known to be incredibly stupid in the
>> vast majority of cases.But in some rare cases it is actually good -
>> but we still would not want to add it to our play-outs.   
>>
>> Because of the 1 point eye rule, suicide in

Re: [computer-go] New CGOS client that allows multiple engines

[Mark Boon]

Don,

Although I'm not interested in this feature at this point in time I  
applaud the effort you put into this server.


Just some information with regards to Mac clients: it turns out Macs  
come with a tcl runtime out of the box. So you should point Mac users  
simply to the cgos3.tcl file and they'll be fine. It would have saved  
me a little bit of fuss. Oh, and the fact that it has to be started  
with "./cgos3.tcl", simply "cgos3.tcl" doesn't work. But maybe that's  
just showing I hardly ever use the command-line shell.


Mark


On 16-jan-08, at 13:55, Don Dailey wrote:

We have designed a new CGOS engine client that has more features  
and should be more convenient to use.


Here are the primary new features:

 You can run multiple engines if you choose.
 You can specify server and port.
 Works with configuration file - so you have multiple configs for  
different testing scenarios.



I would like volunteers to test the alpha version so that we can  
get useful feedback.  The feedback we are most interested in  
concerns bugs, glitches, annoyances that can be easily fixed, not  
ideas for
major upgrades.  If you have great ideas for future features, go to  
sourceforge and join the  cgos-developers and we would welcome your  
feedback on this.


It would be useful to test this on unix, windows and macs.  I have  
done some testing on Unix, but want to know especially if there are  
Windows and Mac issues although I hope for good coverage on all  
platforms.


The new client supports multiple engines, but does not manage  
simultaneous games with these engines, instead it manages the  
rotation of any specified number of players.  So you may have  
several players taking turns playing games on CGOS.


The players are selected randomly but you can choose the priority,  
for instance setting one player up to play twice as often as  
another if you choose.  The priority number is a positive integer  
(it can be zero to deactivate a player) and determines how often a  
given player will play.  The rotation schedule is not predictable,  
it is probabilistic so if you do set one program to play twice as  
often as another, this will happen on average, but it won't be a  
predictable cycle.


The probability of a particular engine playing the next game is  
computed like this:


prob = p / s

where s is the sum of all the engines priority numbers and p is the  
priority of the engine in question.


The client manages the connections - determining when to log on and  
off the server to connect a different program so that they can be  
rotated in a proper way.


The client reads the configuration file between rounds, so you can  
even modify priorities or who plays between rounds without  
restarting the client or temporarily deactivate a player by setting  
his priority to zero.


To run the client just execute it without arguments to get a usage  
message which explains everything.


The alpha client version can be found here:

   http://cgos.boardspace.net/public/cgosGtp_alpha.zip

Currently only a pure tcl version is available but we will be  
packaging these up as executables for the various platforms soon.   
Or on request we can do this right away.



- Don
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/


___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[Mark Boon]

On 16-jan-08, at 17:22, <[EMAIL PROTECTED]> wrote:


We can use math to shed some light on the topic:

* Assume that doubling the speed of a machine
  increases the rank of a program by 100 ELO,
  as Don has previously concluded.

* Then we have the following table of approximate
  costs, which comes from the equation y = 100 * 2^x
  cost -> lost ELO
  
   1%  ->  1.5 ELO
   2%  ->  3.0 ELO
   3%  ->  4.5 ELO
   4%  ->  6.0 ELO
   5%  ->  7.5 ELO
   6%  ->  9.0 ELO
  10%  -> 15.0 ELO

* In my program (which implements undo), the cost of
  for suicide detection is around 1%, which means it
  would lose 1.5 ELO points.

* If I wanted to know whether it was worth it, I would
  want to measure the ELO benefit by making better
  decisions concerning suicide. It is a small but
  real amount, probably at least 1 ELO (using my
  finger in the breeze).

* Thus the issue of whether you detect suicide may
  be a complete wash.

* On the other hand detecting superko costs more like
  6% or so, which costs 9 or more ELO. So a benefit
  of 1 ELO for doing superko right may not be worth
  the cost.

Conclusions

* The effect of suicide detection is *very* small in
  the scheme of things, and is probably not worth
  arguing over. Superko is also small, but might be
  worth a tiny amount of effort.

* Some kind of study to measuring the ELO cost of bad
  suicide and ko decisions would be useful.

* I plan to detect both suicide and superko on principle,
  confident that it doesn't make much difference.

Michael Wing



I have a few question-marks here.

First, did Don really say that a doubling of the speed gains 100 ELO?  
Or did he say adding a ply would add 100 ELO? There's a big difference.


Secondly, you say the ELO benefit for not playing suicide is 1.  
Admittedly you say you used your wet finger in the breeze. Thinking  
more about it I'd say Don is right, not playing suicide should be a  
considerable gain. I'd say that (putting my wet finger up) a random  
player that doesn't play suicide beats a random player that does 2:1.  
What's that in ELO? 100 points? Should be easy to verify.


Mark


___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[wing]

We can use math to shed some light on the topic:

* Assume that doubling the speed of a machine
  increases the rank of a program by 100 ELO,
  as Don has previously concluded.

* Then we have the following table of approximate
  costs, which comes from the equation y = 100 * 2^x
  cost -> lost ELO
  
   1%  ->  1.5 ELO
   2%  ->  3.0 ELO
   3%  ->  4.5 ELO
   4%  ->  6.0 ELO
   5%  ->  7.5 ELO
   6%  ->  9.0 ELO
  10%  -> 15.0 ELO

* In my program (which implements undo), the cost of
  for suicide detection is around 1%, which means it
  would lose 1.5 ELO points.

* If I wanted to know whether it was worth it, I would
  want to measure the ELO benefit by making better
  decisions concerning suicide. It is a small but
  real amount, probably at least 1 ELO (using my
  finger in the breeze).

* Thus the issue of whether you detect suicide may
  be a complete wash.

* On the other hand detecting superko costs more like
  6% or so, which costs 9 or more ELO. So a benefit
  of 1 ELO for doing superko right may not be worth
  the cost.

Conclusions

* The effect of suicide detection is *very* small in
  the scheme of things, and is probably not worth
  arguing over. Superko is also small, but might be
  worth a tiny amount of effort.

* Some kind of study to measuring the ELO cost of bad
  suicide and ko decisions would be useful.

* I plan to detect both suicide and superko on principle,
  confident that it doesn't make much difference.

Michael Wing

Don Dailey <[EMAIL PROTECTED]> said:

> > There are two reasons to consider suicide and its detection..
> >
> > 1) Some rule sets allow suicide. In such a rule set a suicide can
> > be the best move because it can be a huge ko threat.
> >
> > 2) As David Fotland has pointed out many times, when competing
> > under rules that allow suicide, some programs will do one just to
> > see if your program refuses to play when you detect its suicide.
> But there are very few arguments for putting suicide in the play-outs. 
> You can still design your program to accept and even play suicide
> without putting these moves in the play-outs. 
> 
> The play-outs are imperfect by nature - they try to take a statistical
> sample of many possible ways the game might proceed.The path to
> improve the quality of this statistical sample is to not play moves that
> represent very UNLIKELY continuations.Adding these moves randomly to
> the play-outs doesn't improve it's ability to statically measure the
> likely outcome.  
> 
> For instance since is "legal" to resign,  we could randomly include this
> possibility in the play-outs, but it would not increase the resolving
> power of the play-outs. 
>
> Moving into 1 point eyes is also legal, but virtually all Monte Carlo
> programs forbid this as it's well known to be incredibly stupid in the
> vast majority of cases.But in some rare cases it is actually good -
> but we still would not want to add it to our play-outs.   
> 
> Because of the 1 point eye rule, suicide in the play-outs probably isn't
> THAT bad.You are probably only suiciding a group that is already
> dead - but you are weakening the play-outs.   It may be  worth it if you
> get enough speed in return.  
> 
> In my program I am always looking for an excuse to veto moves that are
> obviously bad.   If I had such an obvious class of position like
> suicide, I would jump on the opportunity to remove them from the play-outs!
> 
> - Don
> 
> 
> >
> >
> > Cheers,
> > David
> >
> >
> >
> > On 16, Jan 2008, at 5:52 AM, Don Dailey wrote:
> >
> >> I think suicide is insane myself.   But I think the reason programs
> >> might use it is only for a speedup - it's faster with some
> >> implementations to allow suicide even though it makes the games longer.
> >>
> >> Of course you are right about point B.If suicide is illegal in the
> >> actual game,  there can be no point in allowing it in the play-outs.
> >> It's almost certainly wrong to allow it in the play-outs even if you are
> >> playing by suicide rules - a lot of work has gone into finding good
> >> moves in the play-outs and this would be one of the prime candidates for
> >> removal!
> >>
> >> - Don
> >>
> >>
> >> Jacques Basaldúa wrote:
> >>> Gian-Carlo Pascutto wrote:
> >>>
>  Multi-stone suicide is allowed, single stone not.
> >>>
> >>> I hadn't even considered suicide.(It would be a major change for me,
> >>> as neither my Gui nor my board system allow such moves.)
> >>>
> >>> The question is Why do you do it?
> >>>
> >>> a. Just in case you wanted the entire program to support suicide go
> >>>
> >>> or
> >>>
> >>> b. Because that has some advantage as a random playout.
> >>>
> >>> If it was b, can anyone explain why suicide is a better evaluation for
> >>> a normal (non suicide) game.
> >>>
> >>> Jacques.
> >>>
> >>>
> >>> ___
> >>> computer-go mailing list
> >>> computer-go@computer-go.org
> >>> http://www.computer-go.org/mailman/listinfo/c

Re: [computer-go] Suicide question

[Don Dailey]

David Doshay wrote:
> There are two reasons to consider suicide and its detection..
>
> 1) Some rule sets allow suicide. In such a rule set a suicide can
> be the best move because it can be a huge ko threat.
>
> 2) As David Fotland has pointed out many times, when competing
> under rules that allow suicide, some programs will do one just to
> see if your program refuses to play when you detect its suicide.
But there are very few arguments for putting suicide in the play-outs. 
You can still design your program to accept and even play suicide
without putting these moves in the play-outs. 

The play-outs are imperfect by nature - they try to take a statistical
sample of many possible ways the game might proceed.The path to
improve the quality of this statistical sample is to not play moves that
represent very UNLIKELY continuations.Adding these moves randomly to
the play-outs doesn't improve it's ability to statically measure the
likely outcome.  

For instance since is "legal" to resign,  we could randomly include this
possibility in the play-outs, but it would not increase the resolving
power of the play-outs. 

Moving into 1 point eyes is also legal, but virtually all Monte Carlo
programs forbid this as it's well known to be incredibly stupid in the
vast majority of cases.But in some rare cases it is actually good -
but we still would not want to add it to our play-outs.   

Because of the 1 point eye rule, suicide in the play-outs probably isn't
THAT bad.You are probably only suiciding a group that is already
dead - but you are weakening the play-outs.   It may be  worth it if you
get enough speed in return.  

In my program I am always looking for an excuse to veto moves that are
obviously bad.   If I had such an obvious class of position like
suicide, I would jump on the opportunity to remove them from the play-outs!

- Don


>
>
> Cheers,
> David
>
>
>
> On 16, Jan 2008, at 5:52 AM, Don Dailey wrote:
>
>> I think suicide is insane myself.   But I think the reason programs
>> might use it is only for a speedup - it's faster with some
>> implementations to allow suicide even though it makes the games longer.
>>
>> Of course you are right about point B.If suicide is illegal in the
>> actual game,  there can be no point in allowing it in the play-outs.
>> It's almost certainly wrong to allow it in the play-outs even if you are
>> playing by suicide rules - a lot of work has gone into finding good
>> moves in the play-outs and this would be one of the prime candidates for
>> removal!
>>
>> - Don
>>
>>
>> Jacques Basaldúa wrote:
>>> Gian-Carlo Pascutto wrote:
>>>
 Multi-stone suicide is allowed, single stone not.
>>>
>>> I hadn't even considered suicide.(It would be a major change for me,
>>> as neither my Gui nor my board system allow such moves.)
>>>
>>> The question is Why do you do it?
>>>
>>> a. Just in case you wanted the entire program to support suicide go
>>>
>>> or
>>>
>>> b. Because that has some advantage as a random playout.
>>>
>>> If it was b, can anyone explain why suicide is a better evaluation for
>>> a normal (non suicide) game.
>>>
>>> Jacques.
>>>
>>>
>>> ___
>>> computer-go mailing list
>>> computer-go@computer-go.org
>>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>>
>> ___
>> computer-go mailing list
>> computer-go@computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[David Doshay]

There are two reasons to consider suicide and its detection..

1) Some rule sets allow suicide. In such a rule set a suicide can
be the best move because it can be a huge ko threat.

2) As David Fotland has pointed out many times, when competing
under rules that allow suicide, some programs will do one just to
see if your program refuses to play when you detect its suicide.


Cheers,
David



On 16, Jan 2008, at 5:52 AM, Don Dailey wrote:


I think suicide is insane myself.   But I think the reason programs
might use it is only for a speedup - it's faster with some
implementations to allow suicide even though it makes the games  
longer.


Of course you are right about point B.If suicide is illegal in the
actual game,  there can be no point in allowing it in the play-outs.
It's almost certainly wrong to allow it in the play-outs even if  
you are

playing by suicide rules - a lot of work has gone into finding good
moves in the play-outs and this would be one of the prime  
candidates for

removal!

- Don


Jacques Basaldúa wrote:

Gian-Carlo Pascutto wrote:


Multi-stone suicide is allowed, single stone not.


I hadn't even considered suicide.(It would be a major change for me,
as neither my Gui nor my board system allow such moves.)

The question is Why do you do it?

a. Just in case you wanted the entire program to support suicide go

or

b. Because that has some advantage as a random playout.

If it was b, can anyone explain why suicide is a better evaluation  
for

a normal (non suicide) game.

Jacques.


___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/


___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/


___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] On average how many boardupdates/sec cantop Goprograms do these days?

[Don Dailey]

Mark Boon wrote:
> On 16-jan-08, at 11:54, Christoph Birk wrote:
>
>> I think this is very wrong, like allowing suicide.
>> If you allow (or forbid) moves that cannot really (should) be played
>> in the
>> random games you are not sampling the true status of the board.
>
> I think most people take a much too dogmatic point of view on this
> issue either way. Maybe by allowing suicide you don't sample the true
> status, but does it statistically matter? If you hold this stand-point
> then you should also detect board repetitions. I bet most if not all
> only check for ko because checking for repetition is too time-consuming.
It matters a lot.   The biggest advance in MC has been modifying the
play-outs so that they are not completely random - but instead tend to
play more realistic moves.For instance my play-outs tries a random
defense to an atari move.  

So it makes no sense to allow a move that is almost certainly horrible
in the play-outs.   Even if your group is dead,  at least use your turn
in a more productive way.  

This gives a more realistic picture of the value of a position
statistically. 

Now it's a different issue whether the extra speed gained by not testing
for suicide is worth the degradation of quality. But as you get into
heavier play-outs,  the time saved by heroic measures like allowing
suicide becomes very minor because the majority of your time is spent
judging moves and massaging the move list - steps that can be avoided if
you are not picky about the moves allowed.

So yes, you can get ridiculously fast play-outs if you "throw out the
baby with the bathwater",  but you have to give up a lot of that speed
if you want high quality Mogo-style play-outs. 

Board repetition detection is not in the same league as allowing
suicide.   99.9% of the benefit of knowing about position superko is
handled in the search tree where you CAN check for repetition.  In the
play-outs the advantage of testing for repetition is almost
non-existent. Suicide on the other hand is a move that is almost
certainly  horrible.   


- Don




>
> My question would be, would choosing either way matter? If it matters
> you do something about it. If it doesn't matter you don't care. For me
> multiple suicide and board repetition fall in the category where they
> don't matter. The cases where it makes a difference are so few that
> you can play for a lifetime and encounter it maybe once or twice.
> Maybe with MC playouts it would make the game shorter when
> multiple-suicide is not allowed. If that's the case then that's a
> reason to do something about it. But even with MC I doubt you save
> more than a few moves on average.
>
> Not allowing to play on a point that was at some point illegal for one
> side does matter a lot. Groups with one (false) eye would be alive. So
> so I'm sure people won't use that.
>
> Mark
>
>
> 
>
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] On average how many boardupdates/sec cantop Goprograms do these days?

[Mark Boon]

On 16-jan-08, at 11:54, Christoph Birk wrote:


I think this is very wrong, like allowing suicide.
If you allow (or forbid) moves that cannot really (should) be  
played in the

random games you are not sampling the true status of the board.


I think most people take a much too dogmatic point of view on this  
issue either way. Maybe by allowing suicide you don't sample the true  
status, but does it statistically matter? If you hold this stand- 
point then you should also detect board repetitions. I bet most if  
not all only check for ko because checking for repetition is too time- 
consuming.


My question would be, would choosing either way matter? If it matters  
you do something about it. If it doesn't matter you don't care. For  
me multiple suicide and board repetition fall in the category where  
they don't matter. The cases where it makes a difference are so few  
that you can play for a lifetime and encounter it maybe once or  
twice. Maybe with MC playouts it would make the game shorter when  
multiple-suicide is not allowed. If that's the case then that's a  
reason to do something about it. But even with MC I doubt you save  
more than a few moves on average.


Not allowing to play on a point that was at some point illegal for  
one side does matter a lot. Groups with one (false) eye would be  
alive. So so I'm sure people won't use that.


Mark

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] New CGOS client that allows multiple engines

[Don Dailey]

We have designed a new CGOS engine client that has more features and
should be more convenient to use.

Here are the primary new features:

   1.  You can run multiple engines if you choose.
   2.  You can specify server and port.
   3.  Works with configuration file - so you have multiple configs for
  different testing scenarios.



I would like volunteers to test the alpha version so that we can get
useful feedback.  The feedback we are most interested in concerns bugs,
glitches, annoyances that can be easily fixed, not ideas for
major upgrades.  If you have great ideas for future features, go to
sourceforge and join the  cgos-developers and we would welcome your
feedback on this.

It would be useful to test this on unix, windows and macs.  I have done
some testing on Unix, but want to know especially if there are Windows
and Mac issues although I hope for good coverage on all platforms.

The new client supports multiple engines, but does not manage
simultaneous games with these engines, instead it manages the rotation
of any specified number of players.  So you may have several players
taking turns playing games on CGOS.

The players are selected randomly but you can choose the priority, for
instance setting one player up to play twice as often as another if you
choose.  The priority number is a positive integer (it can be zero to
deactivate a player) and determines how often a given player will play. 
The rotation schedule is not predictable, it is probabilistic so if you
do set one program to play twice as often as another, this will happen
on average, but it won't be a predictable cycle.

The probability of a particular engine playing the next game is computed
like this:

prob = p / s

where s is the sum of all the engines priority numbers and p is the
priority of the engine in question.

The client manages the connections - determining when to log on and off
the server to connect a different program so that they can be rotated in
a proper way.

The client reads the configuration file between rounds, so you can even
modify priorities or who plays between rounds without restarting the
client or temporarily deactivate a player by setting his priority to zero.

To run the client just execute it without arguments to get a usage
message which explains everything.

The alpha client version can be found here:

   http://cgos.boardspace.net/public/cgosGtp_alpha.zip

Currently only a pure tcl version is available but we will be packaging
these up as executables for the various platforms soon.  Or on request
we can do this right away.


- Don
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] On average how many boardupdates/sec cantop Goprograms do these days?

[Christoph Birk]

On Jan 15, 2008, at 11:05 PM, Harri Salakoski wrote:
This is a mistake.  There are often moves that are illegal for  
black that
are big for white.  If you don't let white play there, white can  
lose a lot

of points.  Connections through false eyes are one example.
Yep agree that, knowing that it is not fair for other but kind of  
rationalized it that it is same for both players and there is half  
chance
that other player tries it before. I kind of think that it keeps  
spirit of "random" result still because it is same for both players


I think this is very wrong, like allowing suicide.
If you allow (or forbid) moves that cannot really (should) be played  
in the

random games you are not sampling the true status of the board.

This is very different from null-move where one tries to get a lower
estimate of the board position by allowing an extra move at the
BEGINNING, but not during the playout.

Christoph

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[Don Dailey]

I think suicide is insane myself.   But I think the reason programs
might use it is only for a speedup - it's faster with some
implementations to allow suicide even though it makes the games longer.

Of course you are right about point B.If suicide is illegal in the
actual game,  there can be no point in allowing it in the play-outs.
It's almost certainly wrong to allow it in the play-outs even if you are
playing by suicide rules - a lot of work has gone into finding good
moves in the play-outs and this would be one of the prime candidates for
removal!

- Don


Jacques Basaldúa wrote:
> Gian-Carlo Pascutto wrote:
>
> > Multi-stone suicide is allowed, single stone not.
>
> I hadn't even considered suicide.(It would be a major change for me,
> as neither my Gui nor my board system allow such moves.)
>
> The question is Why do you do it?
>
> a. Just in case you wanted the entire program to support suicide go
>
> or
>
> b. Because that has some advantage as a random playout.
>
> If it was b, can anyone explain why suicide is a better evaluation for
> a normal (non suicide) game.
>
> Jacques.
>
>
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] The "intelligence" can of worms reopened

[Don Dailey]

I agree with what you say about UCT/MC and I think I made a similar post
many months ago.   Essentially I said, just as you,  that UCT is closer
to what humans do,  it "works out" the particulars of the position. 

I've always thought it odd that the approach advocated by many is based
on static rules and intensive knowledge and the advocates of it call it
the "intelligent" approach - or if you will they view it as more human
like.As if humans don't really think - they just have it all in
their head.

I think what humans do best is reason.   All animals have wonderful
pattern recognition and memory about things,  my bird talks and says
things in context - he says "hello" when the phone rings and so on.
But what seems to set our intelligence apart isn't that we have more of
this,  it's the fact that we can reason on it.   UCT is far closer
to this way of attacking a problem than looking up a set of patterns on
the board and hand crafting hundreds of rules for telling you which move
to play.

And yet still it gets criticized as if it's a "dumb" approach (based
mostly on the fact that it's not based on a database of knowledge which
most classic programs essentially are.)  

In my view,  the old classic knowledge based programs are like idiots
that have a lot of knowledge of trivia, but no practical real world
wisdom.  

I'm not criticizing modern programs like GnuGo and MFGO,   they have
kept up by adapting and adding lots of clever modules that in a sense
"reason things out too", such as global search in MFGO - but UCT really
takes things in a wonderful direction in my opinion. Of course there
is nothing wrong with exploring all alternatives and methods.

- Don


Harald Korneliussen wrote:
> In the thread "On average how many board updates/sec can top Go
> programs do these days?" mingwu said of the way MC/UCT programs work
> that he'd hardly call it intelligent.
> I've thought (and argued elsewhere) that the MC/UCT approach is
> fundamentally more "intelligent", in the sense of working more like
> human intelligence apperas to do, than traditional game tree search.
> How did humans learn to play Go? Well, they tried things, figured out
> what worked and what didn't. And that is what a UCT seach does as
> well... the main differences is that it's much worse at
> generalization, and (for that reason) throws away most of what it's
> learned from game to game. Still, it plays well with vastly less a
> priori assumptions/knowledge than a traditional minimax-type search.
> There is some, of course, but humans also rely on some a priori
> knowledge according to the philosophers :-)
>
> To illustrate it a bit, I know of a game in which UCT's advantages are
> even more striking. The game designer Nicholas Bentley recently won an
> award for a game he calls Mind Ninja (silly name, I know, but bear
> with me: it's a very interesting game). It's a generalized
> connection/shape-building game, which begins with a negotiation phase,
> where one player proposes the pattern to be built, and the other
> decides whether he will be the "builder" or the "blocker".
> There are extremely many possible patterns. On the regular board,
> there are 127 points, which can be empty or coloured - the number of
> colours are also part of the pattern rule. By a pattern rule, each
> possible position must be either a win for the builder or not (the
> blocker wins if there are no more legal moves and the builder hasn't
> won). Each partitioning of positions into wins for the builder and
> undecided positions/wins for the blocker can constitute a pattern
> rule.
>
> Now, I believe MC/UCT can play this game, and play it well. (I'm
> working on an implementation). It will adapt to pattern rules it has
> never seen before, just like a human. It doesn't need any "hints" in
> the form of evaluation functions, like chess programs use - in fact,
> the nature of the game makes applying that approach pretty much
> impossible. Like a human, it can consider a pattern rule, and try to
> figure out which side has the advantage. Humans can certainly choose
> rules which would give them an advantage (I imagine nim-like pattern
> rules could work), but with trial and error, so could the program -
> and the game has a way of balancing that advantage, too.
>
> Would a MN-playing program be intelligent? I'm pretty sure they would
> have said so ten years ago, at least :-) But regardless, I think it
> could illustrate the potential of this new algorithm.
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
>   
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[Heikki Levanto]

On Wed, Jan 16, 2008 at 01:30:59PM +0100, Gian-Carlo Pascutto wrote:
> There are no advantages to allowing suicide, it is simply expensive for me
> in terms of speed to forbid it in playouts. If this is not the case for
> your board structure then you will probably want to forbid suicide.

I do not see how that can be! You need to check if the move was a suicide,
and if so, remove it from the board anyway. That must be the expensive part,
calling the move illegal if that happens ought not to be very expensive. But
then again, I do not know the internals of your program...

Regards

   Heikki

-- 
Heikki Levanto   "In Murphy We Turst" heikki (at) lsd (dot) dk

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] How to get more participation in 19x19 CGOS?

[Mark Boon]

-Original Message-
From: [EMAIL PROTECTED] [mailto:computer-go-
[EMAIL PROTECTED] On Behalf Of Mark Boon
Sent: Tuesday, January 15, 2008 10:11 AM
To: computer-go
Subject: Re: [computer-go] How to get more participation in 19x19  
CGOS?


As suggested by David Fotland I made a simple referee type of setup
so that I can have two engines play each other continuously. I got it
working with GnuGo but with MoGo I get an "Access denied" message
when I try to start it from the referee program. When starting from
the command-line I have no trouble.



OK, never mind the question above. Although the strange message was  
caused by a mistake of mine, the real reason MoGo didn't seem to be  
working was that it puts out a lot of data on stderr. And somehow  
this blocks the stdin stream until I actively read the error stream.  
Adding a thread to read the error stream when there's data available  
fixed the problem.


MoGo appear very slow, but I can run it overnight.

Mark

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Suicide question

[Gian-Carlo Pascutto]

> Gian-Carlo Pascutto wrote:
>
>  > Multi-stone suicide is allowed, single stone not.
>
> I hadn't even considered suicide.(It would be a major change for me,
> as neither my Gui nor my board system allow such moves.)
>
> The question is Why do you do it?
>
> a. Just in case you wanted the entire program to support suicide go
>
> or
>
> b. Because that has some advantage as a random playout.
>
> If it was b, can anyone explain why suicide is a better evaluation for
> a normal (non suicide) game.

None of the above!

There are no advantages to allowing suicide, it is simply expensive for me
in terms of speed to forbid it in playouts. If this is not the case for
your board structure then you will probably want to forbid suicide.

Leela does not allow suicide in the GUI and the engine itself will also
never suicide in games.

-- 
GCP
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] Suicide question

[Jacques Basaldúa]

Gian-Carlo Pascutto wrote:

> Multi-stone suicide is allowed, single stone not.

I hadn't even considered suicide.(It would be a major change for me,
as neither my Gui nor my board system allow such moves.)

The question is Why do you do it?

a. Just in case you wanted the entire program to support suicide go

or

b. Because that has some advantage as a random playout.

If it was b, can anyone explain why suicide is a better evaluation for
a normal (non suicide) game.

Jacques.


___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] non-symetrical bandit-based MC planning

[Olivier Teytaud]

Does someone have positive results
for non-symetrical bandit-based planning, e.g.
using a bandit with more exploration for the opponent
than for oneself.

Best regards.

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

[computer-go] The "intelligence" can of worms reopened

[Harald Korneliussen]

In the thread "On average how many board updates/sec can top Go
programs do these days?" mingwu said of the way MC/UCT programs work
that he'd hardly call it intelligent.
I've thought (and argued elsewhere) that the MC/UCT approach is
fundamentally more "intelligent", in the sense of working more like
human intelligence apperas to do, than traditional game tree search.
How did humans learn to play Go? Well, they tried things, figured out
what worked and what didn't. And that is what a UCT seach does as
well... the main differences is that it's much worse at
generalization, and (for that reason) throws away most of what it's
learned from game to game. Still, it plays well with vastly less a
priori assumptions/knowledge than a traditional minimax-type search.
There is some, of course, but humans also rely on some a priori
knowledge according to the philosophers :-)

To illustrate it a bit, I know of a game in which UCT's advantages are
even more striking. The game designer Nicholas Bentley recently won an
award for a game he calls Mind Ninja (silly name, I know, but bear
with me: it's a very interesting game). It's a generalized
connection/shape-building game, which begins with a negotiation phase,
where one player proposes the pattern to be built, and the other
decides whether he will be the "builder" or the "blocker".
There are extremely many possible patterns. On the regular board,
there are 127 points, which can be empty or coloured - the number of
colours are also part of the pattern rule. By a pattern rule, each
possible position must be either a win for the builder or not (the
blocker wins if there are no more legal moves and the builder hasn't
won). Each partitioning of positions into wins for the builder and
undecided positions/wins for the blocker can constitute a pattern
rule.

Now, I believe MC/UCT can play this game, and play it well. (I'm
working on an implementation). It will adapt to pattern rules it has
never seen before, just like a human. It doesn't need any "hints" in
the form of evaluation functions, like chess programs use - in fact,
the nature of the game makes applying that approach pretty much
impossible. Like a human, it can consider a pattern rule, and try to
figure out which side has the advantage. Humans can certainly choose
rules which would give them an advantage (I imagine nim-like pattern
rules could work), but with trial and error, so could the program -
and the game has a way of balancing that advantage, too.

Would a MN-playing program be intelligent? I'm pretty sure they would
have said so ten years ago, at least :-) But regardless, I think it
could illustrate the potential of this new algorithm.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/