Evaluation values help

[lauriet]

Hey all,

So far, I have just guessed the values for my eval function, or tried to see what others have done.
Here is my values in cp.
I don't change them for game stage yet.
(I also use PST and mobility)

RookOnOpenFileReward = 10; {-- gets added twice if two rooks are on the file }
OutPostReward = 10; {-- knight or bishop on outpost }
PassedPawnReward = 20;
KingSafetyReward = 10; {-- get incremented for every safe feature }
RookOn7thReward = 20; {-- rook on seventh rank }

EarlyQueenMovePenalty = 15;
DoublePawnPenalty = 10;
IsolatedPawnPenalty = 20;
BackWardPawnPenalty = 10;
NotCastledPenalty = 10;
OneRookPenalty = 15;
OneBishopPenalty = 20;
NotDevelopedPenalty = 10;

Are there reasonable agreed values
Is, say a rook on an open file worth 1/4 pawn (all things being equal)

I would have thought it would be engine independent since the position is the position...and its either best or not so good.
I don't have the facilities to tune these.... unless Bob volunteers

Can anyone suggest better values, since I can't play 1000 games and then change one and play another 1000 etc, etc.

Thanks
Laurie.

[Dann Corbit]

{snip}
Can anyone suggest better values, since I can't play 1000 games and then change one and play another 1000 etc, etc.

Thanks
Laurie.

That is how everyone does it in order to get the right values for their framework.

Consider (for instance) that the Stockfish pawn is not 100 centipawns:

types.h ( 187): PawnValueMg = 198, PawnValueEg = 258,

Hence, you cannot simply use these values from another program. Even if they chose pawn values the same as yours, the only right way to do it is to run thousands of games. {On the other hand, someone else's program could be used to get some starting values or to scale your features so that they are approximately of the same scale}

But take heart, people without a million dollars worth of hardware just play 1000 super fast games.

There are 86,400 seconds in a day, so that is one game per 86.4 seconds if you have one machine to get 1000 games.

It would therefore take one week to tune 7 parameters {at 1000 games per feature}.

[kbhearn]

The most important terms you'll get a good deal of the benefit just for giving them some value at all as then the search will start to pay attention to trying to achieve/prevent them to some extent.

i.e. having some knowledge that passed pawns are good, and better if they're further advanced is already half the battle. properly weighting the value of an advanced passer vs sacrificed material or other competing positional terms is a far more advanced topic and one you may revisit multiple times over the course of your engine. once you get around to tuning which parameters you have, how they overlap, and which ones you tune first will have a great deal of influence over the correct values of the remaining ones. and as you add new parameters, you'll have to retune old ones again and again.

[PK]

reasonable set of values can be seen here: http://members.aon.at/josefd/Toga%20LOG.html

it uses a bit high piece/square table values and a bit high mobility, but works decently.

Personally, I would avoid adding terms depending on the sequence of moves (it seems that "not castled penalty" falls into that cathegory - it can be replaced by detecting when a king blocks own rook).

there is also very useful article by Larry Kaufman: http://www.danheisman.com/evaluation-of ... ances.html. It considers having two rooks or two knights a liability, not an asset. The situations when it is important are RR vs R+minor < R vs minor and BN vs NN > B vs N.

[AlvaroBegue]

There is an alternative that should be mentioned: Create a database of [quiescent] positions with an assigned result and use logistic regression to set the values of the evaluation terms. As long as your evaluation is a linear combination of features, this will work. If your evaluation is non-linear, you can still use something like gradient descent to tune it.

You have to be careful to not introduce biases when you generate your database. Picking positions from real games is not good enough, at least for two reasons:
(1) because you won't see enough positions with overwhelming advantage for one side (which are the majority of things your evaluation function will be judging), and
(2) because you will only see certain weak patterns when there was a reason for a player to accept them, but your program will then go into them thinking they are always good (see Turing's warning regarding mobility here: https://chessprogramming.wikispaces.com ... n%20Turing).

A better way to generate the database is to make reasonable moves followed by a completely random move, or to sample positions from actual calls to the evaluation function of a running engine. You then have to somehow assign a result to those positions, for instance by running a bullet game using Stockfish.

If I had time to devote to computer chess, this is what I would be trying to do.

[bob]

Hey all,

So far, I have just guessed the values for my eval function, or tried to see what others have done.
Here is my values in cp.
I don't change them for game stage yet.
(I also use PST and mobility)

RookOnOpenFileReward = 10; {-- gets added twice if two rooks are on the file }
OutPostReward = 10; {-- knight or bishop on outpost }
PassedPawnReward = 20;
KingSafetyReward = 10; {-- get incremented for every safe feature }
RookOn7thReward = 20; {-- rook on seventh rank }

EarlyQueenMovePenalty = 15;
DoublePawnPenalty = 10;
IsolatedPawnPenalty = 20;
BackWardPawnPenalty = 10;
NotCastledPenalty = 10;
OneRookPenalty = 15;
OneBishopPenalty = 20;
NotDevelopedPenalty = 10;

Are there reasonable agreed values
Is, say a rook on an open file worth 1/4 pawn (all things being equal)

I would have thought it would be engine independent since the position is the position...and its either best or not so good.
I don't have the facilities to tune these.... unless Bob volunteers

Can anyone suggest better values, since I can't play 1000 games and then change one and play another 1000 etc, etc.

Thanks
Laurie.

It is MUCH more complex than you suspect. Just take the rook on an open file bonus. If there is just ONE open file, the bonus should be very large as that is potentially a game-winning advantage. If there are multiple open files, the advantage is much less valuable. And then there is the issue of which file. A rook on an open file hitting on the king is very valuable, while on the opposite side of the board it is not so valuable.

For passed pawns, it is even worse. The rank is important, the file is important, the state of squares in front of the pawn is important, etc...

[lauriet]

This brings us back to Search verses Evaluation doesn't it ?
Remember Slate/Atkin (chess 4.X) talked about how search effectively improved your evaluation function. So is it more productive to live with a simple eval function and focus on searching deeper ?

Regards
Laurie.

[cdani]

So is it more productive to live with a simple eval function and focus on searching deeper ?

This seems to be more a matter of preference than anything else, as seems that any reasonably working engine can be improved continuously. There are some evaluation minimums that seem to be mandatory, though, but this is probably biased to the general previous experience.

Anyway any good engine must be good in the evaluation function and in the search, not that one can focus only on one of them.

Chess seems to be biased to tactics, so search is probably more important. But not a few features cannot be recognized through search, what requires a good evaluation.

[bob]

This brings us back to Search verses Evaluation doesn't it ?
Remember Slate/Atkin (chess 4.X) talked about how search effectively improved your evaluation function. So is it more productive to live with a simple eval function and focus on searching deeper ?

Regards
Laurie.

That was 1975.

[lauriet]

Hey Bob,

>>>that was 1975.

What a great opportunity this presents for a new academic paper.

Search verses Evaluation in the 21st century.
By Bob Hyatt and Laurie Tunnicliffe

What I propose is:

Crafty A is the normal version. Crafty B gets the evaluation function stripped out and replaced with a minimal
PST based eval.

Now... how many extra ply does Crafty B need to draw equal with Crafty A ?

If you want to "go to town" you could equate adding evaluation features in terms of reducing needed ply.

If you can arrange my accommodation for 6 months, Ill pay my airfare from Australia.

Im ownly half joking. Is there any recent investigation of this ?

Regards
Laurie.