Page 1 of 3
Most common/top evaluation features?
Posted: Fri Apr 10, 2015 6:56 pm
by 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.
Re: Most common/top evaluation features?
Posted: Fri Apr 10, 2015 7:30 pm
by michiguel
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
Re: Most common/top evaluation features?
Posted: Fri Apr 10, 2015 7:46 pm
by 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.
Re: Most common/top evaluation features?
Posted: Fri Apr 10, 2015 8:24 pm
by Fabio Gobbato
- King safety
- Passed pawns
- Mobility
- PST
The strength of an engine is mainly made by this 4 terms.
Re: Most common/top evaluation features?
Posted: Sat Apr 11, 2015 2:29 am
by lucasart
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.
Re: Most common/top evaluation features?
Posted: Sat Apr 11, 2015 4:02 am
by Ferdy
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
Re: Most common/top evaluation features?
Posted: Sat Apr 11, 2015 10:37 am
by 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
How to measure mobility?
Posted: Sat Apr 11, 2015 5:08 pm
by 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?
Re: How to measure mobility?
Posted: Sat Apr 11, 2015 5:22 pm
by Henk
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.
Re: How to measure mobility?
Posted: Sat Apr 11, 2015 7:21 pm
by cdani
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.