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
