Test Position: Rd8!!!

[rabbits]

Zlatnick ; This is the analysis by Toga 11 3.1.2ER on a slowish laptop
Al
Toga II 3.1.2SE
r1b1qr1k/1pp3pp/p3p3/n1b1PpN1/5N1P/6B1/PPP1QPP1/2KR3R w - - 0 1

Analysis by Toga II 3.1.2SE:

23.Kb1 b5 24.Nd3 Bd4 25.h5
² (0.61) Depth: 1/1 00:00:00
² (0.40) Depth: 5/12 00:00:00
23.h5 Kg8 24.h6 g6 25.Kb1 Qc6 26.b3 Be7 27.Bh4 Qc3 28.Rd3 Qb4 29.Nfxe6 Bxe6 30.Nxe6 Bxh4 31.Nxf8 Rxf8
± (1.18) Depth: 5/13 00:00:00
± (1.06) Depth: 13/41 00:00:17 7314kN
23.a3 Nc6 24.Qc4 Bb6 25.Nfxe6 Bxe6 26.Nxe6 Qf7 27.Qd5 Rfe8 28.Ng5 Qxd5 29.Rxd5 h6 30.Nf3 Rad8 31.Rhd1 Rxd5 32.Rxd5
± (1.20) Depth: 13/41 00:00:24 10141kN
± (1.35) Depth: 14/46 00:00:42 18163kN
23.Rd8 Qxd8 24.Qh5 h6 25.Qg6 hxg5 26.hxg5+ Kg8 27.Rh7 Rf7 28.Qh5 Kf8 29.Rh8+ Ke7 30.Rxd8 Kxd8 31.Qxf7 Nc6 32.Nxe6+ Bxe6 33.Qxe6 Ne7 34.Qf7 f4 35.Qf8+ Kd7 36.Qxa8 fxg3
+- (1.60) Depth: 14/46 00:00:57 24568kN
+- (5.63) Depth: 15/56 00:02:00 55262kN

[Ignacio]

Hi Swami,

Toga: 47 seconds
Deep Shredder: 73 seconds

Best,
Ignacio.

Which Toga? Toga II 1.4.2JD can't find it even after 16 minutes. Shredder 10 also doesn't find it.

I use Toga 1.4.5c and Deep Shredder 11 on my Quad.
FEN: r1b1qr1k/1pp3pp/p3p3/n1b1PpN1/5N1P/6B1/PPP1QPP1/2KR3R w - - 0 1

TogaII14-5c-4cpu:

13/37 00:01 831.903 0 +1,25 h4h5 Kh8g8 h5h6 g7g6 a2a3 Bc5a7 Rd1d3 Na5c6 a3a4 Ba7d4
13/51 00:01 1.027.578 3.313.609 +1,42 a2a3 Bc5b6 h4h5 Kh8g8 h5h6 g7g6 Kc1b1 Na5c6 Ng5f3 Rf8f7 Qe2c4 Kg8h8
14/37 00:02 1.636.529 3.240.520 +1,35 a2a3 Bc5b6 h4h5 Kh8g8 h5h6 g7g6 Kc1b1 Kg8h8 Qe2d2 Na5c6 Qd2e1 Bb6d4
14/37 00:02 1.565.130 3.240.520 +1,36 a2a3 Bc5b6 h4h5 Kh8g8 h5h6 g7g6 Kc1b1 Kg8h8 Bg3h4 Bb6c5 Ng5f3 Qe8a4
15/42 00:04 3.187.430 3.326.759 +1,42 a2a3 Bc5b6 h4h5 Kh8g8 h5h6 g7g6 Kc1b1 Na5c6 Ng5f3 a6a5 Bg3h4 a5a4 Bh4f6 Bc8d7 Nf3g5
16/51 00:07 5.803.708 3.386.870 +1,41 a2a3 Bc5b6 h4h5 Kh8g8 h5h6 g7g6 Kc1b1 Bc8d7 a3a4 Ra8d8 Rd1xd7 Qe8xd7 Nf4xe6 Qd7xa4 Ne6xf8 Rd8xf8 Ng5e6
17/45 00:24 20.464.104 3.414.801 +1,27 a2a3 Bc5b6 h4h5 Kh8g8 h5h6 g7g6 Kc1b1 Bc8d7 Qe2f3 Ra8b8 Rd1xd7 Qe8xd7 Nf4xe6 Rf8c8 Rh1d1
17/62 00:49 42.918.752 3.333.333 +9,79 Rd1d8 Bc8d7 Rd8xe8 Bd7xe8 Nf4xe6 Bc5e7 Ne6xf8 Be7xf8 Qe2f3 g7g6 e5e6 Na5c6 Bg3xc7 Bf8g7 Qf3b3 b7b5 Rh1d1 h7h6 Ng5f7+ Kh8h7 Qb3d5 Bg7f6
17/70 02:32 131.826.266 3.466.612 +10,88 Rd1d8 Bc8d7 Rd8xa8 Bd7b5 Ra8xe8 Bb5xe2 Re8xf8+ Bc5xf8 Nf4xe2 Kh8g8 Ng5xe6 c7c5 Rh1d1 Bf8e7 Rd1d7 Kg8f7 Ne6xg7 Na5c6 Ng7h5 b7b6
17/68 02:32 143.233.567 3.468.588 +10,97 Rd1d8 Bc8d7 Rd8xa8 Bd7b5 Ra8xe8 Bb5xe2 Re8xf8+ Bc5xf8 Nf4xe2 Kh8g8 Ng5xe6 c7c5 Rh1d1 Bf8e7 Rd1d7 Kg8f7 Ne6xg7 Na5c6 Ng7h5 b7b6 Nh5f6 h7h6
18/70 03:45 201.320.949 3.579.910 +10,79 Rd1d8 Bc8d7 Rd8xa8 Bd7b5 Ra8xe8 Bb5xe2 Re8xf8+ Bc5xf8 Nf4xe2 Kh8g8 Ng5xe6 c7c5 Rh1d1 Bf8e7 Rd1d7 Kg8f7 Ne6xg7 Na5c6 Ng7h5 b7b6 Bg3f4 h7h6
18/62 05:15 271.453.489 3.661.490 +12,56 Rd1d8 Bc8d7 Rd8xa8 Bd7b5 Qe2d1 Rf8g8 Ra8xe8 Bb5xe8 Nf4xe6 Bc5e7 Ne6xc7 Be8g6 Qd1d5 Na5c6 Nc7xa6 Rg8d8 Qd5e6

[Eelco de Groot]

Maybe Tord could also take a look at this line at the very end of evaluate(), I can't figure out the original one, I replaced it with:

Code: Select all

  // Interpolate between the middle game and the endgame score, and
  // return:
  Value value = scale_by_game_phase(ei.mgValue, ei.egValue, phase, factor);

  if(ei.mateThreat[stm] != MOVE_NONE)
    return Sign[stm] * (2 * QueenValueMidgame +  value);
  else
    return Sign[stm] * value;
}

but am not sure yet this is anywhere correct or better..

No, that's wrong. The evaluation function returns scores from the point of the side to move. In the code above, the variable "value" contains a score from white's point of view, and Sign[] is a two-element array holding the values +1 and -1 for white and black.

If ei.mateThreat[stm] is different from MOVE_NONE, it means that the side to move has a mating move. In this case we want to return a good score. When you multiply with Sign[stm], like you do, you'll return a good score if it's white to move and an immediate mate, but at bad score if it's black to move and an immediate mate. If the program plays black, it will try to avoid positions where it has a mate in one. If it plays white, it will try to get positions where the opponent has a mate in one. Needless to say, this is probably not what you want.

Here is the original code, which as far as I can see is entirely correct:

Code: Select all

  // Interpolate between the middle game and the endgame score, and
  // return:
  Value value = scale_by_game_phase(ei.mgValue, ei.egValue, phase, factor);

  if(ei.mateThreat[stm] != MOVE_NONE)
    return 8 * QueenValueMidgame - Sign[stm] * value;
  else
    return Sign[stm] * value;

Notice that when the side to move has a mating move, I return a huge positive score. It's perhaps confusing that I subtract Sign[stm] * value. I could just have removed this, and just returned 8 * QueenValueMidgame. The effect of subtracting Sign[stm] * value is that the program will prefer bad-looking positions where it has a mate in one over good-looking positions where it has a mate in one. As a consequence, when there is a choice of two lines which both leads to a forced mate, the program will prefer the one where the biggest amount of material is sacrificed. It has no effect on the strength, it just gives slightly more flashy play.

This is probably just confusing, so I'll simplify things and just return 8*QueenValueMidgame in the next version.

Tord

Hi Tord,

Thanks very much for your accurate explanations. I had some trouble visualizing it, but you must be right. Only I think that for instance for your factor of eight times QueenValueMidgame, maybe you could do some testing in tactical positions if this is not too much, because the assumption that it really does not matter for the playing strength which mate sequence is chosen may not be entirely correct. The only reason why with my Build 7 the solution was found two plies earlier appears to be my faulty implementation of the code! Even in the position with reversed colours, Black to move and, if White answers Qxd8 there is actually somewhere a forced mate sequence for Black that is now evaluated negatively with two Queen values instead of positively, the result is still better than with a corrected version! Solution on plydepth 17 instead of eighteen and the variation after 1... c6 with 2. Nc3 is actually the best reply this time for White on deeper analysis, it may be total coincidence but still..

The only explanation I can come up with is that it may basically be another instance of the "sceptical engine" at work, Fabien's ideas; most direct mate sequences that you find are likely too good to be true and will be refuted earlier in the tree when the other side will choose another continuation to avoid the mate, so you might as well give the mate a very negative evaluation right away first and look for other moves first...? I know this sounds rather paradoxical and I am trying to find out if there is a way that you could actually use this or at least test it better.

It is either this explanation or I must have introduced other sign based bugs elsewhere that are somehow affecting the result or are negated by this one...

Thanks for the explanation!
Regards, Eelco

Result with Build 7 in position with reversed colours:

[d]2kr3r/ppp1qpp1/6b1/5n1p/N1B1pPn1/P3P3/1PP3PP/R1B1QR1K b - -

Engine: Ancalagon 2.0 Beta 001 (Athlon 2009 MHz, 256 MB)
by Tord Romstad, Eelco de Groot

8.00 0:00 +2.68 1...h4 2.h3 Ng3+ 3.Kg1 Nf6 4.Qa5 Kb8
5.Re1 Qd7 (63.512) 162

9.00 0:00 +1.70 1...h4 2.h3 Ng3+ 3.Kg1 Qd7 4.Nc5 Qc6
5.b4 Qf6 6.hxg4 Qxa1 (113.146) 226

10.00 0:00 +1.64 1...h4 2.h3 Ng3+ 3.Kg1 Nxf1 4.Bxf1 Nf6
5.Qa5 a6 6.Nc5 Nd7 7.Na4 (286.555) 316

10.06 0:01 +2.15 1...c6 2.Nc3 h4 3.h3 Ng3+ 4.Kg1 Nxf1
5.Qxf1 Nf6 6.f5 Bh5 7.b4 (478.192) 356

11.01 0:01 +2.27 1...c6 2.Ba2 h4 3.h3 Ng3+ 4.Kg1 Nxf1
5.Qxf1 Nf6 6.b4 Kb8 7.Bb2 Qd6 (737.885) 380

12.01 0:02 +2.25 1...c6 2.Ba2 h4 3.h3 Ng3+ 4.Kg1 Nxf1
5.Qxf1 Nf6 6.b4 Qd7 7.Bb2 Qd2 8.Qf2 Qxf2+
9.Kxf2 (1.154.129) 394

13.01 0:04 +2.03 1...c6 2.Ba2 h4 3.h3 Ng3+ 4.Kg1 Nxf1
5.Kxf1 Nf6 6.b4 Kb8 7.Bb2 Rh5 8.Nc5 Qd6 (2.001.798) 408

14.01 0:17 +2.17 1...c6 2.Ba2 h4 3.h3 Ng3+ 4.Kg1 Nxf1
5.Kxf1 Nf6 6.Bd2 c5 7.Ba5 b6 8.Bc3 b5
9.Bxf6 Qxf6 10.Nxc5 Qxb2 (7.276.893) 415

15.01 0:37 +2.37 1...c6 2.Nc3 h4 3.h3 Ng3+ 4.Kg1 Nf6
5.Rf2 Qc5 6.Ba2 Bh5 7.f5 Kb8 8.Rf4 Qd6
9.Bc4 (16.148.044) 425

16.01 0:57 +2.37 1...c6 2.Nc3 h4 3.h3 Ng3+ 4.Kg1 Nxf1
5.Qxf1 Nf6 6.b4 Bf5 7.Qe1 Kb8 8.Bb2 Be6
9.Be2 Qc7 10.Rd1 Rxd1 11.Qxd1 (24.735.226) 431

17.01 1:32 +2.37 1...c6 2.Nc3 h4 3.h3 Ng3+ 4.Kg1 Nxf1
5.Qxf1 Nf6 6.b4 Bf5 7.Qe1 Kb8 8.Bb2 Be6
9.Be2 Qc7 10.Rd1 Rxd1 11.Qxd1 (40.107.324) 435

17.10 6:07 +18.56 1...Rd1 2.Bd2 Rxa1 3.Nc3 Rxe1 4.Bxe1 Nfxe3
5.Nd5 Nxd5 6.Bxd5 Qc5 7.Bb3 e3 8.Rf3 Be4
9.Bxf7 Bxf3 10.gxf3 Qc6 11.Be6+ Qxe6
12.fxg4 Qxg4 (159.392.651) 433

18.01 7:48 +18.72 1...Rd1 2.Bd2 Rxa1 3.Nc3 Rxe1 4.Bxe1 Nfxe3
5.Nd5 Nxd5 6.Bxd5 Qc5 7.Bb3 e3 8.Rf3 Be4
9.Bxf7 Bxf3 10.gxf3 Qc6 11.Kg1 Qxf3
12.Be6+ Kd8 13.Bh4+ Ke8 14.Bxg4 Qxg4+ (204.294.284) 435

19.01 14:18 +19.96 1...Rd1 2.Bd2 Rxa1 3.Nc3 Rxe1 4.Bxe1 Nfxe3
5.Nd5 Qc5 6.Nxe3 Nxe3 7.Be6+ fxe6
8.Bf2 Qc4 9.Rc1 Qe2 10.Bxe3 Qxe3
11.Rf1 Qd2 12.b4 e3 13.c4 (381.052.756) 443

20.01 36:14 +21.21 1...Rd1 2.Bd2 Rxa1 3.Nc3 Rxe1 4.Bxe1 Nfxe3
5.Nd5 Qc5 6.Nxe3 Nxe3 7.Be6+ fxe6
8.Bf2 Qc4 9.Rc1 Qe2 10.Bxe3 Qxe3
11.Ra1 Qxf4 12.c4 Qd2 13.b3 e3 (958.711.197) 440

best move: Rd8-d1 time: 65:27.234 min n/s: 438.534 nodes: 1.722.180.000

Analysis of three best replies after 1.c3 in original position with Build 8 (the corrected version):

Code: Select all

  // Interpolate between the middle game and the endgame score, and
  // return:
  Value value = scale_by_game_phase(ei.mgValue, ei.egValue, phase, factor);

  if(ei.mateThreat[stm] != MOVE_NONE)
    return  2 * QueenValueMidgame + Sign[stm] * value);
  else
    return Sign[stm] * value;
}

21 159:38 -2.37 1...Nc6 2.h5 h6 3.Ng6+ Kg8 4.Nxf8 Bxf8
5.Nh3 Bd7 6.Nf4 Na5 7.b3 Bc6 8.f3 Be7
9.Ng6 Rd8 10.Kb1 Rxd1+ 11.Rxd1 Bg5
12.Bf4 Bb5 13.c4 (4.154.041.448) 433

21 159:38 -3.05 1...Kg8 2.b4 b6 3.bxa5 h6 4.Kb1 bxa5
5.Nf3 Rb8+ 6.Ka1 Qa4 7.Rb1 Bd7
8.Qxa6 Bxf2 9.Bxf2 Qxf4 10.Bc5 Rfc8
11.Qxa5 Qa4 12.Qxa4 Bxa4 13.h5 Rxb1+
14.Kxb1 (4.154.041.448) 433

21 159:38 -3.15 1...Be7 2.Kb1 Rg8 3.Nfxe6 Bxe6
4.Nxe6 Qg6 5.Nxc7 f4+ 6.Qc2 Qxc2+
7.Kxc2 fxg3 8.Nxa8 Rxa8 9.Rd7 Re8
10.fxg3 Nc4 11.Re1 Bc5 12.Rxb7 Kg8
13.b4 Be3 14.Rc7 (4.154.041.448) 433

[Eelco de Groot]

The only explanation I can come up with is that it may basically be another instance of the "sceptical engine" at work, Fabien's ideas; most direct mate sequences that you find are likely too good to be true and will be refuted earlier in the tree when the other side will choose another continuation to avoid the mate, so you might as well give the mate a very negative evaluation right away first and look for other moves first...? I know this sounds rather paradoxical and I am trying to find out if there is a way that you could actually use this or at least test it better.

Thinking about it some more this does not make much sense at all in alpha-beta, but in that case I do not really have an explanation for what I was seeing Sorry, it must be some bug I think, probably mine, but maybe there really is a way of using this effect

Eelco

[Tord Romstad]

Hi Eelco!

Thanks very much for your accurate explanations. I had some trouble visualizing it, but you must be right. Only I think that for instance for your factor of eight times QueenValueMidgame, maybe you could do some testing in tactical positions if this is not too much, because the assumption that it really does not matter for the playing strength which mate sequence is chosen may not be entirely correct.

No need to test anything, eight times QueenValueMidgame isn't too much. Giving checkmate is better than any material advantage. I could have returned a mate score from the evaluation function; the only reason I don't do so is that the evaluation function doesn't know the distance from the root, and therefore don't know the number of moves to mate. I therefore just return a value which is smaller than a mate, but bigger than any material value you are ever likely to see in a game.

The only reason why with my Build 7 the solution was found two plies earlier appears to be my faulty implementation of the code!

Nothing unusual about that. Any change in the code, good or bad, will always cause the best move to be found earlier in some positions.

The only explanation I can come up with is that it may basically be another instance of the "sceptical engine" at work, Fabien's ideas; most direct mate sequences that you find are likely too good to be true and will be refuted earlier in the tree when the other side will choose another continuation to avoid the mate, so you might as well give the mate a very negative evaluation right away first and look for other moves first...? I know this sounds rather paradoxical and I am trying to find out if there is a way that you could actually use this or at least test it better.

You seem to somehow be confused about how the search and evaluation in a chess program interact. The role of the evaluation function is to give the best possible static estimate of how good the position is for the side to move, nothing more. It does not consider how likely it is that the position will actually appear in the game (the evaluation function has absolutely no way of guessing this probability, and even if it did, it wouldn't have any interesting ways to use it). Reducing the evaluation score for one of the exceptional positions where you are 100% sure that the side to move is winning because this position is perhaps not likely to appear in the game makes no sense whatsoever.

Because I'm not sure exactly what you are confused about, I'm afraid I can't explain it any better at the moment...

It is either this explanation or I must have introduced other sign based bugs elsewhere that are somehow affecting the result or are negated by this one...

There is no need to look for any explanation at all. There's nothing unusual or unexpected here.

Tord