Re: [gnugo-devel] set_depth_values()

[Arend Bayer]

Gunnar wrote:
> Arend wrote:
> > I just wanted to add some semeai depth values/node limit to
> > set_depth_values in utils.c, but I don't get what this complicated code
> > is trying to do. And frankly, I don't think I am the first one who doesn't.
>
> It was much simpler in the beginning but has gradually become more
> complex. I think Dan has done most of the tweaking there.
>
> > Apart from atari-atari, the depth settings are exactly identical for
> > levels 10 and 9.
> > Levels 7 and 8 are identical apart from the setting of owl_node_limit.
> > As this has a rather moderate jump from 450 to 400, whereas in the next
> > step to level 6 it drops to 325, I can't see why this should make sense.
>
> It is worth noticing that the depth values are not the only things
> changing with the level. E.g. below level 5
> find_more_owl_attack_and_defense_moves() is no longer called.

Oops, I missed that bit. [Anyway, I think I should make clear that my
recently rather frequent discussing about complicated code isn't meant as
a complaint. (And e.g. my added code in influence.c certainly could go
through a cleanup, too...)
Just as a matter of fact, that kind of non-obvious code makes additional
changes a lot more troublesome. Probably one simply has to accept the
fact that a project like GNU Go requires a third of the patches to be
cleanups, otherwise it will step-by-step get closer to being pretty
unchangeable.]

Let me see: At level
>= 10: superstring stuff is used (this is the same as setting
        superstring_depth to 0 for level <= 9)
>= 10: some more backfilling  (this is the same as setting
        backfill_depth2 to 0 for level <= 9)
>= 9: owl_defend uses owl_vital_apats.db (maybe this should be
        controlled by a depth setting instead?); I've recently copied the
        same rule to owl_analyze_semeai
>= 8: owl_threats are used (disabled at the moment)
>= 8: owl_analyzse_semeai() is used (disabled at the moment; might
        be unnecessary once it has variable depth settings?)
>= 8: estimate_score() is called. (Is this really time critical? If so,
        we could get a score out of the territory valuation of
        initial_influence and initial_opposite_influence at almost no
        cost instead.)
>= 6: find_more_owl_attack_and_defense_moves() is called.

> Ideally the levels should be related to the speed of the engine,
> probably exponentially, while keeping the playing strength as high as
> possible at each level.

> I don't know how well the level system currently works, but something
> like that should be the aim.

Sure, that is what we want. The current system is definitely out of tune
since we disable owl_threats, levels 8 and 7 are pretty much identical.
Also, I suspect that levels 9 and 10 are pretty close.

IMHO most of the above rules should and could be directly handled in
set_depth_values(). Those that can't should be mentioned in a comment
above set_depth_values().

> I have nothing against simplifying the code if it can be made to work
> well enough, but the formula for *_depth above doesn't look good. You
> definitely don't want the main depth to fall lower than 6 or 7 or so
> and some other depth parameters probably shouldn't fall all the way
Well, then the level shouldn't fall below 3 :-), (which it probably
wouldn't with that drastic formula)...

> down to 0 either. On the other hand you want some of the more
> expensive depth parameters to fall off faster than the formula says
> early on.
...but I see your point here.

Still I guess simply doing
        .._depth = .._DEPTH + level - 10
would do worse than the current settings. The expensive depth settings
are typically quite low anyway, aren't they?

Of course, another problem that is not trivial to solve at all is that
one might want the time needed for genmove to be more predictable. This
would mainly require shrinking the owl_node_limit if there are a lot of
dragons to be analzed.


Arend