evaluation idea

[maksimKorzh]

Hi guys

I've finally reached the state of development in my engine when it's time to work on evaluation.
Obviously adding pawn structure and say piece mobility scores is making engine stronger but
here's the thought that doesn't let me alone for a long time:

HOW CAN WE GIVE THE ENGINE AN IDEA OF THE "PATH" TO FOLLOW IN ORDER TO START GETTING CERTAIN TYPE OF POSITIONS IN THE MIDDLEGAME?

I mean getting certain type of positions is something that GMs do and how they are different from club players.
While club players just know openings good and have a solid practical playing strength still they feel lost in unfamiliar types of positions.
I can say even more - they don't always know how to avoid those types of positions and the only thing they can operate is an opening repertoire.

On the other hand GMs are free from opening patterns because they simply know what kind of position they would like to reach in the middle game for a comfortable play.

Let's take this position as an example:
[d]r2q1rk1/ppp2ppp/2n1bn2/2b1p3/3pP3/3P1NPP/PPP1NPB1/R1BQ1RK1 b - - 0 9
The center is closed and whites have a potential of generating king side attack.

Modern engines most likely won't reach this type of position (apart from leela probably, so I mean alpha beta engines without NNUE)
So I was thinking like how to give an engine an idea to reach this like type of position.
For now it's only theory and my tests don't give any positive results, but anyway I would like to share the concept:

Assuming that every position has it's unique hash key we can exactly match the particular position during the search
and in this case simply record pre-stored score without involving static evaluation. (this is almost like weights in NN if I understand then correctly)
So If we imagine a database of this like "key" positions leading engine to a certain type of positions in the middle game then in theory we may LEAD our engine through the certain "PATH".

So it's something like as if human player was responsible for the strategic development while engine ensures that no blunders made.

WHAT DO YOU THINK ABOUT THIS?
Thanks in advance!

[Harald]

I can't speak about neural network engines.

In classic chess engines there is no real plan to follow. (Though I have seen attempts in Prolog.) There are only lots of evaluation terms for all situations. The engine does not say "today I want to win with a kingside attack, whatever the opponent plays." The engine reacts flexible on every change on the board and tries to optimise all evaluations in parallel. If it found a weakness of the opponent then that can easily be attacked and that determines the course of the game.

During the search the typical helper arrays like piece square tables, transposition table, history move table, refutation table and killer moves are available to guide through the game on a short time local path. It also helps to have midgame and endgame evaluations and a smooth transition between them.

I am sure the chessprogramming wiki has a lot of evaluation information. You should probably start with some typical basic terms from these points:

- pawn structure (passers, connected passers, distant passers, square rule, isolated pawns, double pawns, pawn chains, weak pawns, rams, blocked center, pawn storms)
- king safety (castling, pawn shield, direct and hidden sliding attackers)
- mobility (count attacked squares where they are, with which piece, defending own pieces, attacking which opponent pieces or weak pawns, trapped pieces)
- special piece terms (bishop pair, rooks on half/open files, rooks behind passers, rooks on/near opponent king's file, rooks on 7th/8th rank, queen near opponents king, knights not in the corners, knight or bishop ouposts, kings in opposition)

Sometimes some evaluations parts can collect informations which modify the weights of other evaluations:
http://www.fraserheightschess.com/Docum ... _Types.pdf

And if you want more this is an disputed but interesting source of evaluation ideas:
http://www.winboardengines.de/doc/Littl ... endium.pdf

[xr_a_y]

Well I guess that the search scoring a position like 20 ply deeper is somehow already a "plan" no ?

One of the best way to "orient" the search (or at least not let it prune) in the "good" direction is to tune the attack and king safety part of the evaluation (this will especially works against weaker opponents).
Pawn structure and ability to predict pawn evaluation for end-game may remain what makes a win against an equal opponent.

At least that's the way I get it ...

[maksimKorzh]

I can't speak about neural network engines.

In classic chess engines there is no real plan to follow. (Though I have seen attempts in Prolog.) There are only lots of evaluation terms for all situations. The engine does not say "today I want to win with a kingside attack, whatever the opponent plays." The engine reacts flexible on every change on the board and tries to optimise all evaluations in parallel. If it found a weakness of the opponent then that can easily be attacked and that determines the course of the game.

During the search the typical helper arrays like piece square tables, transposition table, history move table, refutation table and killer moves are available to guide through the game on a short time local path. It also helps to have midgame and endgame evaluations and a smooth transition between them.

I am sure the chessprogramming wiki has a lot of evaluation information. You should probably start with some typical basic terms from these points:

- pawn structure (passers, connected passers, distant passers, square rule, isolated pawns, double pawns, pawn chains, weak pawns, rams, blocked center, pawn storms)
- king safety (castling, pawn shield, direct and hidden sliding attackers)
- mobility (count attacked squares where they are, with which piece, defending own pieces, attacking which opponent pieces or weak pawns, trapped pieces)
- special piece terms (bishop pair, rooks on half/open files, rooks behind passers, rooks on/near opponent king's file, rooks on 7th/8th rank, queen near opponents king, knights not in the corners, knight or bishop ouposts, kings in opposition)

Sometimes some evaluations parts can collect informations which modify the weights of other evaluations:
http://www.fraserheightschess.com/Docum ... _Types.pdf

And if you want more this is an disputed but interesting source of evaluation ideas:
http://www.winboardengines.de/doc/Littl ... endium.pdf

Hi Harald

I know that and now implementing masks to determine double, passed, isolated pawns,
This would be obvious along with mobility, king safety, etc.

I just want to add the feature described to "lead" engine through the forest of positions.

[maksimKorzh]

Well I guess that the search scoring a position like 20 ply deeper is somehow already a "plan" no ?

One of the best way to "orient" the search (or at least not let it prune) in the "good" direction is to tune the attack and king safety part of the evaluation (this will especially works against weaker opponents).
Pawn structure and ability to predict pawn evaluation for end-game may remain what makes a win against an equal opponent.

At least that's the way I get it ...

Well I guess that the search scoring a position like 20 ply deeper is somehow already a "plan" no ?

This is so if evaluation is decent.
With only piece square tables and material even twice deeper search compared to opponents capabilities might be a bad plan leading to getting mated.
So it only works with GOOD evaluation.

I don't say that my idea is alternative, it's an addition.
You won't be arguing that opening books is a good thing right?
Now what I propose is a some sort of "flexible opening book" that takes care only of the key positions, so the engine is "jumping" from one key position to another until a certain type of middle game position is reached.

[towforce]

A player might think, "I play well in position type X, and my opponent tends to be weak in that type of position, so I'll play for that type of position."

I you want a computer to play for position type X, then I would think that the obvious thing to do would be to change the evaluation function to prefer that type of position. Include a method in the EF to assess how much like position type X the position being evaluated is.

[Terje]

This is the same as using a book, but instead of opening positions it has middle game positions. Not allowed in competitions nor rating lists I imagine.

[mvanthoor]

Hi guys

HOW CAN WE GIVE THE ENGINE AN IDEA OF THE "PATH" TO FOLLOW IN ORDER TO START GETTING CERTAIN TYPE OF POSITIONS IN THE MIDDLEGAME?

... snip ...

What you are trying to achieve is to give the engine some sort of strategic insight.

There have been experiments with regard to creating 'progression' within the evaluation function. In your position, the center is locked with black having an advanced pawn on d4. There's an e5-d4 chain (could be f6-e5-d4 at some point). The strategy is to attack the base pawn in the chain using your own pawn. To achieve this, you'd need to move Nf3, and then play f2-f4.

Because your pawns on the kingside are already advanced, this creates the possibility for a pawn storm, if you make that attack at the right moment.

So, you would need to:
- detect the pawn chain
- determine the pawn furthest away from you
- determine which pawn you'd need to move to attack this base pawn
- determine if you need to move any pieces
- then actually advance the attacking pawn

You need to detect the situation, set up your goal, and then keep a progression.

It is possible, it has been done and tried, but in the end, it costs too much computing power. Currently, it looks like the neural network engines are the ones making these long range plans, where the a/b-engines are extremely tactical in comparison.

[maksimKorzh]

This is the same as using a book, but instead of opening positions it has middle game positions. Not allowed in competitions nor rating lists I imagine.

Then HOW it would get detected?
Positions would get scored just as regular positions but without walking through static evaluation, just like as it was extracted from TT.

[maksimKorzh]

A player might think, "I play well in position type X, and my opponent tends to be weak in that type of position, so I'll play for that type of position."

I you want a computer to play for position type X, then I would think that the obvious thing to do would be to change the evaluation function to prefer that type of position. Include a method in the EF to assess how much like position type X the position being evaluated is.

That was the first thing I tried but within EF it affects the overall eval so eventually the position would over evaluated, while if match it within search it gives a "normal score", e.g. for position representing Ruy Lopez let's say we have a hash key "0x432343453" so in case of match it would return the score of -30 assuming that bishop is on b5 and it's black turn to move, while without this Ruy Lopez would score -20 with the same position if walk through static eval.