RE: [gnugo-devel] Move valuation question

[Arend Bayer]

Nando wrote:

> Dan wrote:
>
> > > I'm not sure what to do, but what about following ?
> > >
> > >     this_value = 2*dragon[aa].effective_size - gg_abs(score);
> > >     if (this_value < 0.0)
> > >       this_value = 0.0;
> >
> > This doesn't look right to me, however.

> Indeed, after a bit of testing, I now understand why.
>
> > (...). Yet the right thing may be to gamble (...)

Yes. But I doubt it makes sense to value a uncertain owl defense _less_
than a strategical defense move on a dragon with _certain_ owl result.

(Btw, we should not pass score but instead
  our_score = (color == WHITE ? score : - score) to
review move_reasons. This would kill all the gg_abs(score) and
(color == WHITE && score > xx )
 || (color == BLACK && score < -xx)
stuff in value_moves.c.)

> > We also need to know whether the
> > score estimate is certain, for example, how far we
> > are from the end of the game.
>
> This got me thinking and I came up with following patch, which I'd like to
> submit for discussion/review (although it can be safely added into CVS as
> is). I tried to implement what I hope to be (or become soon) a good
> approximation of :

I like this, but...

> - the score (balance in terms of solid territory)
> - the "power" (balance in terms of influence)
>     the implementation currently uses the territory valuation,
>     but this is possibly not the best choice for that purpose.
> - and the game advancement (fuseki, chuban, yose)
>     returned as a value between 0.0 (start) and 1.0 (game is over)

...IMHO you should just use the score as calculated by the influence code,
instead of creating new tunables with WEIGHT_TERRITORY etc. E.g.

1/board_size * \sum_ii abs(territory_value[ii])

Or  1/board_size * \sum_ii territory_value[ii]^2

(Of course this needs be corrected for occupied intersections.)

(And we could use influence_score(INITIAL_INFLUENCE) and
influence_score(INITIAL_OPPOSITE_INFLUENCE) as lower and upper bound,
respectively, instead of the old scoring function.)

> A couple lines are added in do_genmove(), which will only do some debug
> output, so it won't (and shouldn't) have any effect on the engine for the
> moment. The point of the patch is to test whether these algorythms are
> reliable and/or useful.
>
> One simple feature we could implement quickly would be to teach GG the art
> of... resigning. I'm thinking of a (very) conservative policy like:
> - 50 points behind (for a 19x19)
> - no more critical or weak opponent dragons (all either dead or alive)
> - the game is ending (game_status > 0.7 with current code)

Certainly you would have to make it dependent on the number of handicap
stones, too. I think
influence_delta_territory(INITIAL_INFLUENCE, INITIAL_OPPOSITE_INFLUENCE)
would be a useful criterion, too (for measuring how much the position is
played out).