[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Advice on evaluation



Thanks.  Now that I had a good nights sleep, and after reading
all the thoughtful responses, I've decided to stick with my
current one-value group strength evaluation.  Mark Boon made
a very good reply, which I'm including below.

It's clear to me now that group strength should be a single value, 
approximately the average of the white-to-move and black-to-move
values.  This is better than my old internal model, which was
that group strength is an approximation of the probability that
the group will live.

I'm still thinking about the related problem of estimating how
many points you can get by attacking a group.  Sometimes is is
one point per stone in the group because you can kill it, and
sometimes it is just a few points you gain by chasing it
around for a while.  Currently I always assume an attack can
kill, so Many Faces wastes lots of moves attacking groups
that can't be killed, only chased.

David


At 05:00 PM 5/17/99 +0200, you wrote:
>     Hi David,
>
>The problem posed is one of the most basic, and therefore almost
>automatically one of the most complex, of programming Go. For Goliath I've
>always used the method of searching for both sides to start. The value of
>the move is the difference of the two results. This of course means that
>you end up reading twice as much, but I don't think that can be helped
>really. Anyway, it's generally less costly than ending up reading one more
>ply.
>
>I've not thought about using two values very much, but in general it feels
>wrong. There should be one value of the group which is roughly the average
>of black playing first and white playing first. The problem with having the
>value or status of a group depend on who's to move is that there may be
>several unclear groups on the board. Do their value (or status) swing back
>and forth upon every color change? Surely not! When there are more than one
>unsettled groups on the board you can only save/kill one at the time.
>
>One example how this can go wrong horribly is when you have more than one
>weak group. Any move tried that ends in gote will evaluate one or more of
>the groups in favour of your opponent. Therefore, the best the program can
>do is to play a sente move. It will even prefer to play point-losing (ko-)
>threats, just in order not to have any of the groups to be evaluated in
>favour of the opponent.
>
>The way I solved the problem was to use goals to guide reading and
>evaluation. It can roughly estimate a goal by statically evaluating the
>goal to be achieved by one side, and add it to the value when it gets
>achieved by the other side. Very often you can already select the most
>important goal on the board. If you know about where you're going to play,
>you don't need to read for both sides. You just do a single search for the
>best move locally. Of course, if the group concerned is very big, you
>easily get into large number of candidates. You'll have to try to select
>just the few most appropriate moves for the current goal at hand, and
>that's of course what Go programming is all about. How to prevent the
>number of candidate variations get out of hand.
>
>Of course, this method of using goals only works properly if the goals do
>not overlap. This was always rather underdeveloped in Goliath and I think
>its strength could have improved a stone or two by just taking overlapping
>goals into account (which is not trivial to do properly). At the moment it
>very often chooses the most obvious way to achieve the most important goal,
>whereas it could easily have found a way to achieve multiple goals. This is
>the 'say boo' effect where attacking a computer program sometimes results
>in a very cowardly response that protects a local defect in its position
>without looking for more optimal moves globally. This is a weakness not
>unique to my program. (At least it wasn't a couple of years ago.)
>
>Hope this is any help.
>
>Regards,
>
>     Mark Boon
>
>P.S. I receive the computer-go messages through a forwarded account which
>unfortunately means I can't post anything. I don't want to register with my
>current account either, because I will receive everything twice. Please
>forward it to the mailing-list if you feel it's worth it.
>
>
>
>This communication is for informational purposes only.  It is not intended as
>an offer or solicitation for the purchase or sale of any financial instrument
>or as an official confirmation of any transaction, unless specifically agreed
>otherwise. All market prices, data and other information are not warranted as
>to completeness or accuracy and is subject to change without notice. Any
>comments or statements made herein do not necessarily reflect those of
>J.P. Morgan & Co. Incorporated, its subsidiaries and affiliates.
>
>