Re: [gnugo-devel] trevor_1_25.2

[Gunnar Farneback]

Trevor wrote:
> http://www.public32.com/games/go/trevor_1_25.2
> [...]
>   I find the new definition of UPDATE_SAVED_KO_RESULT esier
> to understand.  It is intended to be functionally identical.

Agreed. It was actually the intention of the reordering of the result
codes some time ago to allow such simplifications. But maybe we should
introduce a macro

#define REVERSE_RESULT(code) (WIN - (code))

to gain more flexibility for the future.

>   With the reduced MAXSTACK, run-away reading code fails in
> a trymove assert rather than overrunning the stack.

This is a strange bug since the involved stacks (at least supposedly)
scales with the MAXSTACK value. It would be good if someone could
track down more exactly what happens.

> The new value ( MAX_BOARD * MAX_BOARD * 2 / 3 ) is still quite a bit
> deeper than GNU Go should ever try.

No, this is not safe. It's not only the reading code doing trymoves.
Unconditional_life() can get very close to filling the entire board
under certain circumstances. This was discussed in the list around
August 21 last year, in a thread with the subject "gnugo bug logs".

>   I cleaned up the EXPERIMENTAL_READING code some, so it's not
> sprinkled inside the non-experimental code.

Good.

> +    /* FIXME: Perhaps it's best to just assert here and be done with it? */
> +    /*ASSERT1(0 && "trymove stack overflow", pos);*/

As a general rule, please don't comment out code by embedding it
inside an actual comment. Instead, either use
#if 0
  [...]
#endif

or

if (0) {
  [...]
}

Occasionally it can be preferable to use "0 &&" or "1 ||" to shortcut
parts of logical expressions.

Arend wrote:
> That sounds quite good. I wonder whether it could be most successful to
> combine the two approaches. It might be that direct attacking moves like
> liberties of the string are more quickly generated directly than via a
> pattern; also, one can then continue to use the move order heuristics in
> order_moves, which seem to be quite useful. This centralized handling of
> move ordering might be more efficient than writing intelligent
> value helpers as you have done it e.g. with RA000a.

I don't think a pattern based approach can reach quite the speed of
the non-pattern one, but it's useful for finding out how to improve
the reading strategies. There's also the problem that it requires
recursive calls to the pattern matcher (since reading constraints are
used in other databases) which seems to work but I don't think anyone
can guarantee that it's safe.

> On the other hand, the special_attack/special_rescue functions more or less
> try to play the role of a pattern (their check for surrounding conditions
> really looks like pattern matching).

They *are* patterns, but in some cases more general than can be
expressed by the pattern matcher.

> By generating those special_... moves
> by patterns, one could
> - very easily do tuning of these moves (of course it is more comfortable
>   to create a pattern than to write a new special_rescue11 routine)

Absolutely, but it's not hard to add a handcoded pattern once you know
it's useful. It's just a magnitude or two slower to do. :-)

> - give them intelligent values so that they sort into the other moves in
>   a sensible order.

This can be done also with the special_* functions.

/Gunnar