gnugo-devel
[Top][All Lists]
Advanced

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

RE: [gnugo-devel] a patch from a newbie :)


From: Portela Fernand
Subject: RE: [gnugo-devel] a patch from a newbie :)
Date: Thu, 12 Sep 2002 16:17:55 +0200

Arend wrote:

> (...)
> (I gather that nando is already working on refinements, but I hope that
> this discussion is still worthwile.)

It definitely is. And while I haven't coded anything yet (partly because of
a busy schedule), I'm reviewing the code and thinking a lot whenever I can.

> [Nando, I didn't think about what happens when changing move reasons to
> tactical attacks/defenses. It could be that e.g. a tactical defense move
> is simply ignored, because the worm is considered alive anyway.]

It's a bit more complicated than that. So, if we are to make changes to
move valuation routines, I'd prefer now to do it in the owl code where it
could be used later for other purposes as well.

> Probably as a start it would be absolutely sufficient to start with a
> heuristic such as "a owl attack move with result GAIN is worth
> 0.5*dragon[aa].effecive_size".

Another approach would be to get the effective size of the involved worm. If
by any chance it happens that more than one worm is captured, we could
simply
just take the biggest one into account.

> One way to implement such a thing would
> be to set such dragons ALIVE, and make two new move reasons such as
> OWL_GAIN_S_TH, OWL_PREVENT_LOSS.

Yup, exactly what I'm thinking about. Here I must be careful, but I'd like
to use the .what field for the worm, not the dragon (knowing the worm, it's
easy to find out the dragon if we need to)

> Anyway, I think the most relevant parts in the code are
> - owl_move_reasons (as addressed already in the patch)
> - make_dragons() as mentioned above
> - in case of new move reasons: add some code in in value_moves.c:
>   estimate_territorial_value()

Again, "yep", these are the spots I've seen while reviewing. Unfortunately,
I probably won't be able to start to code before the week-end. So, do not
expect anything before next week...

Two questions :
- I don't see how to break down this step into smaller ones. Suggestions ?
- In case we agree it must be done in one block, should I use some
  EXPERIMENTAL_xxxx define ?

> There are, of course, lots of other places that gather information from
> owl_... calls, but they are not as important I think (and can be adjusted
> later).

Ack.

> I hope this is helpful.

Definitely. Thanx :)

/nando




reply via email to

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