Most Important Evaluation Terms

[adityachandra]

Hi all, I was just wondering what evaluation terms would be the most beneficial to an engine. Currently I have just piece square tables for the middlegame and endgame that are tapered, and some attack and defend maps lying around, which are updated in the make/take move function. I want to use these maps somehow, so what is the general consensus on what chess knowledge an engine "needs" to have other than PSTs?

[hgm]

Important are king safety (pawn shield, attcks on the King neighborhood) and pawn structure (passers, isolated pawns, backward pawns). Also helpful is recognition of drawishness in end-games where the strong side has 0 or 1 pawn. (KBKPP, KBPKN, KRKN.) Bishop pair bonus is also worth something.

[elpapa]

Mobility is important as well.

[KhepriChess]

Pawn eval terms I've gotten pretty good gains off of, particularly when combined with a pawn hash table. Knight outposts are a relatively easy thing to implement and usually get some strength from that.

King safety I've had a lot of trouble with and so far have never been able to get a benefit from. Mobility took me a long time, but eventually I was able to get something work. For me, both of those were troublesome because they use piece attacks and sliding piece attacks for my engine are (comparatively) painfully slow to generate.

[adityachandra]

I suppose knight outposts are already somewhat encoded in a piece square table. I think I'll include safe mobility (not just mobility thanks to the attack tables, and this will be fast because of them) with different weights for vertical mobility for the rooks, and depending on the piece. And attacks around the king zone, which will again be relatively easy with those tables, while maintaining the pawn shield if the king has castled. And of-course pawn structure. I suppose this is a good set of features to tune?

[JoAnnP38]

I suppose knight outposts are already somewhat encoded in a piece square table. I think I'll include safe mobility (not just mobility thanks to the attack tables, and this will be fast because of them) with different weights for vertical mobility for the rooks, and depending on the piece. And attacks around the king zone, which will again be relatively easy with those tables, while maintaining the pawn shield if the king has castled. And of-course pawn structure. I suppose this is a good set of features to tune?

You can't really encode bonuses for Knight/Bishop outposts in the PST. While you could give a bonus for a minor piece being on the opponent's side of the board, it has to be defended by a friendly pawn before it is considered an outpost. At least that's that way I've heard it described. Also, you should consider giving different weights to different piece types wrt mobility. A queen can achieve large amounts of mobility, but you don't want that to encourage the queen to come out too early in the during the opening phase which your engine will do unless the mobility weight for the queen is much lower during the opening. Also, you should really give some thought to giving a bonus to having both bishops (i.e. the bishop-pair bonus). It's really a lightweight bonus since you already know how many bishops each side has, so it definitely earns its place since it is so cheap to determine.

[adityachandra]

Looking into outposts, I now see what you mean, as the require information on what pawns attack that piece or defend. Initially I just thought they were bonuses on just where the knight was placed.

[chrisw]

Hi all, I was just wondering what evaluation terms would be the most beneficial to an engine. Currently I have just piece square tables for the middlegame and endgame that are tapered, and some attack and defend maps lying around, which are updated in the make/take move function. I want to use these maps somehow, so what is the general consensus on what chess knowledge an engine "needs" to have other than PSTs?

Absolutely mobility. It needs to be relatively sophisticated. Only count moves to safe squares. Eval is not linear to move count, use a different weight for each count (for each piece type).

Then king safety, as they call it. Better to think of it as king attack, imo, get yourself into the right mindset.

[adityachandra]

Hi all, I was just wondering what evaluation terms would be the most beneficial to an engine. Currently I have just piece square tables for the middlegame and endgame that are tapered, and some attack and defend maps lying around, which are updated in the make/take move function. I want to use these maps somehow, so what is the general consensus on what chess knowledge an engine "needs" to have other than PSTs?

Absolutely mobility. It needs to be relatively sophisticated. Only count moves to safe squares. Eval is not linear to move count, use a different weight for each count (for each piece type).

Then king safety, as they call it. Better to think of it as king attack, imo, get yourself into the right mindset.

Yes, I was planning to do safe squares. But I was just thinking to multiply that by a fixed value. I'll try including a specific value for each mobility number.

[chrisw]

Hi all, I was just wondering what evaluation terms would be the most beneficial to an engine. Currently I have just piece square tables for the middlegame and endgame that are tapered, and some attack and defend maps lying around, which are updated in the make/take move function. I want to use these maps somehow, so what is the general consensus on what chess knowledge an engine "needs" to have other than PSTs?

Absolutely mobility. It needs to be relatively sophisticated. Only count moves to safe squares. Eval is not linear to move count, use a different weight for each count (for each piece type).

Then king safety, as they call it. Better to think of it as king attack, imo, get yourself into the right mindset.

Yes, I was planning to do safe squares. But I was just thinking to multiply that by a fixed value. I'll try including a specific value for each mobility number.

If you Texel tune them, you'll find all kind of obvious but unexpected things. Like B or Q-mobility actually gets worse at very high mobilities. Because? You're mostly or entirely hitting empty space.