Most common/top evaluation features?

[brtzsnr]

What are the most common/top evaluation features? I'm mainly interested in features that are useful in many situations, not very specific.

Examples of good features:
- Piece square tables
- Tapered eval
- Double pawns
- Mobility

Examples of bad features
- KvsKR knowledge (too specific)
- Unstoppable pawn (too specific, hard to get right)

I can rephrase: if you were to rewrite your evaluation function in which order would you add features to it?

This question is only about evaluation, not searching. Null move pruning, check extension do not qualify.

[michiguel]

What are the most common/top evaluation features? I'm mainly interested in features that are useful in many situations, not very specific.

Examples of good features:
- Piece square tables
- Tapered eval
- Double pawns
- Mobility

Examples of bad features
- KvsKR knowledge (too specific)
- Unstoppable pawn (too specific, hard to get right)

I can rephrase: if you were to rewrite your evaluation function in which order would you add features to it?

This question is only about evaluation, not searching. Null move pruning, check extension do not qualify.

1) mobility
2) passed pawns
3) King placement

Those are huge, and 2 and 3 should be tapered and well tuned.

PST are not that big. You can have a strong engine without them. But I would add them for N and P.

Miguel

[voyagerOne]

Well the very most important Eval term in chess is Piece Value.
You don't want to value your queen as 100 and pawns as 1000.
I assume that is a given.

Second would be King Safety. As this is the whole objective of chess...to mate the opponent's King.

[Fabio Gobbato]

- King safety
- Passed pawns
- Mobility
- PST

The strength of an engine is mainly made by this 4 terms.

[lucasart]

What are the most common/top evaluation features? I'm mainly interested in features that are useful in many situations, not very specific.

Examples of good features:
- Piece square tables
- Tapered eval
- Double pawns
- Mobility

Examples of bad features
- KvsKR knowledge (too specific)
- Unstoppable pawn (too specific, hard to get right)

I can rephrase: if you were to rewrite your evaluation function in which order would you add features to it?

This question is only about evaluation, not searching. Null move pruning, check extension do not qualify.

Remove doubled pawns from your list of good features. This one is practically useless, and quite specific. Otherwise, I agree, start with
0/ Tapered eval
1/ PST
2/ Mobility

You can gain hundreds and hundreds of elo, by fixing bugs, improving search, and fine tuning the above PST+ mobility alone. Don't start anything else, before you reach 2200 elo at least.

[Ferdy]

What are the most common/top evaluation features? I'm mainly interested in features that are useful in many situations, not very specific.
Examples of good features:
- Piece square tables
- Tapered eval
- Double pawns
- Mobility

Examples of bad features
- KvsKR knowledge (too specific)
- Unstoppable pawn (too specific, hard to get right)

In addition to what others have already said.

Code: Select all

1. Pawn structure
   a. backward pawn
   b. isolated doubled pawn

2. Rook in open files

3. Rook in 7th ranks

4. Two bishop advantage (2 different colors)

5. Piece outpost
   a. knight
   b. bishop

6. Threats
   a. attack on opp pieces
   b. attack on empty squares that are important such as central and
   squares near the kings

7. Able to win in winnable KP v K, and won KQ v K and KR v K, endings

[PK]

1. piece/square tables, interpolated between midgame and endgame (as Your engine matures, You are going to add interpolation anyway, so better start with it right away - it's easier to keep the code clean later on). As a sanity check, beat TSCP with just that.

2. passed pawns. at this stage decent search should beat micro-Max

3. mobility. here Sungorus should be beaten by 100 Elo or so

4. basic drawn material configurations: KK, KBK, KNK, KNNK are straight draws, KRKB, KRKN, KRBKR, KRNKR, KQBKQ, KQNKQ, KBNKB, KBNKN, KBBKB (note the omission of KBBKN!) K(2minors)KR are sccaled down (for starters, divide the score by 2). This is needed not for playing strength, but for better testing. In early days of Rodent I have seen so many endings of that kind evaluated as 3+ that I came to believe they may distort the match score)

5. weak pawns (pawns that cannot be defended no matter what pawn moves you make). dividing them into isolated and backward will come later.

6. bishop pair bonus and doubled pawns penalty applied together. the main reason doubled pawns are useful is that they prevent playing for bishop pair at all cost.

7. king safety. You are at least 2500 now.

8. pawns shielding own king.

This is the point when all the basic elements are in place. It's the time to look what mistakes Your engine tends to make, fix them with some special case code (like a penalty for a rook blocked by uncastled king, for blocked d2/e2 pawn and whatever ugly things tend to happen). With some tuning, You are within 100 Elo to Fruit 2.1

[BeyondCritics]

In responses to the question, nearly every programmer had "mobility" on top of its list. It must be an important concept.
However looking up sources (https://chessprogramming.wikispaces.com/Mobility) it is not altogether clear, how to measure "mobility" correctly.

So for starters: How would you recommened to implement the concept of mobility? Any pitfalls?

[Henk]

In responses to the question, nearly every programmer had "mobility" on top of its list. It must be an important concept.
However looking up sources (https://chessprogramming.wikispaces.com/Mobility) it is not altogether clear, how to measure "mobility" correctly.

So for starters: How would you recommened to implement the concept of mobility? Any pitfalls?

Yes mobility never worked for me perhaps because computing mobility was too expensive and I already have a surrogate mobility in my PSQ.

[cdani]

In responses to the question, nearly every programmer had "mobility" on top of its list. It must be an important concept.
However looking up sources (https://chessprogramming.wikispaces.com/Mobility) it is not altogether clear, how to measure "mobility" correctly.

So for starters: How would you recommened to implement the concept of mobility? Any pitfalls?

Counting the number of squares attacked by the piece, and looking at some array with that number is the common way. Is also commont to discount the squares attacked by the oponnent pawns or where there is an own piece. It tends to be effective because the engines has available the attacks of each piece.