Stockfish - material balance/imbalance evaluation

[Milos]

Also from the top of my head elsewhere in the code when we have two bishops it is assumed these are opposite coloured bishops. It is commented that it would be better to do an explicit check because one or more of these bishops might be underpromoted, so they could be of the same colour.

Underpromotions are so rare that material values there have totally marginal influence. Wrong material value of underpromoted bishop pair??? Well, I think room temperature where you keep your machine has more impact on strength of engine than this...

[Eelco de Groot]

P.S. Tord once said that he would give some description of the new imbalance code, if there came a request for some clarification. But I suppose our feeble brains were not yet ready for grasping the simplicity yet also the complexity of his implementation Was this somewhere around the introduction of Stockfish 1.5? I'm not sure exactly when.

Maybe if Tord finds some time he would be willing to tell a bit more about this. As Joona and Marco also mentioned, Tord said it was a bit of a disappointment that not more elos could be squeezed out of his code yet.
It is difficult also to visualize for us mere humans what any change in the code might do It would be interesting if a different set of constants could be found that works as well as the tuned one from the Stockfish programmers.

Eelco

[Eelco de Groot]

Also from the top of my head elsewhere in the code when we have two bishops it is assumed these are opposite coloured bishops. It is commented that it would be better to do an explicit check because one or more of these bishops might be underpromoted, so they could be of the same colour.

Underpromotions are so rare that material values there have totally marginal influence. Wrong material value of underpromoted bishop pair??? Well, I think room temperature where you keep your machine has more impact on strength of engine than this...

This depends on what you are aiming at. In fast games this is very different from the analysis of a correspondence game, where every detail matters. In my opinion, well just ask Vas if he intends ignoring Bishop underpromotions in his server versions. Maybe he will you a clear answer, and maybe he will not.

Eelco

[Ralph Stoesser]

Also from the top of my head elsewhere in the code when we have two bishops it is assumed these are opposite coloured bishops. It is commented that it would be better to do an explicit check because one or more of these bishops might be underpromoted, so they could be of the same colour.

You probably meant this code?

endgame.cpp, line 120

Code: Select all

if (   pos.piece_count(strongerSide, QUEEN) > 0
      || pos.piece_count(strongerSide, ROOK) > 0
      || pos.piece_count(strongerSide, BISHOP) > 1)
      // TODO: check for two equal-colored bishops!
      result += VALUE_KNOWN_WIN;

Maybe it's worth to fix it someday, although highly unlikely to occur.

Btw: From watching games I think Stockfish's bishop eval is not the best. There is no "bad bishop" evaluation. I've tried to penalize positions with blocked pawns of the same square color as the bishop's square color, but there was very little Elo improvement, if any. So meanwhile I'm convinced that it's not that easy to improve this fish! But it's fun to try so, anyway. Because the code base looks very clean and it is mostly sophisticatedly documented.

[Eelco de Groot]

Also from the top of my head elsewhere in the code when we have two bishops it is assumed these are opposite coloured bishops. It is commented that it would be better to do an explicit check because one or more of these bishops might be underpromoted, so they could be of the same colour.

You probably meant this code?

endgame.cpp, line 120

Code: Select all

if (   pos.piece_count(strongerSide, QUEEN) > 0
      || pos.piece_count(strongerSide, ROOK) > 0
      || pos.piece_count(strongerSide, BISHOP) > 1)
      // TODO: check for two equal-colored bishops!
      result += VALUE_KNOWN_WIN;

Yes, that is it!

Maybe it's worth to fix it someday, although highly unlikely to occur.

That "someday" will probably be when it turns out Stockfish lost in the final round of the WCCC against Rybka, exactly because of this missing code

Btw: From watching games I think Stockfish's bishop eval is not the best. There is no "bad bishop" evaluation. I've tried to penalize positions with blocked pawns of the same square color as the bishop's square color, but there was very little Elo improvement, if any. So meanwhile I'm convinced that it's not that easy to improve this fish! But it's fun to try so, anyway. Because the code base looks very clean and it is mostly sophisticatedly documented.

I think bishop code in general is very difficult. For instance Larry Kaufman mentioned "forward mobility" of bishops in Rybka; how this is costly to compute code, but still important in elos. A bad bishop that is defending pawns of its own colour has no forward mobility anymore, if it can't leave its post. It's just a big pawn So I am sure at that point it would matter but the damage is then maybe already done. I take it you have information about blocked pawns in the dynamic evaluation Ralph? I was wondering if computing the colour of pawnsquares is costly to perform? I do believe I do something like colour detection of passed pawns and Bishops, but not for blocked pawns. And not sure I'm doing it efficiently.
Stockfish may be difficult to improve, but it is always possible! Do you have any plans for making your own version of Stockfish public Ralph

Regards, Eelco

[Ralph Stoesser]

...
I take it you have information about blocked pawns in the dynamic evaluation Ralph? I was wondering if computing the colour of pawnsquares is costly to perform? I do believe I do something like colour detection of passed pawns and Bishops, but not for blocked pawns. And not sure I'm doing it efficiently.
Stockfish may be difficult to improve, but it is always possible! Do you have any plans for making your own version of Stockfish public Ralph

Regards, Eelco

For this test I simply took all pawns (temporarily) blocked by an opponent pawn.
In pawns.cpp, PawnInfoTable::evaluate_pawns(), for every pawn I calculated

Code: Select all

bool blocked = theirPawns & file_bb(f) & rank_bb(r + (Us == WHITE ? 1 : -1))
if (blocked) 
  set_bit(&(pi->blockedPawns[Us]), s);

Maybe not that efficient, but simple to implement. Then in evaluate() pi->blockedPawns[Us] & WhiteSquaresBB is the bitboard of our white colored blocked pawns, pi->blockedPawns[Us] & BlackSquaresBB are our black colored blocked pawns.

No I don't plan to make my own version. I just fiddle around with SF code.

[Sven]

...
I take it you have information about blocked pawns in the dynamic evaluation Ralph? I was wondering if computing the colour of pawnsquares is costly to perform? I do believe I do something like colour detection of passed pawns and Bishops, but not for blocked pawns. And not sure I'm doing it efficiently.
Stockfish may be difficult to improve, but it is always possible! Do you have any plans for making your own version of Stockfish public Ralph

Regards, Eelco

For this test I simply took all pawns (temporarily) blocked by an opponent pawn.
In pawns.cpp, PawnInfoTable::evaluate_pawns(), for every pawn I calculated

Code: Select all

bool blocked = theirPawns & file_bb(f) & rank_bb(r + (Us == WHITE ? 1 : -1))
if (blocked) 
  set_bit(&(pi->blockedPawns[Us]), s);

Maybe not that efficient, but simple to implement. Then in evaluate() pi->blockedPawns[Us] & WhiteSquaresBB is the bitboard of our white colored blocked pawns, pi->blockedPawns[Us] & BlackSquaresBB are our black colored blocked pawns.

No I don't plan to make my own version. I just fiddle around with SF code.

Maybe you can calculate all blocked pawns at once, by shifting the enemy pawns BB one rank up or down depending on color and and-ing this with the friendly pawns BB.

Example, could be added to PawnInfoTable::get_pawn_info():

Code: Select all

  pi->blockedPawns[WHITE] = (blackPawns >> 8) & whitePawns;
  pi->blockedPawns[BLACK] = (whitePawns << 8) & blackPawns;

I hope I got the shift directions right, please cross-check!

Sven

[Ralph Stoesser]

Yes, Sven, this would be an obvious optimization. But since I have also tried more complicated schemes for the blocking condition, where the blockage should be of a more non-temporarily kind, I have decided to leave it in the per-pawn calculation, to be more flexible in trying out different things.

[Sven]

Yes, Sven, this would be an obvious optimization. But since I have also tried more complicated schemes for the blocking condition, where the blockage should be of a more non-temporarily kind, I have decided to leave it in the per-pawn calculation, to be more flexible in trying out different things.

Can you give an example of a non-temporary blocking condition, if it is not *too* complex?

Sven

[mcostalba]

I've tried to penalize positions with blocked pawns of the same square color as the bishop's square color, but there was very little Elo improvement, if any.

I would think that you will never find an evaluation tweak that accounts for +20 ELO and even +10 ELO is very difficult.

Increase in ELO from one release to the next is made with little steps, not big jumps. If we had opted to filter out all the "small" gain patches probably we would be still at the level of Galurung or just a little more.

We don't use a 100% reliable way to detect good changes because, when ELO increase is small (99% of cases) tipycally the error bar at the end of the test is bigger then the ELO gain. But although not 100% reliable the fundamental point is that there is a bigger then 50% of probability that the patch is good anyway (actually typically probability is more then 80%) , so adding a good number of these patches you end up with a stronger engine at the end. This is the methodology we use to handle the changes: it works in the long term and we don't need a cluster for testing.

All this words just to hint you that if you have a modification that seems good after a good number of matches at a not-superfast time control, then it surely deserves to be considered...even if it is not a +50 ELO change .....otherwise you'll easily end up looking for the holy grail forever....and after a while, frustrated, you'll give up with this computer chess stuff.