Pieze/square tables

[Kempelen]

isn't mobility a sustitute of pieze/square tables?

I mean, bishop in the center has more moves, so if mobility computation is done, no tables are needed because search tend to move bishop there.... or the contrary, if pieze/square tables are used, no mobility needed .....
(in this I only has doubts with kinght)

Also..... adjustint mobility for each pieze to value the same, has sense? something like:

Code: Select all

              switch (pieza) {
                    case CABALLO:
                        evalNegras += EV_B_MOVILIDAD * (movilidad_pieza - 4) * 3.5f;
                        break;
                    case ALFIL:
                        evalNegras += EV_B_MOVILIDAD * (movilidad_pieza - 7) * 2;
                        break;
                    case TORRE:
                        evalNegras += EV_B_MOVILIDAD * (movilidad_pieza - 7) * 2;
                        break;
                    case DAMA:
                        evalNegras += EV_B_MOVILIDAD * (movilidad_pieza - 14);
                        break;
                    default:
                        ;
                }

(4, 7 and 14 are the average mobility per pieze)

[Dann Corbit]

isn't mobility a sustitute of pieze/square tables?

I mean, bishop in the center has more moves, so if mobility computation is done, no tables are needed because search tend to move bishop there.... or the contrary, if pieze/square tables are used, no mobility needed .....
(in this I only has doubts with kinght)

Also..... adjustint mobility for each pieze to value the same, has sense? something like:

Code: Select all

              switch (pieza) {
                    case CABALLO:
                        evalNegras += EV_B_MOVILIDAD * (movilidad_pieza - 4) * 3.5f;
                        break;
                    case ALFIL:
                        evalNegras += EV_B_MOVILIDAD * (movilidad_pieza - 7) * 2;
                        break;
                    case TORRE:
                        evalNegras += EV_B_MOVILIDAD * (movilidad_pieza - 7) * 2;
                        break;
                    case DAMA:
                        evalNegras += EV_B_MOVILIDAD * (movilidad_pieza - 14);
                        break;
                    default:
                        ;
                }

(4, 7 and 14 are the average mobility per pieze)

They are very similar, but (for instance) pawns controlling the center are not necessarily more mobile than pawns not controlling the center. A fianchetto bishop has less mobility than one in the center. A knight near your king has the same mobility as a knight near the opponent's king. The big aim of the piece square tables is to get your pieces in a position similar to what a human would. I don't think that mobility alone is enough, but probably if you add a few rules you could accomplish the same thing.

[bob]

isn't mobility a sustitute of pieze/square tables?

I mean, bishop in the center has more moves, so if mobility computation is done, no tables are needed because search tend to move bishop there.... or the contrary, if pieze/square tables are used, no mobility needed .....
(in this I only has doubts with kinght)

Also..... adjustint mobility for each pieze to value the same, has sense? something like:

Code: Select all

              switch (pieza) {
                    case CABALLO:
                        evalNegras += EV_B_MOVILIDAD * (movilidad_pieza - 4) * 3.5f;
                        break;
                    case ALFIL:
                        evalNegras += EV_B_MOVILIDAD * (movilidad_pieza - 7) * 2;
                        break;
                    case TORRE:
                        evalNegras += EV_B_MOVILIDAD * (movilidad_pieza - 7) * 2;
                        break;
                    case DAMA:
                        evalNegras += EV_B_MOVILIDAD * (movilidad_pieza - 14);
                        break;
                    default:
                        ;
                }

(4, 7 and 14 are the average mobility per pieze)

They are not quite the same thing. Piece square tables identify good squares (in general) for pieces to stand on. But mobility is a different issue that is a measure of how pieces or pawns are restricting a piece's ability to move to other squares... Poor mobility on a good square is still bad news, while lots of mobility on a bad square is not a lot better...

[CThinker]

isn't mobility a sustitute of pieze/square tables?

I mean, bishop in the center has more moves, so if mobility computation is done, no tables are needed because search tend to move bishop there.... or the contrary, if pieze/square tables are used, no mobility needed .....
(in this I only has doubts with kinght)

Also..... adjustint mobility for each pieze to value the same, has sense? something like:

Code: Select all

              switch (pieza) {
                    case CABALLO:
                        evalNegras += EV_B_MOVILIDAD * (movilidad_pieza - 4) * 3.5f;
                        break;
                    case ALFIL:
                        evalNegras += EV_B_MOVILIDAD * (movilidad_pieza - 7) * 2;
                        break;
                    case TORRE:
                        evalNegras += EV_B_MOVILIDAD * (movilidad_pieza - 7) * 2;
                        break;
                    case DAMA:
                        evalNegras += EV_B_MOVILIDAD * (movilidad_pieza - 14);
                        break;
                    default:
                        ;
                }

(4, 7 and 14 are the average mobility per pieze)

They actually are two different things. Although, there is a good chance of being mobile at the center than at the corner.

Still, you can have a queen at the center which is surrounded by other pieces. With that, you have a queen on a good square, but is immobile.

[CRoberson]

To assume that PSQ = mobility means that mobility = PSQ and
that is definitely not true. PSQ typically has you control the classic
square such as Nf3 NC3 Bf4 BC4 but due to specific pawn placement
these squares may have little mobility relative to some of the other
squares.

[Matthias Gemuh]

isn't mobility a sustitute of pieze/square tables?

They are as different as night and day.
You can have zero mobility (for any piece) in centre of board.

Matthias.

[hgm]

PSTs are a poor-man's solution to mobility: they makes the engine put pieces in places where on average they have the best mobility. This means you give them the best chances for having high mobility. But you still leave to chance something that you could have known, and so often it leads to positionally stupid play.

[d] 8/8/8/8/8/2B5/8/8 w - - 0 1
Usually a good place for a Bishop

[d] 8/8/2p5/1pPp4/1P1Pp3/2B1P3/1P6/8 w - - 0 1
Perhaps you should consider relocating it to a 'worse' square

[Kempelen]

I think that maybe the are not stupid situation, because this samples show that mobility is more important factor than PST. In the second one, if mobility > PSQ , the search will tend to find a better situation for the bishop. Isn't it?

[hgm]

Yes, it would.

[bob]

I think that maybe the are not stupid situation, because this samples show that mobility is more important factor than PST. In the second one, if mobility > PSQ , the search will tend to find a better situation for the bishop. Isn't it?

Yes, but you were implying that you would do one or the other. It is up to you as to how you evaluate mobility, but given a bishop on two good squares according to the piece/square values, I'd choose the one where the bishop had the most mobility. Given two bishops with equal mobility, I would choose the one that is on the more favorable square. So the two terms are complementary.