writing an evaluation function

[Pierre Bokma]

Hi,

Working on my evaluationfunction has been disppointing till now. I have included all the usual term (mobility, king saftey pawn structure etc.). The function started as a exact implementation of chess 4.5 but this played horrible weak. Since is added a lot of code that greatly improved play. My engine now beat tscp easily. Any tips on further improvement appriciated.

Fur further improvement some help would be usual. I started wondering if some one can say something about good relative weigths of the different parts of evaluation.

Also a list of a number of positions and there evaluation calculated by a strong program like crafty or stockfish would be nice. Does any one know of the excistence of such a list?

thanks in advance

Pierre

[Evert]

Working on my evaluationfunction has been disppointing till now. I have included all the usual term (mobility, king saftey pawn structure etc.). The function started as a exact implementation of chess 4.5 but this played horrible weak. Since is added a lot of code that greatly improved play. My engine now beat tscp easily. Any tips on further improvement appriciated.

Fur further improvement some help would be usual. I started wondering if some one can say something about good relative weigths of the different parts of evaluation.

Also a list of a number of positions and there evaluation calculated by a strong program like crafty or stockfish would be nice. Does any one know of the excistence of such a list?

It's not generally very useful to compare numerical values of evaluations between different engines, at least quantitatively.
That said, I sometimes do look at open-source engine evaluation term weights to get a rough idea. I then tune the value for my own program.

As for improving the evaluation function further, what worked for me (at least early on) was to look at the games and see whether there was a consistent blind-spot in the evaluation and then plugging the hole. This becomes more difficult as patterns become less obvious. One thing that is important: test against opponents that are roughly the same strength as your engine, preferably against several. That will help you identify trouble spots. The strategic test suite (STS) is also very useful.

[Rebel]

Wellicht helpt dit een beetje.

http://www.top-5000.nl/authors/rebel/chess840.htm#INTRO

Succes.

[Pierre Bokma]

Dank je Ed. Het meeste van deze factoren heb ik al toegevoegd aan mijn evaluatie maar daarnaast is er nog veel werk te doen. Dat neemt niet weg dat het fantastische informatie is.

[Rein Halbersma]

Dank je Ed. Het meeste van deze factoren heb ik al toegevoegd aan mijn evaluatie maar daarnaast is er nog veel werk te doen. Dat neemt niet weg dat het fantastische informatie is.

En anglais, s'il vous plait

[PK]

Personally, I find designing an evaluation function for a program to be the most rewarding part.

A couple of unscientific hints:

* scaling between midgame and endgame scores (based on remaining piece material) is one of the greatest legacies of Fruit. You harm Your program if You use anything like a sharp boundary between middlegame and endgame. And if You scale, it is a good idea to scale just about everything.

* Try as many of big implementation schemes as You can at an early stage (i.e. king safety scaled against the number of attacking pieces vs Stockfish-like attack table; symmetric or asymmetric eval; linear or non-linear mobility)

* implement basic low material draws at an early stage; without that functionality the strength difference is somewhat reduced when an engine goes for a "winning" KB vs K.

* good material evaluation is more important than most programmers think; witness what Larry Kaufmann says about recent Komodo; but material values should be tuned early; after all an engine that likes to sacrifice an exchange might require different tuning of remaining parameters.

* the best hint form Ed Schroder's page is: when You create a new parameter, i. e. a penalty for a weak pawn, use a table (with a value for each square) rather than a single value.

* king safety is heart and soul of an engine.

* If You have a reasonably developed engine, a lot can be gained from testing. Mot of evaluation changes can be tested at very fast time controls (by "very fast" I mean anything that allows Your engine to search about 6 plies). However, You might need a bit longer games for testing king safety.

[ZirconiumX]

<S'pht translator active>

Maybe this helps a bit.

http://www.top-5000.nl/authors/rebel/chess840.htm#INTRO

Success.

Thank you Ed. Most of this I have already added to my program but there is still lots of work to do. Nevertheless this is great information.

In english, please.

Matthew:out