zamar wrote:lech wrote:Prominent programmers are like the Egyptian priests.
It is very difficult to change anything in Stockfish evoluation.
SF's evaluation is very standard and based on publicly available ideas.
It took >30 years of time and many brilliant people to find the correct ideas. Sure it's difficult to improve!
But if you want to try I'd suggest to concentrate on the king safety and passed pawns, they are the least standardized evaluation features of the chess engines (in general).
Also SF lacks a lot of endgame knowledge. We'd need to find the correct scaling factor for many different end game types and situation. But implementing this requires a lot of time and skill which very few people have. It's easy to make a 5 line change, but when one needs to design and implement something new (and make it correctly & without bugs) it's where most people fail.
A lot of values is tuned and they should probably be retuned after each change.
In my experience: Good idea is +10 elo. Fine tuning it is +5 elo. So if you find a good idea, it should work also without tuning. Tuning can only give a little extra push.
It dosn't mean that this evoluation works well.
Good! Please point out something better.
I was just thinking about a rather simple idea, that is along Sting goals too and could very probably be used there, if it can be tuned. Right now in margins() we (Stockfish) only store a bad King Safety situation with the idea that, only if you have the move, you could improve your situation because you have the right to move right now, capturing one of the pieces that threaten your king can improve your king safety, even if the material value would get worse. We ignore any possible improvement for instance to the other side, if we are actually the King attacker that can take out any of the defending pieces, and more in general any possible positional value that could either improve, get better so there is compensation for any sacrificed/lost material, or alternatively get worse so the hoped for compensarion eventually evaporates to the better material possessed by the other side. Then there is the error in the evaluation itself which also will have some statistical properties, if it is noise like error it will also probably have some bell shaped distribution around a more perfect, and imaginary errorfree eval.
I think this simple idea could be condensed to no more than a one line change, in evaluate.cpp, just for example we could be changing at the end of this fragment, line 446-453:
Code: Select all
else
// Endgame with opposite-colored bishops, but also other pieces. Still
// a bit drawish, but not as drawish as with only the two bishops.
sf = ScaleFactor(50);
}
margin = margins[pos.side_to_move()];
Value v = interpolate(score, ei.mi->game_phase(), sf);
Adding one line:
Code: Select all
else
// Endgame with opposite-colored bishops, but also other pieces. Still
// a bit drawish, but not as drawish as with only the two bishops.
sf = ScaleFactor(50);
}
// Interpolate between the middle game and the endgame score
margins[pos.side_to_move()] += scale_by_game_phase(std::max(score - ei.mi->material_value(), ei.mi->material_value() - score)/(32), ei.mi->game_phase(), sf);
margin = margins[pos.side_to_move()];
Value v = scale_by_game_phase(score, ei.mi->game_phase(), sf);
The division here by 32 is arbitrarily chosen, it should be tuned. Maybe it should be some expression but in that case there is the danger that you run into "division by zero" errors very quickly, and Stockfish will crash with an 0xc0000094 error code. The error margin should be a positive number to work as an futility margin for the side to move, especially if the idea is that, without Zugzwang, the side to move should be able to improve his position (goal is to judge if we can reach a beta cutoff, eval > alpha = beta - 1 in an alpha-beta framework. We also ignore the fact for the moment that advantages on your side do not simply evaporate if you just don't happen to have the move right now). Thinking along statistical lines there should probably some sort of second order term just like the Standard deviation is some average error squared, but I have not bothered about that yet.
Okay it is just some idea but as it is a one line change to the Stockfish code and can be tuned in many ways, by dividing by some simple number the impact on search extensions can be made as small as you wish, I think this was the most worthwhile eval idea I had today
Regards, Eelco
Not that I don't think you guys are right; that this is difficult to test and in particular there is no way to see if any elements are actually making things worse if you don't test all of it separately. But there is an idea to it all that I try to get across, sometimes there are features in a chess position that you can't do so much about. They may have happened "by accident" or your opponent got them with a superior search or superior knowledge implemented. Of for instance they came with the opening. And maybe when you detect it, it is already too late. Now you can include all the knowledge you know in your evaluation function, but here you actually have the chance to do something about some of the elements! The piece is attacked and there is no defending pawn. The piece does not actually have to hang but you do know for sure you can attack it and you even know with what piece you do this. Maybe then it pays off, to see how good your target really is. A parallel with king safety: you start evaluating that fully only if you have more than one attacker in place. 
I am maintaining the copyright to my codechanges