Passed Pawns (endgame)

[mcostalba]

Why use Max() here? tr can't become negative.
evaluate.cpp, line 892+893

Code: Select all

int r = int(relative_rank(Us, s) - RANK_2);
int tr = Max(0, r * (r - 1));

I don't quite follow, relative_rank(Us, s) can be == RANK_2 if the passed pawn is still on the original rank, in which case r == 0.

What did I miss

0 * -1 == 0

[Ralph Stoesser]

Not related to the thread issue, but shouldn't that be the other way round?
pawns.cpp, line 96

Code: Select all

  // Pawn storm open file bonuses by file
  const int16_t KStormOpenFileBonus[8] = { 31, 31, 18, 0, 0, 0, 0, 0 };
  const int16_t QStormOpenFileBonus[8] = { 0, 0, 0, 0, 0, 26, 42, 26 };

If we want to attack enemy king on king side it would be good to have open files f, g and h, not open files a, b and c. The same vice versa for queen side.

Code: Select all

  // Pawn storm open file bonuses by file
  const int16_t QStormOpenFileBonus[8] = { 31, 31, 18, 0, 0, 0, 0, 0 };
  const int16_t KStormOpenFileBonus[8] = { 0, 0, 0, 0, 0, 26, 42, 26 };

(A quick test with 5000 self play games @1 sec resulted in slightly positive score in favor to the switched bonuses: +1692, -1641, =1667)

[mcostalba]

Not related to the thread issue, but shouldn't that be the other way round?

hmmm I have to think a bit on this, it is not so obvious. Anyhow simply reversing the array could be suboptimal and a retuning may be necessary.

Two bugs and one candidate in few days: I have to admit you have good eye

[Eelco de Groot]

Not related to the thread issue, but shouldn't that be the other way round?
pawns.cpp, line 96

Code: Select all

  // Pawn storm open file bonuses by file
  const int16_t KStormOpenFileBonus[8] = { 31, 31, 18, 0, 0, 0, 0, 0 };
  const int16_t QStormOpenFileBonus[8] = { 0, 0, 0, 0, 0, 26, 42, 26 };

If we want to attack enemy king on king side it would be good to have open files f, g and h, not open files a, b and c. The same vice versa for queen side.

Code: Select all

  // Pawn storm open file bonuses by file
  const int16_t QStormOpenFileBonus[8] = { 31, 31, 18, 0, 0, 0, 0, 0 };
  const int16_t KStormOpenFileBonus[8] = { 0, 0, 0, 0, 0, 26, 42, 26 };

(A quick test with 5000 self play games @1 sec resulted in slightly positive score in favor to the switched bonuses: +1692, -1641, =1667)

I think you are right Ralph. If the files appear in the order { a, b, c, d, e ,f ,g, h }; then your fixed version is correct. Very good! I am glad that you have some quantative data too that this code actually works. If the bonuses were actually tuned then it could be that they are too low, tuning should have pushed them to zero?

Eelco

[Ralph Stoesser]

Thanks. Let's look at bugs from a positive point of view. SF is already very strong. The more bugs are in SF code, the easier to make SF play even stronger.

@Eelco: I'm going until 20.000 games. Let's see how it will turn out.

Another possible issue? Maybe related to the last one? Auto tuning issue? Concerning king side pawn storm we calculate a pawn lever bonus this way.
pawns.ccp, line 231

Code: Select all

int v = StormLeverBonus[f] - 2 * square_distance(s, s2);

But concerning queen side attack it is

Code: Select all

int v = StormLeverBonus[f] - 4 * square_distance(s, s2);

StormLeverBonus is a negative bonus. I would assume it is because we finally want to get rid of our stormy pawn in favor to open files for our heavy pieces. What I do not understand is this assymetry (2 vs 4).

[mcostalba]

Thanks. Let's look at bugs from a positive point of view. SF is already very strong. The more bugs are in SF code, the easier to make SF play even stronger.

@Eelco: I'm going until 20.000 games. Let's see how it will turn out.

Another possible issue? Maybe related to the last one? Auto tuning issue? Concerning king side pawn storm we calculate a pawn lever bonus this way.
pawns.ccp, line 231

Code: Select all

int v = StormLeverBonus[f] - 2 * square_distance(s, s2);

But concerning queen side attack it is

Code: Select all

int v = StormLeverBonus[f] - 4 * square_distance(s, s2);

StormLeverBonus is a negative bonus. I would assume it is because we finally want to get rid of our stormy pawn in favor to open files for our heavy pieces. What I do not understand is this assymetry (2 vs 4).

Yes assymetry is there from Glaurung times, I had already spotted that but until now I never test the symmetric version (with either 4 or 2). It is on my TODO list anyhow.

Regarding negative leverage bonus this is a puzzling result that we got from auto-tuning during 1.4 dev cycle. It was puzzling us why negative, but we found no reason. Perhaps it has to do with the reversing of the open files bouns array. In this case we should retune also the StormLeverBonus after reversing the array.

Actually tuning pawns is not easy becasue things are correlated and we have to be careful in setting initial conditions....

[Eelco de Groot]

Thanks. Let's look at bugs from a positive point of view. SF is already very strong. The more bugs are in SF code, the easier to make SF play even stronger.

@Eelco: I'm going until 20.000 games. Let's see how it will turn out.

Another possible issue? Maybe related to the last one? Auto tuning issue? Concerning king side pawn storm we calculate a pawn lever bonus this way.
pawns.ccp, line 231

Code: Select all

int v = StormLeverBonus[f] - 2 * square_distance(s, s2);

But concerning queen side attack it is

Code: Select all

int v = StormLeverBonus[f] - 4 * square_distance(s, s2);

StormLeverBonus is a negative bonus. I would assume it is because we finally want to get rid of our stormy pawn in favor to open files for our heavy pieces. What I do not understand is this assymetry (2 vs 4).

Yes assymetry is there from Glaurung times, I had already spotted that but until now I never test the symmetric version (with either 4 or 2). It is on my TODO list anyhow.

Regarding negative leverage bonus this is a puzzling result that we got from auto-tuning during 1.4 dev cycle. It was puzzling us why negative, but we found no reason. Perhaps it has to do with the reversing of the open files bouns array. In this case we should retune also the StormLeverBonus after reversing the array.

Actually tuning pawns is not easy becasue things are correlated and we have to be careful in setting initial conditions....

Hello Marco,

The StormLeverBonus being negative, if this was a tuned result could be correct, my explanation was that if the neighbouring files are half-open already, this should get a bonus. The bonus is that no negative StormLeverBonus is awarded, the

Code: Select all

while (b)

condition is false. If there are pawns then it is better to get close to them so that chances of an exchange increase.

The idea behind a bigger exchange bonus for Queen Storm Exchanges, Ralph's question, I think is mainly that the A-file, after castling long, is more vulnerable than the H-file after castling short. Because the castled white King does not cover the A-pawn unless he moves to the left (or to the right if Black). Also on that side the Queen might be slightly more active and there are four pawns storming forward really, on a, b, c and d-file at least that is what you might change, the d-pawn is at the moment not included in the pawn storm. If you exchange one pawn there are still three left to move forward.

[Ralph Stoesser]

(A quick test with 5000 self play games @1 sec resulted in slightly positive score in favor to the switched bonuses: +1692, -1641, =1667)

After 20000 games @ 1 sec: +6674, -6480, =6846
After 3686 games @ 5 sec: +1005, -934, =1747

[Eelco de Groot]

Very interesting Ralph, good results! I don't know if it is significant but the draw percentage seems to diverge. At 5 seconds I would expect slightly more draws but this would already seem a significant difference, much more than one third are draws. Maybe it is hard to find out what that means if you don't know how many games there are where the Stormbonus did not affect the outcome; because for instance same side castling or just simply bad play, noise, in the shorter time control. That makes it hard to see if there is some real difference in timecontrol.

Regards, Eelco

[mcostalba]

(A quick test with 5000 self play games @1 sec resulted in slightly positive score in favor to the switched bonuses: +1692, -1641, =1667)

After 20000 games @ 1 sec: +6674, -6480, =6846
After 3686 games @ 5 sec: +1005, -934, =1747

Thanks Ralph. I will verify the result at 1'+0" and if it is good I will commit your change as is, delaying the full re-tuning to a later time.

Patch queued up