TalkChess.com

In RomiChess the piece/square tables are created dynamically before each search. This can lead to some extreamly unbalanced evals leading to things like bad sacrifices and other pathalogical behaviors. So, what is best, limiting each square to a maximum or adding up all the squares and scaling them all down to some total maximum or scaling wPos - bPos so that it is at the most some +/- value or what?

Thanks!

Michael Sherwin wrote:In RomiChess the piece/square tables are created dynamically before each search. This can lead to some extreamly unbalanced evals leading to things like bad sacrifices and other pathalogical behaviors. So, what is best, limiting each square to a maximum or adding up all the squares and scaling them all down to some total maximum or scaling wPos - bPos so that it is at the most some +/- value or what?

Thanks!

In XiniX, I limit the extremes that are "spiking". fe I have no problem with giving a passed pawn a bonus X, but when rank-1 and rank+1 only have x/2 bonusses, it gets adjusted.

This can happen in my (buggy) neural net implementation.

I also have to take care of "doubles".
In my definition, I thought a backwards pawn was bad, but the neural net found good backward pawns: Pawns on the 6th rank, since my definition says that there must be a pawn ahead of it. So I was actually scoring backward pawns AND defended passed pawns.

Tony

Michael Sherwin wrote:In RomiChess the piece/square tables are created dynamically before each search. This can lead to some extreamly unbalanced evals leading to things like bad sacrifices and other pathalogical behaviors. So, what is best, limiting each square to a maximum or adding up all the squares and scaling them all down to some total maximum or scaling wPos - bPos so that it is at the most some +/- value or what?

Thanks!

I think that the best is not to create dynamically piece square tables before each search.

Uri Blass wrote:

Michael Sherwin wrote:In RomiChess the piece/square tables are created dynamically before each search. This can lead to some extreamly unbalanced evals leading to things like bad sacrifices and other pathalogical behaviors. So, what is best, limiting each square to a maximum or adding up all the squares and scaling them all down to some total maximum or scaling wPos - bPos so that it is at the most some +/- value or what?

Thanks!

I think that the best is not to create dynamically piece square tables before each search.

I am aware of the argument of root evaluation of squares vs. that of endleaf evaluation. I have decided to investigate the former as it is possible to use huge amounts of chess knowledge to build the tables at virtually no cost in time to the search. Also the move that is played at the root is far more important than any move that may or may not be made further up in the tree and information from the root is more strategically in tune with the first move. However, I still see the need for endleaf evaluation and that is where the pawn structure eval and two bishop bonus are done (and other things that are planned). One thing that I have not done yet is to bonus/malus pawn squares based on how the pawn placement affects the movements of the pieces. That should help a lot. None of this addresses my original question though.

One thing of note is, that I have worked mostly on the search these last two years and only have a couple of days invested in the eval so far. So, unless I am a genius ( and I'm not) and created the almost absolute best 'root evaluator' from the start, there is still much to be gained from two more years work on the eval.

So, other than the argument that the search is too deep and root evaluation is therefore too inaccurate on modern computers, what if any further argument is there against root evaluation?

Tony wrote:

Michael Sherwin wrote:In RomiChess the piece/square tables are created dynamically before each search. This can lead to some extreamly unbalanced evals leading to things like bad sacrifices and other pathalogical behaviors. So, what is best, limiting each square to a maximum or adding up all the squares and scaling them all down to some total maximum or scaling wPos - bPos so that it is at the most some +/- value or what?

Thanks!

In XiniX, I limit the extremes that are "spiking". fe I have no problem with giving a passed pawn a bonus X, but when rank-1 and rank+1 only have x/2 bonusses, it gets adjusted.

This can happen in my (buggy) neural net implementation.

I also have to take care of "doubles".
In my definition, I thought a backwards pawn was bad, but the neural net found good backward pawns: Pawns on the 6th rank, since my definition says that there must be a pawn ahead of it. So I was actually scoring backward pawns AND defended passed pawns.

Tony

So, if at the beginning of the search, when the pawn tables are being generated, if there are a lot of advanced pawns for one side then to avoid a huge spike in the eval for that side the pawn tables should be adjusted downward some?

Michael Sherwin wrote:

Uri Blass wrote:

Michael Sherwin wrote:In RomiChess the piece/square tables are created dynamically before each search. This can lead to some extreamly unbalanced evals leading to things like bad sacrifices and other pathalogical behaviors. So, what is best, limiting each square to a maximum or adding up all the squares and scaling them all down to some total maximum or scaling wPos - bPos so that it is at the most some +/- value or what?

Thanks!

I think that the best is not to create dynamically piece square tables before each search.

I am aware of the argument of root evaluation of squares vs. that of endleaf evaluation. I have decided to investigate the former as it is possible to use huge amounts of chess knowledge to build the tables at virtually no cost in time to the search. Also the move that is played at the root is far more important than any move that may or may not be made further up in the tree and information from the root is more strategically in tune with the first move. However, I still see the need for endleaf evaluation and that is where the pawn structure eval and two bishop bonus are done (and other things that are planned). One thing that I have not done yet is to bonus/malus pawn squares based on how the pawn placement affects the movements of the pieces. That should help a lot. None of this addresses my original question though.

One thing of note is, that I have worked mostly on the search these last two years and only have a couple of days invested in the eval so far. So, unless I am a genius ( and I'm not) and created the almost absolute best 'root evaluator' from the start, there is still much to be gained from two more years work on the eval.

So, other than the argument that the search is too deep and root evaluation is therefore too inaccurate on modern computers, what if any further argument is there against root evaluation?

It just doesn't work well. You are using information at position X to establish critical evaluation parameters. Then you evaluate position Y, which is _many_ plies removed from position X. At position X, king safety might have been meaningless, while at position Y, your king is terribly exposed. Processing at the root would base the eval on the position where your king is safe, and make terrible errors in the actual position being evaluated. It works when you search very shallow trees. But the deeper you can go, the farther the real positions you evaluate are removed from the root position where you set the terms up.

Michael Sherwin wrote:

Tony wrote:

Michael Sherwin wrote:In RomiChess the piece/square tables are created dynamically before each search. This can lead to some extreamly unbalanced evals leading to things like bad sacrifices and other pathalogical behaviors. So, what is best, limiting each square to a maximum or adding up all the squares and scaling them all down to some total maximum or scaling wPos - bPos so that it is at the most some +/- value or what?

Thanks!

In XiniX, I limit the extremes that are "spiking". fe I have no problem with giving a passed pawn a bonus X, but when rank-1 and rank+1 only have x/2 bonusses, it gets adjusted.

This can happen in my (buggy) neural net implementation.

I also have to take care of "doubles".
In my definition, I thought a backwards pawn was bad, but the neural net found good backward pawns: Pawns on the 6th rank, since my definition says that there must be a pawn ahead of it. So I was actually scoring backward pawns AND defended passed pawns.

Tony

So, if at the beginning of the search, when the pawn tables are being generated, if there are a lot of advanced pawns for one side then to avoid a huge spike in the eval for that side the pawn tables should be adjusted downward some?

No, not quite.

The amount of advanced pawns has nothing to do with it. The adjustment is not on the eval as a whole, but on certain parts.

Fe I generate the tables for the passed pawns with certain pieces on the boards and the kings on certain locations/sides. Then I make sure that a passed pawn on A6 has a higher score than one on A5 (assuming the same other circumstances) but not as high as on A7.

Further I make sure that a passed pawn on A6 with my king on the queenside and your king on the kingsside, has a higher score than both our kings on the queenside etc.

Tony

bob wrote:

Michael Sherwin wrote:

Uri Blass wrote:

Michael Sherwin wrote:In RomiChess the piece/square tables are created dynamically before each search. This can lead to some extreamly unbalanced evals leading to things like bad sacrifices and other pathalogical behaviors. So, what is best, limiting each square to a maximum or adding up all the squares and scaling them all down to some total maximum or scaling wPos - bPos so that it is at the most some +/- value or what?

Thanks!

I think that the best is not to create dynamically piece square tables before each search.

I am aware of the argument of root evaluation of squares vs. that of endleaf evaluation. I have decided to investigate the former as it is possible to use huge amounts of chess knowledge to build the tables at virtually no cost in time to the search. Also the move that is played at the root is far more important than any move that may or may not be made further up in the tree and information from the root is more strategically in tune with the first move. However, I still see the need for endleaf evaluation and that is where the pawn structure eval and two bishop bonus are done (and other things that are planned). One thing that I have not done yet is to bonus/malus pawn squares based on how the pawn placement affects the movements of the pieces. That should help a lot. None of this addresses my original question though.

One thing of note is, that I have worked mostly on the search these last two years and only have a couple of days invested in the eval so far. So, unless I am a genius ( and I'm not) and created the almost absolute best 'root evaluator' from the start, there is still much to be gained from two more years work on the eval.

So, other than the argument that the search is too deep and root evaluation is therefore too inaccurate on modern computers, what if any further argument is there against root evaluation?

It just doesn't work well. You are using information at position X to establish critical evaluation parameters. Then you evaluate position Y, which is _many_ plies removed from position X. At position X, king safety might have been meaningless, while at position Y, your king is terribly exposed. Processing at the root would base the eval on the position where your king is safe, and make terrible errors in the actual position being evaluated. It works when you search very shallow trees. But the deeper you can go, the farther the real positions you evaluate are removed from the root position where you set the terms up.

Although in my program I have moved completely away from assigning values based on root analysis and now calculate everything I need at each node, I do think one inbetween technique is to use 2 tables. One for the opening and one for the endgame, then interpolate between these two values (Fruit does this). You then can set a piece value table entry for the openeing and for the endgame, and that can compensate a lot for things like piece safety, passed pawn scaling etc. Not as good as realy taking the current position into account, but a lot better than a static piece-square table.

mjlef wrote:

bob wrote:

Michael Sherwin wrote:

Uri Blass wrote:

Michael Sherwin wrote:In RomiChess the piece/square tables are created dynamically before each search. This can lead to some extreamly unbalanced evals leading to things like bad sacrifices and other pathalogical behaviors. So, what is best, limiting each square to a maximum or adding up all the squares and scaling them all down to some total maximum or scaling wPos - bPos so that it is at the most some +/- value or what?

Thanks!

I think that the best is not to create dynamically piece square tables before each search.

I am aware of the argument of root evaluation of squares vs. that of endleaf evaluation. I have decided to investigate the former as it is possible to use huge amounts of chess knowledge to build the tables at virtually no cost in time to the search. Also the move that is played at the root is far more important than any move that may or may not be made further up in the tree and information from the root is more strategically in tune with the first move. However, I still see the need for endleaf evaluation and that is where the pawn structure eval and two bishop bonus are done (and other things that are planned). One thing that I have not done yet is to bonus/malus pawn squares based on how the pawn placement affects the movements of the pieces. That should help a lot. None of this addresses my original question though.

One thing of note is, that I have worked mostly on the search these last two years and only have a couple of days invested in the eval so far. So, unless I am a genius ( and I'm not) and created the almost absolute best 'root evaluator' from the start, there is still much to be gained from two more years work on the eval.

So, other than the argument that the search is too deep and root evaluation is therefore too inaccurate on modern computers, what if any further argument is there against root evaluation?

It just doesn't work well. You are using information at position X to establish critical evaluation parameters. Then you evaluate position Y, which is _many_ plies removed from position X. At position X, king safety might have been meaningless, while at position Y, your king is terribly exposed. Processing at the root would base the eval on the position where your king is safe, and make terrible errors in the actual position being evaluated. It works when you search very shallow trees. But the deeper you can go, the farther the real positions you evaluate are removed from the root position where you set the terms up.

Although in my program I have moved completely away from assigning values based on root analysis and now calculate everything I need at each node, I do think one inbetween technique is to use 2 tables. One for the opening and one for the endgame, then interpolate between these two values (Fruit does this). You then can set a piece value table entry for the openeing and for the endgame, and that can compensate a lot for things like piece safety, passed pawn scaling etc. Not as good as realy taking the current position into account, but a lot better than a static piece-square table.

That's not quite the thing we are talking about. At the root, you notice your opponent's king appears to be safe, so you set up everything to develop normally and try to control the center (or vice-versa). 20 plies down, you have discovered a way to expose his king, but it doesn't look interesting since your scoring terms are not concerned with an exposed king at depth 20 since at depth=1 the king was not exposed.

The point being that in the days (70's) of 5 ply searches, this idea was perfectly safe (you couldn't do much in 5 plies to drastically change a position) but today's 20 ply searches put those tip positions a _long_ way away from the root position where things started.

In an extreme case, you could notice (at the root) that your opponent has some significant (you think) threat, but by ply-4 the threat is gone. Yet your evaluation is worrying about that threat all the way out to depth=20. And guiding your search away from what is really about to happen were you looking more carefully...

You need to consider the point of the search. The point is to find achievable positions for the positoin evaluator to decide if the positions are worth reaching. The position evaluation has to be evaluated based on its own merits and not on the merits of the root position. This is exactly the advice of several chess IM's and GM's.

I have several books by Eugene Znosko-Borovsky. One of them is "How Not to Play Chess". In it, he states a very common mistake for beginner to intermediate chess players is to become enamored with the search and lose site of the resulting position. They find a waycool (punn intended) combination and go for it, but they don't see that it leads them to a lost position.

A great combo that leads to a lost position is useless.