Re: [gnugo-devel] Preparatory patch

[Gunnar Farneback]

Inge wrote:
> Here is a patch that is preparatory for a more advanced handling of
> combinations of threats.

Could you try to describe your plans for how you want this to work?

> I started this change a few days ago, but I hope that it applies
> cleanly to the current version in CVS.  In particular I hope that it
> doesn't clash to heavily with Arends scheme to filter out redundant
> move reasons.

I haven't actually tried it but I'm quite certain it clashes a lot
with Arend's patch.

>  - remove all _THREAT move reasons
>  - new member in move_reason: is_threat

This might make sense, but it's not completely clear since the threat
property doesn't make any sense for some of the move reasons.

>  - All move reasons except strategic attacks and defends can now be
>    threats

Antisuji threats?

>  - handling of threats in move_reasons.c rewritten
>  - calls to add and remove move reasons changed to new calling
>    standards everywhere

I'm not satisfied with the design of this. The is_threat parameter is
a real nuisance. Quite frankly I don't see that this has improved the
code at all. I might appreciate these changes more if you explain why
they are necessary for your scheme, but I really hope it's possible to
come up with some nicer solution.

> After that I will tackle find_double_threats() in combinations.c,
> making it handle many more threats than just attacks.  For those of
> you working with readconnect, now might, by the way, be a good time to
> implement threats to connect our groups and threats to disconnect the
> opponent groups.

That has only weak connections to the readconnect code itself, which
is about connections between strings. Threats to disconnect dragons
are actually impossible to detect without rewriting the entire
amalgamation process. While this certainly is in the future plans,
it's nowhere close to "now".

> +/* truth values */
> +#define FALSE        0
> +#define TRUE         1

No, thanks. These macros don't buy us anything and are inconsistent
with the established practice (within the project) to use raw 0 and 1
for truth values.

/Gunnar