Re: [Computer-go] Seki in playouts

2015-04-19 Thread Igor Polyakov
I just tried this, and included code in the playout to save groups in 
atari by counter-capturing enemy stones. It still chooses to connect in 
that situation, so I am going back to passing in playouts.


On 2015-04-16 3:41, Aja Huang wrote:



On Wed, Apr 15, 2015 at 12:24 PM, Igor Polyakov 
weiqiprogramm...@gmail.com mailto:weiqiprogramm...@gmail.com wrote:


5. But it misses this because squeezing leads to a few accidental
losses in playouts where black plays something that white doesn't
respond to


My two cents: just prevent the accidental losses in playouts then the 
program will play B8 correctly.


Aja


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


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

Re: [Computer-go] Seki in playouts

2015-04-19 Thread Hiroshi Yamashita
2. Have custom seki logic that will just prevent you from playing a 
nakade shape against a group that already has an eye


Aya does this.
But eye recognition is only if string lib is 2 and stones =2.
If probability from 3x3 pattern is zero, it is eye.
And I also have special logic for this shape.
Black never suicide except white lib is one.

Regards,
Hiroshi Yamashita

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

Re: [Computer-go] Seki in playouts

2015-04-16 Thread valkyria

Interesting position.

I am not sure how I exactly handle this is in Valkyria. My code for 
allowing or disallowing suicide is very complex.

As long as special case-handling is only executed when necessary.

In this case the pattern with two stones forming a possible eye would be 
starting point for special handling of B8.


Most important is to correctly handle the simplest cases. That is to 
prevent suicide as soon as white has an eye and only two liberties.


The next step here could be that it is not necessary to plack black B8 
if black can prevent white B8, by playing black D9 or D7 for example.
But I am not sure if it is possible to make sure that there are 
situations where this logic is bad. I would then implement the rule, and 
run simulations for a long time on an empty board and dump every 
position to a log file where the new rule triggers.


If I find situations where the new rule is bad i would then try to fix 
the rule, or if I think it is impossible or too costly I would just 
leave it as it is.


So, in other words in Valkyria I would try to detect the most clean 
basic seki variants perfectly. But I would also try to add special cases 
to the code to improve plays that might not always be correct but in the 
majority of cases. Valkyria is in principle a huge decision tree where 
all branches are hand coded.


Best
Magnus

On 2015-04-15 13:24, Igor Polyakov wrote:

I have an interesting problem with my program.

1. I have self-atari detection, but self-atari is allowed for smaller
groups like the two stone group because it can make a nakade.
2. Self-atari detection means that in most playouts the program will
let the black player suicide, but it won't let the white player
suicide because the group is too large.
3. Therefore, it has white winning playing D9 or D7 because the
playouts have black suicide
4. It has to squeeze right now because the seki loses the game, while
the squeeze wins it.
5. But it misses this because squeezing leads to a few accidental
losses in playouts where black plays something that white doesn't
respond to

I have thought about this and there's a few solutions:

1. Allow the program to pass late in playouts. In the current
implementation this leads to accidental pass-pass playouts when the
game is not finished and the program is poor at evaluating boards with
dead stones on them.

1a. Implement a special passing type that doesn't end the game, but
only allows you take back ko or just let your opponent finish their
game when you still have legal moves left you don't want to take

1b. Make the program good at deciding dead stones somehow and not
worry about pass-pass in playouts as long as it's late enough (what's
late enough? 75% of the board filled?)

2. Have custom seki logic that will just prevent you from playing a
nakade shape against a group that already has an eye

I noticed that every program does this correctly that I've seen except
for the old Mogo for Windows binary. I'd like to know how they do
this.

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


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

Re: [Computer-go] Seki in playouts

2015-04-16 Thread Aja Huang
On Wed, Apr 15, 2015 at 12:24 PM, Igor Polyakov weiqiprogramm...@gmail.com
wrote:

 5. But it misses this because squeezing leads to a few accidental losses
 in playouts where black plays something that white doesn't respond to


My two cents: just prevent the accidental losses in playouts then the
program will play B8 correctly.

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

[Computer-go] Seki in playouts

2015-04-15 Thread Igor Polyakov

I have an interesting problem with my program.

1. I have self-atari detection, but self-atari is allowed for smaller 
groups like the two stone group because it can make a nakade.
2. Self-atari detection means that in most playouts the program will let 
the black player suicide, but it won't let the white player suicide 
because the group is too large.
3. Therefore, it has white winning playing D9 or D7 because the playouts 
have black suicide
4. It has to squeeze right now because the seki loses the game, while 
the squeeze wins it.
5. But it misses this because squeezing leads to a few accidental losses 
in playouts where black plays something that white doesn't respond to


I have thought about this and there's a few solutions:

1. Allow the program to pass late in playouts. In the current 
implementation this leads to accidental pass-pass playouts when the game 
is not finished and the program is poor at evaluating boards with dead 
stones on them.


1a. Implement a special passing type that doesn't end the game, but only 
allows you take back ko or just let your opponent finish their game when 
you still have legal moves left you don't want to take


1b. Make the program good at deciding dead stones somehow and not worry 
about pass-pass in playouts as long as it's late enough (what's late 
enough? 75% of the board filled?)


2. Have custom seki logic that will just prevent you from playing a 
nakade shape against a group that already has an eye


I noticed that every program does this correctly that I've seen except 
for the old Mogo for Windows binary. I'd like to know how they do this.


seki problem.sgf
Description: application/go-sgf
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

[computer-go] Seki in playouts

2008-08-12 Thread Martin Mueller



I
did not realize that his program, even with a large tree, would not be
able to recognize the seki.  I knew of course that the original Mogo
playouts had this problem, but I thought all strong programs had
solved it by now...


Hello Erik,

seki in playouts is still an unsolved problem for Fuego as well. I  
have tried many times to fix it by disabling selfatari moves. But  
anything I tried made the program measurably weaker overall.


Martin

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


Re: [computer-go] Seki in playouts

2008-08-12 Thread terry mcintyre
There are times when self-atari is the correct play. Seki and nakade are 
probably going to require a global analysis to handle properly.

 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: Martin Mueller [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Tuesday, August 12, 2008 9:18:16 AM
Subject: [computer-go] Seki in playouts


 I
 did not realize that his program, even with a large tree, would not be
 able to recognize the seki.  I knew of course that the original Mogo
 playouts had this problem, but I thought all strong programs had
 solved it by now...

Hello Erik,

seki in playouts is still an unsolved problem for Fuego as well. I  
have tried many times to fix it by disabling selfatari moves. But  
anything I tried made the program measurably weaker overall.

Martin

___
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] Seki in playouts

2008-08-12 Thread Rémi Coulom

Martin Mueller wrote:



I
did not realize that his program, even with a large tree, would not be
able to recognize the seki.  I knew of course that the original Mogo
playouts had this problem, but I thought all strong programs had
solved it by now...


Hello Erik,

seki in playouts is still an unsolved problem for Fuego as well. I 
have tried many times to fix it by disabling selfatari moves. But 
anything I tried made the program measurably weaker overall.


Martin 


Crazy Stone now evaluates most usual cases of seki correctly. The way I 
do it is extremely complicated. I did not measure an improvement in 
playing strength from that work, but the program does not play weaker 
either.


I am happy that it now scores every game correctly, and avoids some 
horrible moves caused by misunderstanding of seki. Also, seki knowledge 
is necessary to play games with Japanese rules (tournaments in Japan are 
played with Japanese rules).


The sgf file in attachment contains a variety of interesting seki and 
non-seki situations that the playouts of Crazy Stone evaluate correctly. 
I believe it contains all the usual kinds.


Some sekis are so complicated that it is not reasonable to evaluate them 
in the playouts. That page is fun:

http://senseis.xmp.net/?StrangeSekis

My warning: if you'd like seki knowledge in your playouts, then get 
ready for headaches.


Rémi



Seki-0004.sgf
Description: application/go-sgf
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Seki in playouts

2008-08-12 Thread Erik van der Werf
On Tue, Aug 12, 2008 at 6:18 PM, Martin Mueller [EMAIL PROTECTED] wrote:

 I
 did not realize that his program, even with a large tree, would not be
 able to recognize the seki.  I knew of course that the original Mogo
 playouts had this problem, but I thought all strong programs had
 solved it by now...

 Hello Erik,

 seki in playouts is still an unsolved problem for Fuego as well. I have
 tried many times to fix it by disabling selfatari moves. But anything I
 tried made the program measurably weaker overall.

Hi Martin,

The tricky thing is to determine *when* to disable self-atari moves.
Forgive me for not going into details now; if you ask me again in
Beijing or after the Olympiad I'll say more.

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