Don wrote:{snipped}
Komodo, as well as other programs and probably Houdini too have different values for different game stages.
In Komodo we "center" everything so that the values are actually meaningful to us without too much interpretation. For example our bishop mobility is negative if the bishop is not very mobile and is close to zero when it has "average" mobility. Of course what is average is a judgement call but we try to make that judgement. So for mobility we have defined N squares of mobility to be the centering point - and that is different for each piece. Our piece square tables all have negative and positive entries also in order to capture this same concept. Whenever we implement a new evaluation concept we don't want to have to "lower" or "raise" the value of something else to compensate so we take care to "center" anything that has anything more than a trivial consequence on the evaluation function.
Our values for the opening are:
600, 3100, 3225, 4350, 9100
ending:
925, 3100, 3225, 5475, 9700
We also have other modifiers which have the effect of changing these such as the bishop pair, rook pair, "major piece pair involving queen" and a bunch of other stuff which also considers the effect of the pawns.
I doubt these values will work for just any program but I present them for what they are worth.
{snipped}
Thanks, interesting.
So 1/3100 Knight units instead of millipawns
Still, I found ~60 centies for a pawn in the opening surprisingly small, assuming piece square values are centered around zero, and weak pawns like backward and isolated may receive a additional penalty. How much becomes a strong white pawn say on e4 in the opening?
Don wrote:{snipped}
Komodo, as well as other programs and probably Houdini too have different values for different game stages.
In Komodo we "center" everything so that the values are actually meaningful to us without too much interpretation. For example our bishop mobility is negative if the bishop is not very mobile and is close to zero when it has "average" mobility. Of course what is average is a judgement call but we try to make that judgement. So for mobility we have defined N squares of mobility to be the centering point - and that is different for each piece. Our piece square tables all have negative and positive entries also in order to capture this same concept. Whenever we implement a new evaluation concept we don't want to have to "lower" or "raise" the value of something else to compensate so we take care to "center" anything that has anything more than a trivial consequence on the evaluation function.
Our values for the opening are:
600, 3100, 3225, 4350, 9100
ending:
925, 3100, 3225, 5475, 9700
We also have other modifiers which have the effect of changing these such as the bishop pair, rook pair, "major piece pair involving queen" and a bunch of other stuff which also considers the effect of the pawns.
I doubt these values will work for just any program but I present them for what they are worth.
{snipped}
Thanks, interesting.
So 1/3100 Knight units instead of millipawns
Still, I found ~60 centies for a pawn in the opening surprisingly small, assuming piece square values are centered around zero, and weak pawns like backward and isolated may receive a additional penalty. How much becomes a strong white pawn say on e4 in the opening?
The pawn value evolved over time - it was once below 1000 for the opening and above 1000 for the ending. To make major changes to the pawn value requires making many adjustments to margins and such - and as this evolved it turns out that this was the easiest thing to do. But if we raised the pawn we would have to raise everything else accordingly.
And yes, a pawn is basically 1000 points but the evaluation returns the answer in centi-pawns.
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
Carotino wrote:Of course the "final value" of pieces is a dynamic process and depends on the evaluation function, PST, etc.. But I believe that a correct estimation of the initial value is still important.
The values ​​provided by Larry are good and have sufficient accuracy for humans, but for computer but for a computer I believe that we must use a finer tolerance of 1/4 of pawn. What? that is the question!
Another consideration: usually, we tend to give to the bishop a value slightly higher than the knight. In fact, in my opinion, should be the evaluation functions of the engine to change this (depending on the mobility, PST, controlled square, pawn structure, etc.. etc ...). I think the starting value should be equal... Or not?
As Robert explained, it doesn't matter what the "starting values" are, as long as all the other terms properly adjust for it. In Komodo we try to set the starting values to be the average values, just so that when we make changes we don't get misled. The average value of an unpaired bishop is slightly higher than the average value of a knight; currently we are using one-eighth of a pawn for this difference.
Oh thanks Larry, one-eighth of a pawn seems to be fairly accurate: about 13 centipawns...
Don wrote:{snipped}
Komodo, as well as other programs and probably Houdini too have different values for different game stages.
In Komodo we "center" everything so that the values are actually meaningful to us without too much interpretation. For example our bishop mobility is negative if the bishop is not very mobile and is close to zero when it has "average" mobility. Of course what is average is a judgement call but we try to make that judgement. So for mobility we have defined N squares of mobility to be the centering point - and that is different for each piece. Our piece square tables all have negative and positive entries also in order to capture this same concept. Whenever we implement a new evaluation concept we don't want to have to "lower" or "raise" the value of something else to compensate so we take care to "center" anything that has anything more than a trivial consequence on the evaluation function.
Our values for the opening are:
600, 3100, 3225, 4350, 9100
ending:
925, 3100, 3225, 5475, 9700
We also have other modifiers which have the effect of changing these such as the bishop pair, rook pair, "major piece pair involving queen" and a bunch of other stuff which also considers the effect of the pawns.
I doubt these values will work for just any program but I present them for what they are worth.
{snipped}
Thanks, interesting.
So 1/3100 Knight units instead of millipawns
Still, I found ~60 centies for a pawn in the opening surprisingly small, assuming piece square values are centered around zero, and weak pawns like backward and isolated may receive a additional penalty. How much becomes a strong white pawn say on e4 in the opening?
The pawn value evolved over time - it was once below 1000 for the opening and above 1000 for the ending. To make major changes to the pawn value requires making many adjustments to margins and such - and as this evolved it turns out that this was the easiest thing to do. But if we raised the pawn we would have to raise everything else accordingly.
And yes, a pawn is basically 1000 points but the evaluation returns the answer in centi-pawns.
I see, sorry if my question about the none weak e4 pawn was a bit too impertinent
I guess > 1000.
Don wrote:{snipped}
Komodo, as well as other programs and probably Houdini too have different values for different game stages.
In Komodo we "center" everything so that the values are actually meaningful to us without too much interpretation. For example our bishop mobility is negative if the bishop is not very mobile and is close to zero when it has "average" mobility. Of course what is average is a judgement call but we try to make that judgement. So for mobility we have defined N squares of mobility to be the centering point - and that is different for each piece. Our piece square tables all have negative and positive entries also in order to capture this same concept. Whenever we implement a new evaluation concept we don't want to have to "lower" or "raise" the value of something else to compensate so we take care to "center" anything that has anything more than a trivial consequence on the evaluation function.
Our values for the opening are:
600, 3100, 3225, 4350, 9100
ending:
925, 3100, 3225, 5475, 9700
We also have other modifiers which have the effect of changing these such as the bishop pair, rook pair, "major piece pair involving queen" and a bunch of other stuff which also considers the effect of the pawns.
I doubt these values will work for just any program but I present them for what they are worth.
{snipped}
Thanks, interesting.
So 1/3100 Knight units instead of millipawns
Still, I found ~60 centies for a pawn in the opening surprisingly small, assuming piece square values are centered around zero, and weak pawns like backward and isolated may receive a additional penalty. How much becomes a strong white pawn say on e4 in the opening?
The pawn value in Komodo is artificially low, primarily because an extra pawn is usually also a passed or candidate passed pawn, which gets a nice bonus, especially if advanced. Also unblocked pawns (the usual case) get bonuses. I think we should do something to more properly center the pawn, if only to avoid misleading anyone. You can remove a pawn and set up any configuration you like to answer a question like the above in Komodo; the answer will partly depend on whether the extra pawn on e4 is a Candidate or not, and also on whose turn to move, etc. In the opening position with e7 removed, a one ply search shows 1.e4 with a 0.65 score in Komodo 5 (0.67 in latest version). Since Black gets a side-to move bonus, the static value of the position after 1.e4 with no e7 must be in the upper 70s. This seems about right; on a full board a knight is worth nearly four pawns, and 3.1/4 is .775.
Houdini wrote:Three comments:
1) The value of the pieces evolve with the phase of the game. The values you give above for Houdini are not "piece values", they're just multipliers for a more complex function. They could very well have been 100, 50, 87, 26, 151...
2) Piece values are influenced by the PST (piece-square tables). If you increase all the PST values by 10, the "piece values" will decrease by the same amount.
3) Piece values very much depend on the dynamic factors in the evaluation. If you increase the mobility score for of a piece, its static piece value will have to be decreased to maintain overall balance.
All this means that there is no such thing as a simple "piece value" in Houdini (or in any other engine, for that matter). Comparing the multiplier values you've found in the Houdini executable to classical, "human" piece values is completely meaningless.
Robert
Komodo, as well as other programs and probably Houdini too have different values for different game stages.
In Komodo we "center" everything so that the values are actually meaningful to us without too much interpretation. For example our bishop mobility is negative if the bishop is not very mobile and is close to zero when it has "average" mobility. Of course what is average is a judgement call but we try to make that judgement. So for mobility we have defined N squares of mobility to be the centering point - and that is different for each piece. Our piece square tables all have negative and positive entries also in order to capture this same concept. Whenever we implement a new evaluation concept we don't want to have to "lower" or "raise" the value of something else to compensate so we take care to "center" anything that has anything more than a trivial consequence on the evaluation function.
Our values for the opening are:
600, 3100, 3225, 4350, 9100
If i calculate that back to pawn = 1000 then that gives for
the pieces:
The interesting thing here is that the relative difference to sacrafice an
exchange is under 2.0 pawns. it's less than 1.9 in fact.
Most engines have a relative distance of 2.0 there or even more.
Seems in more modern automatic tuning the tuners tune it lower than 2.0
ending:
925, 3100, 3225, 5475, 9700
We also have other modifiers which have the effect of changing these such as the bishop pair, rook pair, "major piece pair involving queen" and a bunch of other stuff which also considers the effect of the pawns.
I doubt these values will work for just any program but I present them for what they are worth.
I do have a hypothesis on this too. If a program is terrible at handling some specific piece, should the value of that piece be the same as in a program that handled that piece well? Traditionally, programs did not handle their rooks well for example and the programs chances improved if there were no rooks on the board. Of course programs do well with queens too, due to tactics. In the chess club I once attended some weak kid there specializing in the use of knights because it works against weaker plays and he had a knack for playing them. For HIM, the knights were worth more than the bishops - and his entire play was based on deploying and attacking with the knights. He was not hard to beat, but you had to watch his knights and if you could win them his game fell completely apart. If he were a computer program I would say his knights NEEDED to be valued much more than the bishops.
The short version of this is that I believe the values of pieces should be somewhat based on the other heuristics - what really matters is maximizing your strengths and minimizing your weaknesses and for computer chess you have to literally assign numbers to those things.
Houdini wrote:Three comments:
1) The value of the pieces evolve with the phase of the game. The values you give above for Houdini are not "piece values", they're just multipliers for a more complex function. They could very well have been 100, 50, 87, 26, 151...
2) Piece values are influenced by the PST (piece-square tables). If you increase all the PST values by 10, the "piece values" will decrease by the same amount.
3) Piece values very much depend on the dynamic factors in the evaluation. If you increase the mobility score for of a piece, its static piece value will have to be decreased to maintain overall balance.
All this means that there is no such thing as a simple "piece value" in Houdini (or in any other engine, for that matter). Comparing the multiplier values you've found in the Houdini executable to classical, "human" piece values is completely meaningless.
Robert
Komodo, as well as other programs and probably Houdini too have different values for different game stages.
In Komodo we "center" everything so that the values are actually meaningful to us without too much interpretation. For example our bishop mobility is negative if the bishop is not very mobile and is close to zero when it has "average" mobility. Of course what is average is a judgement call but we try to make that judgement. So for mobility we have defined N squares of mobility to be the centering point - and that is different for each piece. Our piece square tables all have negative and positive entries also in order to capture this same concept. Whenever we implement a new evaluation concept we don't want to have to "lower" or "raise" the value of something else to compensate so we take care to "center" anything that has anything more than a trivial consequence on the evaluation function.
Our values for the opening are:
600, 3100, 3225, 4350, 9100
If i calculate that back to pawn = 1000 then that gives for
the pieces:
The interesting thing here is that the relative difference to sacrafice an
exchange is under 2.0 pawns. it's less than 1.9 in fact.
Most engines have a relative distance of 2.0 there or even more.
Seems in more modern automatic tuning the tuners tune it lower than 2.0
ending:
925, 3100, 3225, 5475, 9700
We also have other modifiers which have the effect of changing these such as the bishop pair, rook pair, "major piece pair involving queen" and a bunch of other stuff which also considers the effect of the pawns.
I doubt these values will work for just any program but I present them for what they are worth.
I do have a hypothesis on this too. If a program is terrible at handling some specific piece, should the value of that piece be the same as in a program that handled that piece well? Traditionally, programs did not handle their rooks well for example and the programs chances improved if there were no rooks on the board. Of course programs do well with queens too, due to tactics. In the chess club I once attended some weak kid there specializing in the use of knights because it works against weaker plays and he had a knack for playing them. For HIM, the knights were worth more than the bishops - and his entire play was based on deploying and attacking with the knights. He was not hard to beat, but you had to watch his knights and if you could win them his game fell completely apart. If he were a computer program I would say his knights NEEDED to be valued much more than the bishops.
The short version of this is that I believe the values of pieces should be somewhat based on the other heuristics - what really matters is maximizing your strengths and minimizing your weaknesses and for computer chess you have to literally assign numbers to those things.
The pawn values are understated by at least a 100 for reasons explained earlier, so you should add at least 100 to those numbers when making these calculations.
Houdini wrote:Three comments:
1) The value of the pieces evolve with the phase of the game. The values you give above for Houdini are not "piece values", they're just multipliers for a more complex function. They could very well have been 100, 50, 87, 26, 151...
2) Piece values are influenced by the PST (piece-square tables). If you increase all the PST values by 10, the "piece values" will decrease by the same amount.
3) Piece values very much depend on the dynamic factors in the evaluation. If you increase the mobility score for of a piece, its static piece value will have to be decreased to maintain overall balance.
All this means that there is no such thing as a simple "piece value" in Houdini (or in any other engine, for that matter). Comparing the multiplier values you've found in the Houdini executable to classical, "human" piece values is completely meaningless.
Robert
Komodo, as well as other programs and probably Houdini too have different values for different game stages.
In Komodo we "center" everything so that the values are actually meaningful to us without too much interpretation. For example our bishop mobility is negative if the bishop is not very mobile and is close to zero when it has "average" mobility. Of course what is average is a judgement call but we try to make that judgement. So for mobility we have defined N squares of mobility to be the centering point - and that is different for each piece. Our piece square tables all have negative and positive entries also in order to capture this same concept. Whenever we implement a new evaluation concept we don't want to have to "lower" or "raise" the value of something else to compensate so we take care to "center" anything that has anything more than a trivial consequence on the evaluation function.
Our values for the opening are:
600, 3100, 3225, 4350, 9100
If i calculate that back to pawn = 1000 then that gives for
the pieces:
The interesting thing here is that the relative difference to sacrafice an
exchange is under 2.0 pawns. it's less than 1.9 in fact.
Most engines have a relative distance of 2.0 there or even more.
Seems in more modern automatic tuning the tuners tune it lower than 2.0
ending:
925, 3100, 3225, 5475, 9700
We also have other modifiers which have the effect of changing these such as the bishop pair, rook pair, "major piece pair involving queen" and a bunch of other stuff which also considers the effect of the pawns.
I doubt these values will work for just any program but I present them for what they are worth.
I do have a hypothesis on this too. If a program is terrible at handling some specific piece, should the value of that piece be the same as in a program that handled that piece well? Traditionally, programs did not handle their rooks well for example and the programs chances improved if there were no rooks on the board. Of course programs do well with queens too, due to tactics. In the chess club I once attended some weak kid there specializing in the use of knights because it works against weaker plays and he had a knack for playing them. For HIM, the knights were worth more than the bishops - and his entire play was based on deploying and attacking with the knights. He was not hard to beat, but you had to watch his knights and if you could win them his game fell completely apart. If he were a computer program I would say his knights NEEDED to be valued much more than the bishops.
The short version of this is that I believe the values of pieces should be somewhat based on the other heuristics - what really matters is maximizing your strengths and minimizing your weaknesses and for computer chess you have to literally assign numbers to those things.
The pawn values are understated by at least a 100 for reasons explained earlier, so you should add at least 100 to those numbers when making these calculations.
You refer to bonuses for things like passers, everyone has those Larry.
This is the basic material evaluation. It's important to factorize correctly and what i wrote down seems correct.
Houdini wrote:Three comments:
1) The value of the pieces evolve with the phase of the game. The values you give above for Houdini are not "piece values", they're just multipliers for a more complex function. They could very well have been 100, 50, 87, 26, 151...
2) Piece values are influenced by the PST (piece-square tables). If you increase all the PST values by 10, the "piece values" will decrease by the same amount.
3) Piece values very much depend on the dynamic factors in the evaluation. If you increase the mobility score for of a piece, its static piece value will have to be decreased to maintain overall balance.
All this means that there is no such thing as a simple "piece value" in Houdini (or in any other engine, for that matter). Comparing the multiplier values you've found in the Houdini executable to classical, "human" piece values is completely meaningless.
Robert
Komodo, as well as other programs and probably Houdini too have different values for different game stages.
In Komodo we "center" everything so that the values are actually meaningful to us without too much interpretation. For example our bishop mobility is negative if the bishop is not very mobile and is close to zero when it has "average" mobility. Of course what is average is a judgement call but we try to make that judgement. So for mobility we have defined N squares of mobility to be the centering point - and that is different for each piece. Our piece square tables all have negative and positive entries also in order to capture this same concept. Whenever we implement a new evaluation concept we don't want to have to "lower" or "raise" the value of something else to compensate so we take care to "center" anything that has anything more than a trivial consequence on the evaluation function.
Our values for the opening are:
600, 3100, 3225, 4350, 9100
If i calculate that back to pawn = 1000 then that gives for
the pieces:
The interesting thing here is that the relative difference to sacrafice an
exchange is under 2.0 pawns. it's less than 1.9 in fact.
Most engines have a relative distance of 2.0 there or even more.
Seems in more modern automatic tuning the tuners tune it lower than 2.0
ending:
925, 3100, 3225, 5475, 9700
We also have other modifiers which have the effect of changing these such as the bishop pair, rook pair, "major piece pair involving queen" and a bunch of other stuff which also considers the effect of the pawns.
I doubt these values will work for just any program but I present them for what they are worth.
I do have a hypothesis on this too. If a program is terrible at handling some specific piece, should the value of that piece be the same as in a program that handled that piece well? Traditionally, programs did not handle their rooks well for example and the programs chances improved if there were no rooks on the board. Of course programs do well with queens too, due to tactics. In the chess club I once attended some weak kid there specializing in the use of knights because it works against weaker plays and he had a knack for playing them. For HIM, the knights were worth more than the bishops - and his entire play was based on deploying and attacking with the knights. He was not hard to beat, but you had to watch his knights and if you could win them his game fell completely apart. If he were a computer program I would say his knights NEEDED to be valued much more than the bishops.
The short version of this is that I believe the values of pieces should be somewhat based on the other heuristics - what really matters is maximizing your strengths and minimizing your weaknesses and for computer chess you have to literally assign numbers to those things.
The pawn values are understated by at least a 100 for reasons explained earlier, so you should add at least 100 to those numbers when making these calculations.
You refer to bonuses for things like passers, everyone has those Larry.
This is the basic material evaluation. It's important to factorize correctly and what i wrote down seems correct.
It is not factorizing correctly because it seems that the komodo team forgot to center the pawn value correctly by substracting something in the evaluation for pawns that are not passed pawns.
