Re: Rep : [gnugo-devel] Another cosmic patch

[Arend Bayer]

> Compared to the patch I sent three days ago, it adds a new
> function choose_strategy() that uses the score estimation
> and the level of completion of the game to decide whether
> gnugo should play agressively or conservatively (to keep
> the lead, if any)

This looks like a very productive thing to do and experiment with.

I also want to help a bit next week with evaluating the cosmic GNU Go.
The pair-go approach is not exactly immediately appealing, but if it
offers clear benefits that we cannot get by other means, I am in favour
of it.

One thing Gunnar mentioned on NNGS is that it could be exploited (i.e.
if the opponent knows which of the two players will move next, he could
exploit this players' specific weaknesses), and that it might make sense
to choose the player randomly instead.

This would also add to gnugo's indeterminacy. The problems of the
current approach to indeterminacy (randomly selecting among patterns
with identical values) have been discussed often enough on this list.

One comment about style: Pls try to follow the code formatting as you
see it in the existing code. I have no religious opinions about
"correct" style (or if I had them they would definitely not agree with
the existing gnugo code), but I think it pays to keep style consistent
across the project. That makes simply less suprises when reading the
code.
I've modified the patch accordingly for merging. (Specific issues:
shiftwidth is always two spaces; position of opening and closing braces
for if and else statements; formatting of multiple line if-conditions;
lines should usually be less than 80 columns.)

> It also  adds a new function whose_loose_territory() to
> influence.c, which is a attempt at defining something
> whose_territory() and whose_moyo().
> The eventual idea is to try to use whose_loose_territory()
> instead of whose_territory() at some later stage in the
> influence code to use the breakin reading to break into
> moyos instead of just into territories. This is controlled
> by the global variable "use_optimistic_territory"

> As this doesn't quite works at the moment (it's very very
> slow) it is not activated in the patch, but feel free to make
> experiments :-)

I might indeed do so :-)

Arend