Aboute the "Nakade problem":
1) There is in principle no problem to correctly handle nakade in
MC/UCT programs. It just a question of making the playouts do it.
2) But doing this requires some smart programming. I think all the
strong progams has been designed by the "What can I do in less than 10
lines of code that improves playing strength and does not slow down
the program"-principle. The problems with Nakade is that it requires
more effort than other stuff, so all energy has gone into for example
playing urgent shapes and that has improved the engines immensely.
3) If one does efficiently implement Nakade it is not certain that the
program will get stronger. My experience of adding L&D knowledge is
that if you mess up the balance between attack and defense you can get
problems like: "The program make invasions that does not work and
defends aginst invasions that it could easily kill" or "It does not
make territory because it wrongly thinks it can kill all invasions".
This is really hard to handle. Basically you just see from tests that
new code have a detrimental effect on playing strength, but there are
no bad moves that can be "debugged" just a subtle switch in playing
style that has a lower chance of winning.
Valkyria partially handle life and death well. In playouts it will
play the vital point right after a nakade capture for example. It has
a remaining weakness in that it does not know what Nakade shapes gives
one or two eyes, it only understands the empty space after a capture.
In such cases the status of a group is evaluated as unstable although
they may be unconditionally alive/dead. Before Mogo became invincible
I noticed that Valkyria could often exploit L&D weaknesses and steal
the victory in otherwise lost games. But the price for having L&D
knowledge is that Valkyria is at least 10 times slower than for
example Leela on the same hardware.
Surprisingly to me L&D tactics seems to be less important in computer
go. What is really important is that the program knows how to attack
and defend eyespace. If you win that fight 9 time out of 10 it does
not matter that you lose 75% of the time in that single game where it
was not settled early.
Gnugo is good at L&D, but I have seen Valkyria killing big groups on
13x13 ore larger simply because the MC programs can sniff out
weaknesses in groups long before the static evaluation can. When these
big groups die there is often no L&D problem to solve there is just a
lot of empty space that cannot be made into into two eyes.
Humans need to practice L&D a lot to get strong. But I see this as
pushups to get muscle power. If you are not good at closed well
defined problems you will also not be able to handle open ill-defined
problems. And 95-99% of all moves in good game of go are in such
positions.
So, when human opponents complaines about Nakade it just means that
the programmer has made the right design choices in what code the
playouts need to make the program as strong as possible *given the
programming effort*.
This means that are a lot of potential to make the programs even
stronger. But it may be really hard to find the right balance. You may
want to add feature A and B but the program may only get stronger if
you implement A and B simultaneously. A alone or B alone just makes
the program weaker. I think the gnugo team wrote about similar
experiences some time ago on this list.
Quoting Darren Cook <[EMAIL PROTECTED]>:
2. Mogo (and CrazyStone) are using lots of intelligence in their
playouts, and that is the cause of the nakade weakness. They are good
players, but they have preconceptions. They consider the moves required
to discover the difference between a nakade and
dead-stones-in-a-definitely-alive-group as low priority. So, in that
sense, they do have a concept of nakade.
(I hope Remi, or one of the Mogo developers, will correct me if I've
misunderstood what is going on.)
-Magnus
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
