Re: [gnugo-devel] Preparatory patch

[Inge Wallin]

Gunnar wrote:
> Could you try to describe your plans for how you want this to work?

I will be back with a more thorough explanation of this.  I haven't
finished the final design of it all yet, but I know how I want simple
combinations of threats to work.

> >  - 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.

No, it doesn't.  But it makes sense for most of them, many enough that
I think it is OK to have a struct member that says that it is a
threat.  Or put another way: There are few enough move reasons where
it doesn't apply that it makes sense anyhow in a global sense.

> Antisuji threats?

No, I missed that one in my explanation.  Antisujis can't be threats
either.  On the other hand, an antisuji is not a move reason.  Rather,
it is a non-move reason that you have crammed into the move reason
struct for convenience.

> >  - 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.

I will remove the is_threat parameter for those functions where it
doesn't make sense.  The problem is that nowadays things are happening
at a speed where if you don't send in your patches immediately you
will be so badly out of sync that you have to redo much of your work.
I wanted to send in something fast that works, and then fix the
details in the next patch.

But for the rest of the move reasons, in fact for the overwhelming
majority, the is_threat parameter makes perfect sense and is, in my
opinion, no nuisance at all.  If we continue down your path we will
eventually end up with a
ATTACK_WITH_TWO_STEP_APPROACH_MOVE_GOOD_KO_THREAT, which is much
worse.  In fact, if the roles had been reversed, I would have rejected
your patch where you came up with the ATTACK_MOVE_GOOD_KO and
OWL_ATTACK_MOVE_GOOD_KO reasons since it isn't extendable with
reasonable effort.  For instance, do you yourself want to have
ATTACK_THREAT_GOOD_KO and associates which would be the next natural
thing to do?

I state that the current scheme makes it more or less impossible to
create a general machinery that handles threats and combinations of
threats.  My scheme is a remedy of this.  If you or somebody else can
come up with something better, then good.

> > 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".

I think you are a bit confused here.  A connection is a connection and
a threat to connect is a move that will fail to connect if the
opponent doesn't answer.  In that case we can connect on the next
move.  If this threat is combined with another meaning of the move
then we can use the threat as a kikashi while keeping sente like we do
with attack threats now. 

I have no plans on reversing amalgamation now and I don't think I will
try it in the forseeable future.

> > +/* 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.

I think it buys us something.  A call like

  add_attack_move(pos, worm, WIN, TRUE);

says more about what is happening than

  add_attack_move(pos, worm, WIN, 1);

There is a reason why we use (0, GOOD_KO, BAD_KO, WIN) instead of 
(1, 2, 3, 4) you know.  But if you say so, I can change it.  What is
the opinion of the rest of you, maybe especially Dan?

        -Inge