Determining values for piece-square tables.

[xsadar]

For a long time I've had piece-square tables in my engine that I had "temporarily" borrowed from other engines. This has prevented me from releasing my engine, because I want to release an engine that's entirely my own work (and definitely avoid releasing an engine that infringes on other people's copyrights).
I've begun a complete rewrite from the ground up, and have no intention of borrowing tables again, so my question is: how do people come up with these values in the first place?

I'm pretty mediocre at chess myself, and have very little book knowledge about chess, so any guesstimates I make will most likely be way off, and I would imagine that even a Grand Master's estimates would be off by a fair amount. So are there any suggestions on how I can go about determining those values? Or information I might be able to use in the process? Testing my values will be quite a task since I don't have a cluster like Bob's -- I'll just have to run tests while I'm at work or sleeping -- so, obviously, the closer I can get my initial estimates, the better.

[Don]

For a long time I've had piece-square tables in my engine that I had "temporarily" borrowed from other engines. This has prevented me from releasing my engine, because I want to release an engine that's entirely my own work (and definitely avoid releasing an engine that infringes on other people's copyrights).
I've begun a complete rewrite from the ground up, and have no intention of borrowing tables again, so my question is: how do people come up with these values in the first place?

I'm pretty mediocre at chess myself, and have very little book knowledge about chess, so any guesstimates I make will most likely be way off, and I would imagine that even a Grand Master's estimates would be off by a fair amount. So are there any suggestions on how I can go about determining those values? Or information I might be able to use in the process? Testing my values will be quite a task since I don't have a cluster like Bob's -- I'll just have to run tests while I'm at work or sleeping -- so, obviously, the closer I can get my initial estimates, the better.

It's pretty much a black art. I suggest you look at a bunch of different programs that have available source code and see if you can determine what the most important themes are.

[mclane]

make an array /table for each piece.

take grandmaster games.
bring each movement into the array with 1 point.
run through the database and you will get
data that is sensible because it came out of good human games.

IMO this way you would get good piece-square tables with a realistic value.

[Gian-Carlo Pascutto]

make an array /table for each piece.

take grandmaster games.
bring each movement into the array with 1 point.
run through the database and you will get
data that is sensible because it came out of good human games.

IMO this way you would get good piece-square tables with a realistic value.

If you try this, you will see it fails.

[Don]

For a long time I've had piece-square tables in my engine that I had "temporarily" borrowed from other engines. This has prevented me from releasing my engine, because I want to release an engine that's entirely my own work (and definitely avoid releasing an engine that infringes on other people's copyrights).
I've begun a complete rewrite from the ground up, and have no intention of borrowing tables again, so my question is: how do people come up with these values in the first place?

I'm pretty mediocre at chess myself, and have very little book knowledge about chess, so any guesstimates I make will most likely be way off, and I would imagine that even a Grand Master's estimates would be off by a fair amount. So are there any suggestions on how I can go about determining those values? Or information I might be able to use in the process? Testing my values will be quite a task since I don't have a cluster like Bob's -- I'll just have to run tests while I'm at work or sleeping -- so, obviously, the closer I can get my initial estimates, the better.

There are some guiding principles that I try to follow. For each piece you can list some constraints, rules you want to follow. For instance with pawns you may want to have the rule that pawns are worth more as you move towards the center and the a and h are worth a lot less. Put down principles like this and try to pick values that will make them work.

Another couple of issues are piece centering and range. Piece centering is the concept that you have both negative and positive values in your piece square table. You want the average piece to have the base value of the piece so that good squares are worth more than the piece and bad squares are worth less. This is important for many reasons, such as lazy evaluation later and the creative use of margins when your program is refined. It's also important to know that if you set your knight to 340 (for instance) it is REALLY 340 in the average case.

In my program there is a table of piece square values that are independent of the pieces. If you want only piece square tables you can just add them in when the program starts up. If you are uncomfortable working with negative numbers just pick a square you consider average for that piece and adjust them all by that amount (so that this square gets zero) when the program starts up.

The other issue that is important is the range of values of the pieces. You need to decide how much difference there is between a really good piece and a really bad piece in your tables. If those are not properly balanced between pieces your program will make bad positional decisions. I have an exception to this, I give knights on a8 and h8 huge penalties because I want to force the search to never end at a leaf node with knights on those squares (unless it's worth it even with my huge penalty.) But the range calculation should consider fairly typical usage.

If you put all of these factors together your table can almost build itself. Some versions of my program actually do that, I don't hard code a table but instead I compute the table based on a bunch of general rules.

I am assuming you are trying to get a relatively accurate FIXED piece square table to start working from. In many ways a piece square table is just wrong and in the old days the table WAS computed based on looking at the root position. Based on what you told me about your program, that is probably what you need to do. That is called a pre-processor. It's wrong too, but so is everything else evaluation related, it is all guesswork and approximations. Piece Square Tables have been remarkably effective if done well. An example of this is that if the C file is open, you would give extra points for putting a rooks on that file.

My piece square tables are only designed to capture very general principles because chess is too dynamic and I have other things to deal with more specific things.

[Don]

For a long time I've had piece-square tables in my engine that I had "temporarily" borrowed from other engines. This has prevented me from releasing my engine, because I want to release an engine that's entirely my own work (and definitely avoid releasing an engine that infringes on other people's copyrights).
I've begun a complete rewrite from the ground up, and have no intention of borrowing tables again, so my question is: how do people come up with these values in the first place?

I'm pretty mediocre at chess myself, and have very little book knowledge about chess, so any guesstimates I make will most likely be way off, and I would imagine that even a Grand Master's estimates would be off by a fair amount. So are there any suggestions on how I can go about determining those values? Or information I might be able to use in the process? Testing my values will be quite a task since I don't have a cluster like Bob's -- I'll just have to run tests while I'm at work or sleeping -- so, obviously, the closer I can get my initial estimates, the better.

One thing I that has entered my mind for a long time is to build a system for building weights for an evaluation function, and this could apply to piece square tables too. It would be based on general principles, not highly specific rules. The principles would be something like invariants or constraints. You would not tell it how much a piece is worth, you would only give it enough information to work that out for itself.

For example:

N > P
R > N
R > B
N+B > R

etc ...

You would only put in constraints you believed in. The system would attempt to fit a set of weights to your set of rules in such a way that everything worked out. If your rules had conflicts that would be flagged for your inspection.

It would be fun putting such a system together. But it would let you focus on the general principles you want to capture without having to obsess over the particulars.

You might have operators such as "approximate equality" which means get it as close as you can. Or you might be able to say get as close as you can where one values is never less than the other.

All things being equal the system would favor using the smallest range that satisfied all the constraints. For instance if you said R > N there are an infinite set of values that satisfy that, but the system would choose R = N+1 unless some other constraint (such as N+B > R) affected this.

There would be no exact solution of course and you might use some kind of learning algorithm or fitness function to search for sets of weights that worked.

[Sergei Markoff]

make an array /table for each piece.

take grandmaster games.
bring each movement into the array with 1 point.
run through the database and you will get
data that is sensible because it came out of good human games.

IMO this way you would get good piece-square tables with a realistic value.

It will not work because for example Nb1-c3 is more frequent than Nc3-e4 and so on.

[Don]

make an array /table for each piece.

take grandmaster games.
bring each movement into the array with 1 point.
run through the database and you will get
data that is sensible because it came out of good human games.

IMO this way you would get good piece-square tables with a realistic value.

It will not work because for example Nb1-c3 is more frequent than Nc3-e4 and so on.

I'm not saying this will work, but it's possible to use the Bradley Terry model and assign scores to moves. This has been done in GO for patterns. The bradley terry model essential assigned ELO ratings to moves and this could be done by looking at high level games.

So in your example, it doesn't matter how often Nc3 is played, what matters is how it does in competition with other moves. So if a move is played a very high percentage of the time when it's possible to play it, then this would indicate that the move is a very good move.

If I were to do this, I would at least perform see() on each move and only consider non-losing moves as part of the Bradley Terry model. So if half the moves were losing moves, I would not consider "rating" them using the Bradley Terry model.

[xsadar]

Thanks for all the thoughts Don. When I've tried before to make piece-square tables, I figured I could just follow the general rules, but I really know very few of the general rules. I know you should try to control the center. I know to keep knights away from the edges. I know to move the king more toward the center in the end game, but of course keep it safely tucked away behind some pawns in the corner before that.
So that leads to the question, where can I find more information on general rules that are more pertinent to piece-square tables? Of course I know there are millions of chess books out there, but I'm looking for something most pertinent to the task at hand. On the web would be ideal (and as I remember there is at least some on CPW), but I'm not completely opposed to buying a book if it's worth the cost.
Also, I just realized, I don't have to put everything I want it to know into the tables at once, but I can build them up gradually over time. I can start by figuring in one simple rule, and test that, then figure in another rule, and test that, and so on. That would definitely work best if I generate them on the fly as you suggest. The difficult part of course will be figuring the range of values.

[xsadar]

make an array /table for each piece.

take grandmaster games.
bring each movement into the array with 1 point.
run through the database and you will get
data that is sensible because it came out of good human games.

IMO this way you would get good piece-square tables with a realistic value.

It will not work because for example Nb1-c3 is more frequent than Nc3-e4 and so on.

I'm not saying this will work, but it's possible to use the Bradley Terry model and assign scores to moves. This has been done in GO for patterns. The bradley terry model essential assigned ELO ratings to moves and this could be done by looking at high level games.

So in your example, it doesn't matter how often Nc3 is played, what matters is how it does in competition with other moves. So if a move is played a very high percentage of the time when it's possible to play it, then this would indicate that the move is a very good move.

If I were to do this, I would at least perform see() on each move and only consider non-losing moves as part of the Bradley Terry model. So if half the moves were losing moves, I would not consider "rating" them using the Bradley Terry model.

This sounds about like what I was thinking when I read Thorsten's post (thanks Thorsten), although I don't know anything about the Bradley Terry model specifically. But the idea of comparing how well for example Ne4 does in games compared to other squares, doesn't sound to bad.