gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] Updated large scale patch


From: Arend Bayer
Subject: Re: [gnugo-devel] Updated large scale patch
Date: Tue, 12 Aug 2003 10:12:02 +0200 (CEST)

On Mon, 11 Aug 2003, Stéphane Nicolet wrote:
> I think the worse problem of that patch at the moment is the
> speed. Arend posted some benchmarks yesterday, but I think
> that computer/computer games are best cases for the patch
> since they tend to be calmer than human games against gnugo.
> When almost of the board is in fire the patch will try quite
> a lot of owl-attacks against small dragons.

Yes, the benchmark suite certainly should be extended by games against
humans. Still, the benchmarks I did should be repeated with this
version of the patch.

I have some technical comments in the patch: (Feel free to ignore the
ones you dislike :-).)

> -/* Test certain moves to see whether they (too) can owl attack or
> +/* Test all the moves to see whether they can owl-attack on
> + * a large scale . Tested moves are
> + * 1. Moves that already have a move reason.
> + * 2. Are not too far away from a small critical dragon (<= 6 stones).
> + *    The distance used is the Manhatan distance, and the maximum
> + *    distance is currently 3.

What you implement is actually not Manhattan distance. Manhattan
distance is instead computed as follows:

0. Start with the dragon.
1. All directly neighboring fields have distance 1.
2. All directly neighboring fields of those in the previous step have
distance 2.
3. ...

I explain this because maybe Manhattan distance would be more
appropriate than what you have implemented.

...3....
..323...
.32123..
321X123.
.321X123
..32123.
...323..
....3...

I've numbered the fields with Manhattan distance 1, 2, 3. I think your
patch instead does the following:

33333333
32222223
32111123
321X.123
321.X123
32111123
32222223
33333333

The corners here seem way to far away to have any effect on the dragon.


> + */
> +static void
> +find_large_scale_owl_attack_moves(int color, int save_verbose)
> +{
(...)
> +  int maximum_distance = 3;  /* maximum Manhatan distance tried */
Maybe better make this a pre-processor constant?

> +  /* Identify the unstable dragons and store them in a list. */
> +  for (pos = BOARDMIN; pos < BOARDMAX; pos++) {
> +    if (IS_STONE(board[pos])
> +        && dragon[pos].origin == pos
> +        && board[pos] == other)
> +      if (dragon[pos].status == CRITICAL
> +        || DRAGON2(pos).owl_status == CRITICAL)
Better fold this into one "if".

> +      if (save_verbose)
> +         gprintf("Small critical dragon found at %1m\n", pos);
The "small" test comes only later I think, so the message is a little
confusing.


> +              /* See if that move has other move reasons */
> +              has_move_reasons = 0;
> +              for (a = 0; a < MAX_REASONS; a++) {
> +                int r = move[pos].reason[a];
> +                if (r < 0)
> +                  break;
> +
> +                has_move_reasons = 1;
> +               }
This seems worth having as separate function have_move_reason(pos) in
move_reaons.c.

> +              /* We try all large scale attacks on small dragons (and
> +                 only moves with other move reason) */
> +              if (board[target] == other)
> +                worth_trying = ((dragon[target].size <= 6)
> +                                && has_move_reasons);
> +
> +
> +              if (worth_trying) {
No need for the variable worth_trying (you can do a direct "if").

> +                /* To reduce the amount of aji allowed for large scale
> +                 * attacks, we reduce the owl limit to 350 nodes for
> +                 * attacks at distance <= 1, and 150 nodes for attacks at
> +                 * distance >= 2
> +                 */
> +                if (dist <= 1)
> +                  new_node_limit = gg_min(350, owl_node_limit);
> +                else
> +                  new_node_limit = gg_min(150, owl_node_limit);
> +                change_owl_node_limit(new_node_limit, &old_node_limit);

The hardwired numbers 350 and 150 are a bit problematic. They make less
sense for a different default level than 10, e.g. So maybe you should
instead multiply the owl node limit by 0.35 or 0.15?


Arend






reply via email to

[Prev in Thread] Current Thread [Next in Thread]