[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: computer-go: Go Programming Difficulties
Dave,
My embedded comments start with "*".
-----Original Message-----
From: David Fotland [ <mailto:fotland@xxxxxxxxxxxxxxxxx>
mailto:fotland@xxxxxxxxxxxxxxxxx]
Sent: Thursday, April 12, 2001 2:10 PM
To: computer-go@xxxxxxxxxxxxxxxxx; 'computer-go@xxxxxxxxxxxxxxxxx'
Subject: Re: computer-go: Go Programming Difficulties
Please share your 40 techniques :) I think that you will find that these
techniques
* No thing magic. Just those techniques you can find in any go books such as
"cut/connect", "moyo/anti-moyo", "making_eye/destroying_eye", ...
are more difficult than you think. Most everyone uses OO techniques or OO
languages,
so that is not what is keeping computer go programs weak. The hard part is
accurate
evaluation of group strength. For example, looking at an enemy group,
If it is very weak, it is dead, and you should leave it alone
If it is a little stronger, you should play to kill it
If it is a little stronger, you should play to contain it and force it to
live in gote
If it is a little stronger, you should threaten it with sente
If it is very strong, you should leave it alone.
If you can't evaluate the strength accurately, you will let weak groups
live, or waste moves
chasing strong groups, etc.
* Taking "group strength" as an example, the strength is relative to its
surrounding groups: how many eyes the group has, and how much Qi (breath)
the group has. Compare the strength to the neighboring groups. They are
solid algorithms to count group Qi. Counting the number of eyes of a block
(1+ groups) is more difficult, but you can almost always have a good
estimate (you will have to estimate in cases you cannot do an exhaustive
search, which pros do as well).
You might pick a typical middle game postion from a 1 dan game with some
strong and dead
groups, and a big, multigroup fight in progress, and see if you 40
techniques can find
good moves. It's not easy.
* It won't be easy. But the fact that a 1k amateur can give 10 stone
handicap to the best go program after practice is just a little bit hard for
me to understand now.
* Well, "nothing is as easy as it looks".
-- Mousheng Xu
David
At 09:32 AM 4/12/2001 -0700, Xu, Mousheng (SEA) wrote:
>Hi Everybody,
>
>I have been accidentally dropped off the list for more than 8 months, so I
>should have lost a lot of fun. For the period no email came to me from the
>list, I thought it might be that everybody was busy dot-comming instead of
>doing go programming. :)
>
>There are about 40 common go techniques to implement. If all of these
common
>techniques are implemented, it's possible for the program to beat an
amateur
>1 dan. I am about to start implementing these ~40 techs but have not yet
>done it, so I cannot say with full confidence. But I feel most if not all
>these techs are not so hard to implement. Given "cutting" as an example,
you
>only need to 1) find the cutting point; 2) estimate if you can cut at the
>point and safely escape; 3) cut it. Doing 1) & 3) are straighforward, doing
>2) might be tricky but does not sound very hard. Beyond individual
>techniques, you will have to synchronize them together, which will take
>significant but not forbidden number of calculations.
>
>For those who have gone through all of these implementations, here is my
>question: what am I missing? If you use assembly, I can understand why it's
>not as easy as I have just said. But if you use an OO language, it would be
>much easier to implement. OO is much slower (10x?) than assembly, but
that's
>why CPU speed come to play. It's my religion that algorithm is much more
>important than speed.
>
>Thanks a lot.
>
>-- Mousheng Xu
>
>
>
>
>The information contained in this email is intended for the
>personal and confidential use of the addressee only. It may
>also be privileged information. If you are not the intended
>recipient then you are hereby notified that you have received
>this document in error and that any review, distribution or
>copying of this document is strictly prohibited. If you have
>received this communication in error, please notify Celltech
>Group immediately on:
>
>+44 (0)1753 534655, or email 'is@xxxxxxxxxxxxxxxxx'
>
>Celltech Group plc
>216 Bath Road, Slough, SL1 4EN, Berkshire, UK
>
>Registered Office as above. Registered in England No. 2159282
David Fotland
The information contained in this email is intended for the
personal and confidential use of the addressee only. It may
also be privileged information. If you are not the intended
recipient then you are hereby notified that you have received
this document in error and that any review, distribution or
copying of this document is strictly prohibited. If you have
received this communication in error, please notify Celltech
Group immediately on:
+44 (0)1753 534655, or email 'is@xxxxxxxxxxxxxxxxx'
Celltech Group plc
216 Bath Road, Slough, SL1 4EN, Berkshire, UK
Registered Office as above. Registered in England No. 2159282