FW: [computer-go] SlugGo approach: GNU vs.Goliath

["Mark Boon" <tesujisoftware@xxxxxxxxx>]

Thanks David for taking the time to write an extensive reply to my posting
and my questions. It turns out Vlad is right, I did my experiment for the
wrong reason as I had misinterpreted one of your posts. So rather by chance
I found out a few interesting things. Serendipity!?!

I think I understand your SlugGo approach a lot better now than I did
earlier.

> The evaluation used by SlugGo is to combine the GNU Go value of the
> original
> candidate move with 2 other evaluations, one based upon influence and
> the
> other based upon territory, and there is another bonus added when the
> candidate
> move is on both the US and the THEIR list. The influence and territory
> evaluations
> are done only at the end of the 16 move lookahead depth. All 3
> evaluations are
> normalized prior to being summed, and both the influence and territory
> evaluations
> are also weighted according to move number so influence is important in
> the
> beginning and territory is important at the end (the weighting
> functions cross
> at move 83 right now). So we are combining the GNU Go evaluation of THIS
> move with the influence and territory evaluations of the FUTURE board.

This has two bits of information I was missing earlier. I take a single
evaluation of Goliath's score of the future board only. You combine
evaluation of the current candidate with its future board. I can see how
this reduces the effect of the horizon a great deal, but I can't see yet why
combining the evaluation of the future board with the current board helps.
To me this is counter-intuitive, so I'll have to think a bit more about
that. Any rationale from your side why you chose to do it this way? I
suppose your territory/influence based evaluation doesn't account for
dead-groups, so you don't 'see' the threats at the end of the sequence? And
do you intend to keep this evaluation approach when you add branching?

The other bit is that you generate moves for both sides. I did see this in
one of your posts, but didn't see the full point of it. Now I understand
why, you need it because you include evaluation of the current move. Since
for defensive moves it evaluates to no or small gain , for those you need to
complement them with the gain for the opponents move.

I decided not to generate the THEIRS list because I think making decisions
based on the opponents precise move doesn't work well. It would only work
well if I can decide which opponents moves are related to moves in the US
list, and boost those. I think this is what you do? I would have used it too
if I had had the time. I decided to try a simplified experiment first, just
to see what would come of it.

Do you also actually play out the oponents move as canidates? Or are they
only examined one ply deep?

> This evaluation function is quite different than what SlugGo does. I
> think
> your choice here is surely amplifying the horizon effect.

Indeed this is what seems to happen.

As to your speculations: you may be right about most of them. Recently I
learned that GNU Go doesn't do global lookahead at all, it's all based on
static evaluations. I must say this surprised me. It plays very well for a
program that doesn't do lookahead. So I can see that it would benefit
greatly from almost any form of lookahead added to it. Goliath probably has
a simple evaluation compared to GNU Go, but compensates it by already doing
lookahead itself. This confirms something I've been saying all along,
improvements in computer Go should largely be sought in improving the
evaluation instead of increasing the number of moves it reads.

I just had a thought: instead of taking the score of the end-position I
should take the value from Goliath's internal cache. That will give the
result of the (usually stable) position resulting after Goliath's internal
lookahead that would most likely parry any threat. Only difficulty will be
then to take care of gote/sente, but it may be worth a try to see if it
improves things.

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