Smoothing evaluation phases

[Sune Fischer]

I like the idea of a calm transition between different game phases.
It seems like it is something you would expect to happen naturally and
it's probably beneficial for the search stability as well.

Unfortunately I don't see a way to do it efficiently - in my case.

I've been looking over some of the programs that do this in their eval
and I get the impression they have rather simplistic evaluations.
They have one big eval with some terms for midgame and some for
the endgame, these are then interpolated by some game stage value.

I see some problems with that though, one problem is that
everything gets evaluated all the time, even if it contributes little or
nothing at all to the final score.

Another problem is how does one extend and build upon this basic design?

The way my program works right now is that there are a handful of
different specialized (mostly endgame) evaluations.

One eval for setting mate, one for king-rook-pawn endgames, one
for pure pawn endgames one for bishop-knight endgames etc..

It's easy to check which one to use and then jump straight into
an optimized eval for that special case.

I guess my question is, to those that do the interpolation thing,
how do you build a complex evaluator with this interpolation
mechanism in place?

-S.

[Charles Roberson]

I have two parts -- specialty eval and simplistic.
When there is no need for the specialty don't do any part of it.

I use the interpolation method on things that always belong in the
eval through all stages such as passed pawn and connected passed
pawn evaluation. Connected passers are worth more as they advance
but even more as the stage of the game progresses (pieces drop off
the board).

I have a special table for KBBK and KNBK endgames and some others.
Also, I have some WonEndgame bonuses that help transition to these
won endgames.

I think perfect smoothness is something you shouldn't try for.
When your opponent blunders in an even game, the score does and
should jump.

[Charles Roberson]

One of the values of scaling is many things have importance early in
the game but their greatest importance can not be realized until the
situation is ripe.

A passer is good early in the game and is worth more than a pawn.
Giving it a static value would over value it early in the match. However,
scaling it by stage (judged by pieces on board) or by pieces (can be
done several ways), guides the search toward trading pieces or
pieces of certain types so that the full value/potential of the passed
pawn can be realized.

Seems this concept could be applied to the special cases you talk of
by recognizing that a pattern "almost exists" and applying
bonus/penalties that will guide the search to the special case.
Of course, this is easier said than done.

Also, automated learning and lots of long time control matches would
help. The automated learning would create a guide to these special
cases. This is the same as in automated learning giving a program
with 6 man tablebases a long term advantage over programs with
5 man tablebases. The automated learning will become a guide
to the 6 man tables.

Effectively, automated learning allows a program to accentuate
its strengths. This is the same for scaling the values of long term
advantages.

I am not sure if I answered your question. I basically told why
and not so much how.

[Dan Honeycutt]

Sune:

I can tell you one thing I tried that seemed to do no good - I split the game into 6 stages rather than the more conventional 3 (open, mid, end). About the only thing that seemed to make sense with this was the PST for the king, which transitioned smoothly from "stay out of the center" to "go to the center" as the game progressed. Other evaluation factors; knight outpost, trapped piece, etc I never could see any intelligent way to weight these for the game stage.

Best
Dan H.

[Sune Fischer]

Hi Dan

I think 3 phases are more than enough, I plan to only have two phases.
I think the opening phase is not that important since often the book will take care of it and the midgame eval should work okay for the opening also.

The thing is that the endgame phase can develop into so many different directions, each ending with its own set of objectives. E.g. is it worth the time to do mobility for the rooks in a KR ending? Maybe here it is better to go 15% faster in nps or try to block the passed pawns instead which would of course lower the mobility.

The technical aspect of it is how does the score jump when you trade off the last knight and suddenly turn off some eval terms.

If there are more terms like this it is possible they can accumulate for one side and produce quite a nasty jump or drop of score.

-S.

[Sune Fischer]

Hi Charles,

Seems this concept could be applied to the special cases you talk of
by recognizing that a pattern "almost exists" and applying
bonus/penalties that will guide the search to the special case.
Of course, this is easier said than done.

Yes quite right. This could also be a problem, that there aren't any "almost the right pattern" scores.

This could be solved perhaps by evaluating a KRN endgame as KR position (simply ignoring the knight) and then evaluate it as a KN endgame in the same way, then smooth the evals by something like
eval = 0.25*KN+0.25*KR+0.50*KRN
I fear it would be very expensive indeed, not to mention complicated just to figure out which endgame evals to use

Also, automated learning and lots of long time control matches would
help. The automated learning would create a guide to these special
cases. This is the same as in automated learning giving a program
with 6 man tablebases a long term advantage over programs with
5 man tablebases. The automated learning will become a guide
to the 6 man tables.

Learning will in theory solve almost everything, but the question is how to
do the implementation

The eval terms will not build themselves I fear, but automatic tuning
would still be a big help.

-S.

[Charles Roberson]

I would not score KRNk special verus KRk. Both should get a bonus
for being a won endgame (this allows search guidance when the
position is seen at a leaf node).

I've had several ideas for automated learning. But, I've concluded
automated learning is better (in some case much better) when
you have EGTB's. Various types of learning would score a position
poorly becuase it ended in a draw or lose. However the position
is a won position and the program didn't search deep enough.
This type of learning uses the end result to learn.

There are several other types of learning. In an ICCA article from
a decade ago, Bob Hyatt describes what goes on in Crafty. It is rather
neat and doesn't require knowledge of how the game turns out.
It creates a position with a value in the learn file when a move is made
with a score and then a few moves later the score drastically changes.
This compensates for incorrect position evaluation whether due to
lack of knowledge or merely the horizon effect.

This is sort of like developing intuition. It does create a guidance
toward or away from previously learned positions.

I've looked at and dreamed up several methods utilizing end result
info. But, there are many pitfalls to them. Bad info, once in, takes a
while to get it out.

I've created some automated tuning code and tuned various parts
via test suites. This is quite fun. It did bear some fruit but it also
created some problems.

Also, there is automated learning of functions. I did this with
neural networks in grad school and plan to use it for chess programs.
It is interesting but seems somewhat limited.