Most common/top evaluation features?

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
brtzsnr
Posts: 433
Joined: Fri Jan 16, 2015 3:02 pm
Contact:

Most common/top evaluation features?

Post by brtzsnr » Fri Apr 10, 2015 4:56 pm

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.

User avatar
michiguel
Posts: 6388
Joined: Thu Mar 09, 2006 7:30 pm
Location: Chicago, Illinois, USA
Contact:

Re: Most common/top evaluation features?

Post by michiguel » Fri Apr 10, 2015 5:30 pm

brtzsnr wrote: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
Posts: 154
Joined: Tue May 17, 2011 6:12 pm

Re: Most common/top evaluation features?

Post by voyagerOne » Fri Apr 10, 2015 5:46 pm

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.

User avatar
Fabio Gobbato
Posts: 125
Joined: Fri Apr 11, 2014 8:45 am
Contact:

Re: Most common/top evaluation features?

Post by Fabio Gobbato » Fri Apr 10, 2015 6:24 pm

- King safety
- Passed pawns
- Mobility
- PST

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

User avatar
lucasart
Posts: 3040
Joined: Mon May 31, 2010 11:29 am
Full name: lucasart
Contact:

Re: Most common/top evaluation features?

Post by lucasart » Sat Apr 11, 2015 12:29 am

brtzsnr wrote: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.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.

Ferdy
Posts: 4111
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: Most common/top evaluation features?

Post by Ferdy » Sat Apr 11, 2015 2:02 am

brtzsnr wrote: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
Posts: 824
Joined: Mon Jan 15, 2007 10:23 am
Location: Warsza
Contact:

Re: Most common/top evaluation features?

Post by PK » Sat Apr 11, 2015 8:37 am

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
Posts: 346
Joined: Sat May 05, 2012 12:48 pm
Location: Bergheim

How to measure mobility?

Post by BeyondCritics » Sat Apr 11, 2015 3:08 pm

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
Posts: 5819
Joined: Mon May 27, 2013 8:31 am

Re: How to measure mobility?

Post by Henk » Sat Apr 11, 2015 3:22 pm

BeyondCritics wrote: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.

User avatar
cdani
Posts: 2104
Joined: Sat Jan 18, 2014 9:24 am
Location: Andorra
Contact:

Re: How to measure mobility?

Post by cdani » Sat Apr 11, 2015 5:21 pm

BeyondCritics wrote: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.

Post Reply