what is the basis for the current values of SF's {MidgameLimit = 15258, EndgameLimit = 3915}, and what do they represent exactly?
for example the last time they were changed was when the linear imbalance was removed even though the MG values of the pieces changed later.
SF' MidgameLimit & EndgameLimit ?
Moderators: hgm, Rebel, chrisw
-
Eelco de Groot
- Posts: 4561
- Joined: Sun Mar 12, 2006 2:40 am
- Full name:
Re: SF' MidgameLimit & EndgameLimit ?
It is best to look this up in the code itself. I'm not sure about the details but roughly, Stockfish varies its evaluation factors between a weight for the endgame and a weight for the midgame. How much of each is determined by the game phase. Between midgamelimit and endgamelimit there is a linear dependancy determined by types and numbers of pieces (I'm not sure if t the moment it involves also pawns, it used to be not but at some point that might have changed or changed back) If the number used goes under the midgamelimit or over the endgame limit, this does not change the game phase anymore. Only the endgame terms count above endgame limit or only the midgame term counts below midgame limit. If the values for pieces in endgame or midgame are retuned, in principle the endgame limit and midgame limit should change as well if you want exactly the same distribution of piece types to fall between the two limits.
If as you say that was not always done, I don't know why not. If the values were automatically retuned, the limits maybe were not changed because that would throw off the result from the tuning. Or if the values change only a little and the same distribution falls between limits, you don't have to change the limits, also if you don't care if now some combinations fall on the other side of the limit.
If as you say that was not always done, I don't know why not. If the values were automatically retuned, the limits maybe were not changed because that would throw off the result from the tuning. Or if the values change only a little and the same distribution falls between limits, you don't have to change the limits, also if you don't care if now some combinations fall on the other side of the limit.
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan
-
Hanamuke
- Posts: 3
- Joined: Fri Dec 07, 2018 2:47 pm
- Full name: Antoine Houdayer
Re: SF' MidgameLimit & EndgameLimit ?
To complement the answer, there is no real reason to change, or not to change the limits. We simply test patches, that are accepted if they bring Elo. If a patch that doesn't change the limit is accepted, it means it works well with the current limits. If a patch that changes the limits is accepted, it means it is good to change them. There is not much more to it. As a general rule however, it is easier to write a patch that works with the current limits, than to change them. Changing the limits affects basically every part of the evaluation, so it's likely to not work in a well tuned engine.
Also, the piece values that are used in the computation of the game phase are the values from the PieceValue array, which are deconnected from the values used to evaluate the position (the psqt values). Therefore, even if you tune the evaluation (the psqt) the same material will still map to the same game phase as before.
Also, the piece values that are used in the computation of the game phase are the values from the PieceValue array, which are deconnected from the values used to evaluate the position (the psqt values). Therefore, even if you tune the evaluation (the psqt) the same material will still map to the same game phase as before.