[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [gnugo-devel] Move valuation question
From: |
Arend Bayer |
Subject: |
RE: [gnugo-devel] Move valuation question |
Date: |
Sun, 19 Jan 2003 16:31:21 +0100 (CET) |
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).