Kamsky-Yussupow, Tilburg 1992

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Rebel, chrisw

jdart
Posts: 4367
Joined: Fri Mar 10, 2006 5:23 am
Location: http://www.arasanchess.org

Kamsky-Yussupow, Tilburg 1992

Post by jdart »

This one is fairly easy but interesting. Some versions of Arasan get this rapidly, some don't:

[D] 8/8/R7/1pPpk2r/8/2PK1P2/8/8 w - -

bm f4+!.

--Jon
User avatar
Eelco de Groot
Posts: 4567
Joined: Sun Mar 12, 2006 2:40 am
Full name:   

Re: Kamsky-Yussupow, Tilburg 1992

Post by Eelco de Groot »

jdart wrote:This one is fairly easy but interesting. Some versions of Arasan get this rapidly, some don't:

[D] 8/8/R7/1pPpk2r/8/2PK1P2/8/8 w - -

bm f4+!.

--Jon
I'm starting over with a new version of Ancalagon 2.0, I had gotten as far as Build 108 all based on Tord's Glaurung 2.1, that code of Build 108 is the basis for a new version but I'm hoping to put some of the old Glaurung 080422 in it too and some of my own changes I hope to remove: so the new version is called Ancalagon 1.08 Beta. This is the very first output of the Beta, Build 1, it has still ridiculous scores for Passed Pawns so all the evals should be ignored I think.

Ancalagon 2.0 was still playing without promise, where at least some of the older 080422 versions could put up a fight sometimes against Naum, Ancalagon 2.0 had yet to win a single game. So I think something had gone wrong and too many changes were untested. Unfortunately only one of the Glaurung 080422 Mjolnir sources is kept so the code basis is a bit small. Anyway it would be impossible to backtrack all the changes certainly without some testing scheme. Plan B is just to start somewhere :) I'm starting somewhere in the middle; I'm throwing in the kettle some code of both Ancalagon Build 108 and Build 56 of Glaurung 080422 Mjolnir and see what Microsofts wizards and druids make of this brew.


[D]8/8/R7/1pPpk2r/8/2PK1P2/8/8 w - -

Engine: Ancalagon 1.08 Beta Build 1 (256 MB)
by Tord Romstad, Eelco de Groot

2.00 0:00 +11.03 1.c6 Kd6 (107) 0

3.00 0:00 +3.29 1.c6 Kd6 2.f4 Kc7 (371) 1

3.00 0:00 +11.90 1.f4+ Kxf4 2.c6 Ke5 (624) 1

4.00 0:00 +11.62 1.f4+ Kxf4 2.c6 Rh7 3.Kd4 (1.334) 4

5.00 0:00 +12.27 1.f4+ Kxf4 2.c6 Rh7 3.Kd4 Kf5 4.Kxd5 (2.855) 9

6.00 0:00 +12.27 1.f4+ Kxf4 2.c6 Rh7 3.Kd4 Kf5 4.Kxd5 (5.928) 18

7.00 0:00 +9.86 1.f4+ Kxf4 2.c6 Rh7 3.Kd2 Ke5 4.Ke3 Kd6 (10.893) 33

7.00 0:00 +10.60 1.Rg6 Rh3 2.c6 Rxf3+ 3.Kd2 Rf7 4.Ke3 Rc7 (26.477) 73

8.00 0:00 +9.74 1.Rg6 Rh3 2.c6 Rxf3+ 3.Kc2 Rf7 4.Kb3 Rc7
5.Kb4 (36.670) 93

9.00 0:00 +10.37 1.Rg6 Kf5 2.Rd6 Ke5 3.f4+ Kxf4 4.c6 Ke5
5.Rg6 Rh3+ 6.Kd2 (93.850) 193

10.00 0:00 +8.74 1.Rg6 Rh3 2.Ke3 Kf5 3.Rb6 Ke5 4.Rxb5 Rh6
5.Rb6 Rh4 (183.330) 279

11.00 0:01 +7.54 1.Rg6 Rh4 2.c6 Rc4 3.Rh6 d4 4.f4+ Kd5
5.f5 dxc3 6.Kc2 Rxc6 7.Rxc6 Kxc6
8.f6 (438.226) 389

12.01 0:01 +6.94 1.Rg6 Rh4 2.c6 Rc4 3.Rh6 Kf5 4.Kd2 Rxc6
5.Rxc6 Kf4 6.Rc5 Kxf3 7.Rxd5 (940.697) 474

12.02 0:02 +7.19 1.f4+ Kxf4 2.c6 Kf5 3.c7 Rh8 4.Kd4 Rc8
5.Ra7 Rxc7 6.Rxc7 Ke6 7.Rc5 Ke7
8.Rxd5 (1.253.490) 511

13.01 0:03 +7.07 1.f4+ Kxf4 2.c6 Kf5 3.c7 Rh8 4.Kd4 Rc8
5.Rc6 Kg5 6.Ke5 Rxc7 7.Rxc7 d4
8.Kxd4 Kf6 (1.923.609) 539

14.01 0:07 +6.70 1.f4+ Kxf4 2.c6 Ke5 3.c7 Rh8 4.Rb6 Rc8
5.Rc6 Rxc7 6.Rxc7 Kd6 7.Rc8 Ke6
8.Rc5 Ke5 9.Rxb5 (4.373.667) 575

15.01 0:15 +6.70 1.f4+ Kxf4 2.Kd4 Kf5 3.Kxd5 Rh3 4.c6 Rxc3
5.Kd6 b4 6.c7 Rd3+ 7.Kc6 Rc3+ 8.Kd7 b3
9.Ra5+ Kf6 10.Rb5 Rd3+ 11.Kc6 Rc3+
12.Kb7 (8.876.934) 591

16.01 0:24 +8.45 1.f4+ Kxf4 2.Kd4 Kf5 3.Rb6 Rh3 4.Rd6 Rh4+
5.Kxd5 Rh3 6.Kc6 Ke5 7.Kxb5 Rh8
8.Rb6 Rh7 9.c4 Rc7 (14.281.691) 593

17.01 0:36 +9.17 1.f4+ Kxf4 2.Kd4 Kf5 3.Rd6 Rh4+
4.Kxd5 Rh3 5.Kc6 Ke5 6.Kxb5 Rh7
7.Kb6 Rh2 8.Rg6 Rb2+ 9.Kc7 Kf5 10.c6 Kxg6
11.Kc8 (21.612.796) 597

18.01 0:51 +10.13 1.f4+ Kxf4 2.Kd4 Kf5 3.Rd6 Rh4+
4.Kxd5 Rh3 5.Kc6 Ke5 6.Kxb5 Rh8
7.Kb6 Rb8+ 8.Kc7 Ra8 9.Rg6 Kf5 10.c6 Kxg6
11.Kb7 Re8 (31.172.411) 602


best move: f3-f4 time: 0:54.500 min n/s: 600.650 nodes: 32.670.000

High evals are to be ignored here...
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan
User avatar
Eelco de Groot
Posts: 4567
Joined: Sun Mar 12, 2006 2:40 am
Full name:   

Re: Kamsky-Yussupow, Tilburg 1992

Post by Eelco de Groot »

jdart wrote:This one is fairly easy but interesting. Some versions of Arasan get this rapidly, some don't:

[D] 8/8/R7/1pPpk2r/8/2PK1P2/8/8 w - -

bm f4+!.

--Jon
I'm starting over with a new version of Ancalagon 2.0, I had gotten as far as Build 108 all based on Tord's Glaurung 2.1, that code of Build 108 is the basis for a new version but I'm hoping to put some of the old Glaurung 080422 in it too and some of my own changes I hope to remove: so the new version is called Ancalagon 1.08 Beta. This is the very first output of the Beta, Build 1, it has still ridiculous scores for Passed Pawns so all the evals should be ignored I think.

Ancalagon 2.0 was still playing without promise, where at least some of the older 080422 versions could put up a fight sometimes against Naum, Ancalagon 2.0 had yet to win a single game. So I think something had gone wrong and too many changes were untested. Unfortunately only one of the Glaurung 080422 Mjolnir sources is kept so the code basis is a bit small. Anyway it would be impossible to backtrack all the changes certainly without some testing scheme. Plan B is just to start somewhere :) I'm starting somewhere in the middle; I'm throwing in the kettle some code of both Ancalagon Build 108 and Build 56 of Glaurung 080422 Mjolnir and see what Microsofts wizards and druids make of this brew.


[D]8/8/R7/1pPpk2r/8/2PK1P2/8/8 w - -

Engine: Ancalagon 1.08 Beta Build 1 (256 MB)
by Tord Romstad, Eelco de Groot

2.00 0:00 +11.03 1.c6 Kd6 (107) 0

3.00 0:00 +3.29 1.c6 Kd6 2.f4 Kc7 (371) 1

3.00 0:00 +11.90 1.f4+ Kxf4 2.c6 Ke5 (624) 1

4.00 0:00 +11.62 1.f4+ Kxf4 2.c6 Rh7 3.Kd4 (1.334) 4

5.00 0:00 +12.27 1.f4+ Kxf4 2.c6 Rh7 3.Kd4 Kf5 4.Kxd5 (2.855) 9

6.00 0:00 +12.27 1.f4+ Kxf4 2.c6 Rh7 3.Kd4 Kf5 4.Kxd5 (5.928) 18

7.00 0:00 +9.86 1.f4+ Kxf4 2.c6 Rh7 3.Kd2 Ke5 4.Ke3 Kd6 (10.893) 33

7.00 0:00 +10.60 1.Rg6 Rh3 2.c6 Rxf3+ 3.Kd2 Rf7 4.Ke3 Rc7 (26.477) 73

8.00 0:00 +9.74 1.Rg6 Rh3 2.c6 Rxf3+ 3.Kc2 Rf7 4.Kb3 Rc7
5.Kb4 (36.670) 93

9.00 0:00 +10.37 1.Rg6 Kf5 2.Rd6 Ke5 3.f4+ Kxf4 4.c6 Ke5
5.Rg6 Rh3+ 6.Kd2 (93.850) 193

10.00 0:00 +8.74 1.Rg6 Rh3 2.Ke3 Kf5 3.Rb6 Ke5 4.Rxb5 Rh6
5.Rb6 Rh4 (183.330) 279

11.00 0:01 +7.54 1.Rg6 Rh4 2.c6 Rc4 3.Rh6 d4 4.f4+ Kd5
5.f5 dxc3 6.Kc2 Rxc6 7.Rxc6 Kxc6
8.f6 (438.226) 389

12.01 0:01 +6.94 1.Rg6 Rh4 2.c6 Rc4 3.Rh6 Kf5 4.Kd2 Rxc6
5.Rxc6 Kf4 6.Rc5 Kxf3 7.Rxd5 (940.697) 474

12.02 0:02 +7.19 1.f4+ Kxf4 2.c6 Kf5 3.c7 Rh8 4.Kd4 Rc8
5.Ra7 Rxc7 6.Rxc7 Ke6 7.Rc5 Ke7
8.Rxd5 (1.253.490) 511

13.01 0:03 +7.07 1.f4+ Kxf4 2.c6 Kf5 3.c7 Rh8 4.Kd4 Rc8
5.Rc6 Kg5 6.Ke5 Rxc7 7.Rxc7 d4
8.Kxd4 Kf6 (1.923.609) 539

14.01 0:07 +6.70 1.f4+ Kxf4 2.c6 Ke5 3.c7 Rh8 4.Rb6 Rc8
5.Rc6 Rxc7 6.Rxc7 Kd6 7.Rc8 Ke6
8.Rc5 Ke5 9.Rxb5 (4.373.667) 575

15.01 0:15 +6.70 1.f4+ Kxf4 2.Kd4 Kf5 3.Kxd5 Rh3 4.c6 Rxc3
5.Kd6 b4 6.c7 Rd3+ 7.Kc6 Rc3+ 8.Kd7 b3
9.Ra5+ Kf6 10.Rb5 Rd3+ 11.Kc6 Rc3+
12.Kb7 (8.876.934) 591

16.01 0:24 +8.45 1.f4+ Kxf4 2.Kd4 Kf5 3.Rb6 Rh3 4.Rd6 Rh4+
5.Kxd5 Rh3 6.Kc6 Ke5 7.Kxb5 Rh8
8.Rb6 Rh7 9.c4 Rc7 (14.281.691) 593

17.01 0:36 +9.17 1.f4+ Kxf4 2.Kd4 Kf5 3.Rd6 Rh4+
4.Kxd5 Rh3 5.Kc6 Ke5 6.Kxb5 Rh7
7.Kb6 Rh2 8.Rg6 Rb2+ 9.Kc7 Kf5 10.c6 Kxg6
11.Kc8 (21.612.796) 597

18.01 0:51 +10.13 1.f4+ Kxf4 2.Kd4 Kf5 3.Rd6 Rh4+
4.Kxd5 Rh3 5.Kc6 Ke5 6.Kxb5 Rh8
7.Kb6 Rb8+ 8.Kc7 Ra8 9.Rg6 Kf5 10.c6 Kxg6
11.Kb7 Re8 (31.172.411) 602


best move: f3-f4 time: 0:54.500 min n/s: 600.650 nodes: 32.670.000

High evals are to be ignored here...
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan
Harald Johnsen

Re: Kamsky-Yussupow, Tilburg 1992

Post by Harald Johnsen »

18.01 0:51 +10.13 1.f4+ Kxf4 2.Kd4 Kf5 3.Rd6 Rh4+
4.Kxd5 Rh3 5.Kc6 Ke5 6.Kxb5 Rh8
7.Kb6 Rb8+ 8.Kc7 Ra8 9.Rg6 Kf5 10.c6 Kxg6
11.Kb7 Re8 (31.172.411) 602
Did i incorrectly copied the pv ?

[D] 4r3/1K6/2P3k1/8/8/2P5/8/8 w - - 2 12

This is a draw by table bases.

HJ.
User avatar
Eelco de Groot
Posts: 4567
Joined: Sun Mar 12, 2006 2:40 am
Full name:   

Re: Kamsky-Yussupow, Tilburg 1992

Post by Eelco de Groot »

Harald Johnsen wrote:
18.01 0:51 +10.13 1.f4+ Kxf4 2.Kd4 Kf5 3.Rd6 Rh4+
4.Kxd5 Rh3 5.Kc6 Ke5 6.Kxb5 Rh8
7.Kb6 Rb8+ 8.Kc7 Ra8 9.Rg6 Kf5 10.c6 Kxg6
11.Kb7 Re8 (31.172.411) 602
Did i incorrectly copied the pv ?

[D] 4r3/1K6/2P3k1/8/8/2P5/8/8 w - - 2 12

This is a draw by table bases.

HJ.
Harald thanks, it is a draw you are right! :oops: Glaurung 2.1 and Naum 3.1 which I checked the position with see that immediately. What is happening I think is that in an attempt to let the program know more about "outside passers" there are some changes made, but they backfire in practically all Rook endgames I think and there are a lot of those.

Glaurung already understood the rules for the enemy King being "in the quadrant" in elementary endgames where it can stop a passed pawn. It also gets a bonus for a King that can support a passed pawn by being close to it and a penalty for the enemy King being close, but I figured sometimes the King does not have to be close as long as it is inside the square, here formed by the pawn and queening square c6-c8-a6-a8 on the left, or c6-c8-e6-e8 on the right, important for the enemy queen. The enemy queen is outside the square and gets a big penalty (way too big but that does not even matter much), the own King is inside the square and gets a big bonus. However the old bonuses for supporting the pawn are also still present and the Rook is only taken into account once for attacking square c8, without looking at what type of piece it is and if it is opposed in any way by White pieces, or for example having to defend several queening squares. There it goes wrong...

That is what makes accurate detection of promising passed pawns so difficult I reckon, you have to look at the whole board and since it is so important, almost all features of the board in theory have to be taken into account, because an almost promoted pawn can decide the game instantly.

This is some of the code that was at work, lots about Kings but nothing about Rooks:

Code: Select all


  // evaluate_passed_pawns() evaluates the passed pawns for both sides.

  void evaluate_passed_pawns(const Position &pos, EvalInfo &ei) {
    bool hasUnstoppable[2] = {false, false};
    int movesToGo[2] = {100, 100};
    int blockerCount, attackedsquareCount, defendedsquareCount;
    int malus, gote;
    // Phase phase;

    for&#40;Color us = WHITE; us <= BLACK; us++) &#123;
      Color them = opposite_color&#40;us&#41;;
      Square ourKingSq = pos.king_square&#40;us&#41;;
      Square theirKingSq = pos.king_square&#40;them&#41;;
      Bitboard b = ei.pi->passed_pawns&#40;) & pos.pawns&#40;us&#41;, b2, b3, b4;
      Bitboard b_outpost = ei.pi->outpost_pawns&#40;) & pos.pawns&#40;us&#41; & ~ei.pi->passed_pawns&#40;);
      gote = (&#40;us == pos.side_to_move&#40;))? 0 &#58; 1&#41;;

      while&#40;b&#41; &#123;
        Square s = pop_1st_bit&#40;&b&#41;;
        assert&#40;pos.piece_on&#40;s&#41; == pawn_of_color&#40;us&#41;);
        assert&#40;pos.pawn_is_passed&#40;us, s&#41;);

        int r = int&#40;pawn_rank&#40;us, s&#41; - RANK_2&#41;;
        int tr = Max&#40;0, r * &#40;r-1&#41;);
        Square blockSq = s + pawn_push&#40;us&#41;;

        // Base bonus based on rank&#58;
        Value mbonus = Value&#40;20 * tr&#41;;
        Value ebonus = Value&#40;r * r * 25&#41;;
        // &#91;EdG&#58; Edge pawns are maybe less likely to promote, control fewer squares&#58;&#93;
		if &#40;square_file&#40;s&#41; == FILE_A || square_file&#40;s&#41; == FILE_H&#41; &#123;
			mbonus -= Value&#40;30&#41;;
			ebonus -= Value&#40;10&#41;;
		&#125;

         Square qsq;
         Value quadrant_them;
		   Value quadrant_relative_us;
         Value quadrant_us_bonus_mid;
         Value quadrant_them_bonus_mid;
         Value quadrant_us_bonus_end;
         Value quadrant_them_bonus_end;

         qsq = relative_square&#40;us, make_square&#40;square_file&#40;s&#41;, RANK_8&#41;);
         quadrant_them = Value&#40;square_distance&#40;theirKingSq, qsq&#41;
			 - square_distance&#40;s, qsq&#41; - gote&#41;;
         quadrant_relative_us = Value&#40;(&#40;quadrant_them >= 0&#41;? 40 &#58; 10&#41;
			 - square_distance&#40;ourKingSq, qsq&#41; + square_distance&#40;s, qsq&#41; - gote&#41;;

        // Adjust bonus based on king proximity&#58;
        ebonus -= Value&#40;square_distance&#40;ourKingSq, blockSq&#41; * 3 * tr&#41;;
        ebonus -=
          Value&#40;square_distance&#40;ourKingSq, blockSq + pawn_push&#40;us&#41;) * 1 * tr&#41;;
        ebonus += Value&#40;square_distance&#40;theirKingSq, blockSq&#41; * 6 * tr&#41;;

        //quadrant_us_bonus_mid = Value&#40;quadrant_relative_us * 2 * tr&#41;;
        //mbonus += quadrant_us_bonus_mid;
        //quadrant_them_bonus_mid = Value&#40;quadrant_them * 3 * tr&#41;;
		  //mbonus += quadrant_them_bonus_mid;
        quadrant_us_bonus_end = Value&#40;quadrant_relative_us * 3 * r * r&#41;;
        ebonus += quadrant_us_bonus_end;
        quadrant_them_bonus_end = Value&#40;quadrant_them * 10 * r * r&#41;;
        ebonus += quadrant_them_bonus_end;
.
.
.


Just to give you an idea where the big bonuses were coming from, and no tablebases to correct it. An enemy Rook controlling qsq and a big material plus for Black might be a way to scale the bonuses a bit :oops:

Eelco
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan
swami
Posts: 6640
Joined: Thu Mar 09, 2006 4:21 am

Re: Kamsky-Yussupow, Tilburg 1992

Post by swami »

Bright @ Q6600.

Time: 1 Second

New game
8/8/R7/1pPpk2r/8/2PK1P2/8/8 w - - 0 1

Analysis by bright-0.3a:
1.Rg6
+/- (0.86) Depth: 1/1 00:00:00
1.Rg6
+/- (0.86) Depth: 1/1 00:00:00
1.Rg6
+/- (0.86) Depth: 1/1 00:00:00
1.c6
+/- (1.35) Depth: 1/1 00:00:00
1.c6 Rh7 2.Ra8
+/- (1.21) Depth: 2/8 00:00:00
1.c6 Rh7 2.Ra8
+/- (1.21) Depth: 3/8 00:00:00
1.c6 Rh7 2.Ke3 Rf7 3.Ra8
+/- (1.33) Depth: 4/12 00:00:00
1.Ra5 Rh3 2.Ke3 Rh6 3.Rxb5
+/- (1.37) Depth: 4/12 00:00:00
1.Ra5 Rh4 2.Rxb5 Rc4 3.Ra5
+/- (1.15) Depth: 5/12 00:00:00
1.c6 Rf5 2.Ke3 Rf7 3.Ra8
+/- (1.33) Depth: 5/12 00:00:00
1.c6 Rh3 2.Ke2 Kd6 3.Ke3 Kc7 4.Kf4
+/- (1.07) Depth: 6/14 00:00:00 12kN
1.Ra5 Rh4 2.Rxb5 Rf4 3.c6 Rxf3+ 4.Kd2
+/- (1.24) Depth: 6/14 00:00:00 14kN
1.Ra5 Rh4 2.Rxb5 Rf4 3.c6 Rxf3+ 4.Kd2 Kd6 5.Rb6
+/- (0.99) Depth: 7/14 00:00:00 37kN
1.Ra8 Rh4 2.Re8+ Kf5 3.Rf8+ Ke6 4.f4 Ke7 5.Rf5
+/- (1.13) Depth: 7/16 00:00:00 47kN
1.Ra8 Rh4 2.Re8+ Kf5 3.Rf8+ Ke6 4.f4 Ke7 5.Rf5 Rh3+ 6.Kd4
+/- (1.32) Depth: 8/16 00:00:00 85kN
1.Ra8 Rh4 2.Re8+ Kf5 3.Rf8+ Ke6 4.f4 Rh1 5.c6 Kd6 6.Rc8
+/- (1.35) Depth: 9/19 00:00:00 163kN
1.Ra8 Rh4 2.Re8+ Kf5 3.Rf8+ Ke6 4.f4 Rh1 5.c6 Kd6 6.Rc8 Rf1 7.Ke3
+/- (1.38) Depth: 10/19 00:00:00 263kN
1.Ra8 Rh4 2.f4+ Ke6 3.Ke3 Rh3+ 4.Kd4 Rf3 5.Ra6+ Kf5 6.c6 Rxf4+ 7.Kxd5 Rc4 8.Ra7 Rxc3 9.Rf7+ Kg5
+- (1.54) Depth: 11/22 00:00:00 753kN
1.Ra8 Ke6 2.f4 Rh1 3.Ra6+ Kf5 4.c6 Ke6 5.Ra7 Rh3+ 6.Kd4 Rf3 7.Kc5 Rxc3+ 8.Kxb5
+- (1.63) Depth: 12/23 00:00:00 1498kN
1.Ra8 Ke6 2.f4 Rh4 3.Ke3 Rh1 4.Ra6+ Kf5 5.c6 Rh7 6.Kd4 Rc7 7.Kxd5 Kxf4 8.Ra8
+- (1.73) Depth: 13/24 00:00:00 2290kN
1.Ra8 Ke6 2.f4 Rh4 3.Ke3 Rh3+ 4.Kd4 Rf3 5.Re8+ Kd7 6.Rf8 Kc6 7.Rf6+ Kd7 8.c6+ Kc7 9.Kxd5 Rd3+ 10.Kc5 Rxc3+ 11.Kxb5
+- (1.73) Depth: 14/27 00:00:00 3740kN
1.f4+ Kxf4 2.Ra8 Rh6 3.Kd4 Kg4 4.Rg8+ Kf3 5.Kxd5 Rh5+ 6.Kc6 Ke4 7.Kxb5 Kd3 8.c4 Ke4 9.Rg4+ Ke5
+- (1.88) Depth: 14/27 00:00:01 6218kN

1.f4+ Kxf4 2.Ra8 Rh6 3.Kd4 Kg4 4.Rg8+ Kf3 5.Kxd5 Rh5+ 6.Kc6 Ke4 7.Kxb5 Kd3 8.c4 Ke4 9.Rg4+ Kd3 10.Rg6
+- (1.89) Depth: 15/27 00:00:01 7711kN
1.f4+ Kxf4 2.Ra8 Rh6 3.Kd4 Kf5 4.Rb8 Re6 5.Rxb5 Re4+ 6.Kxd5 Re5+ 7.Kd6 Kf6 8.Rb1 Re6+ 9.Kd5 Re5+ 10.Kd4 Re6 11.c4
+- (2.14) Depth: 16/32 00:00:02 15665kN
1.f4+ Kxf4 2.Ra8 Rh6 3.Kd4 Kf5 4.Rb8 Rh7 5.Rxb5 Rc7 6.Kxd5 Rd7+ 7.Kc4 Rc7 8.c6+ Ke6 9.Rc5 Kd6 10.Rd5+ Ke6 11.Kc5
+- (2.23) Depth: 17/38 00:00:03 24247kN
1.f4+ Kxf4 2.Ra8 Rh6 3.Kd4 Kf5 4.Rb8 Rh7 5.Rxb5 Rc7 6.Kxd5 Rd7+ 7.Kc4 Rc7 8.c6+ Ke6 9.Rc5 Rc8 10.Kd4 Kd6 11.c7
+- (2.35) Depth: 18/38 00:00:05 38183kN
1.f4+ Kxf4 2.Ra8 Rh6 3.Kd4 Kf5 4.Rb8 Rh7 5.Rxb5 Ke6 6.Rb6+ Kf5 7.Kxd5 Rh3 8.Rb3 Rd3+ 9.Kc4 Rd1 10.c6 Ke6 11.Rb7 Rc1 12.Kd4
+- (2.47) Depth: 19/44 00:00:11 84477kN
1.f4+ Kxf4 2.Ra8 Rh6 3.Kd4 Kf5 4.Rb8 Rh7 5.Rxb5 Ke6 6.Rb6+ Kf5 7.Kxd5 Rh3 8.Rb3 Rd3+ 9.Kc4 Rg3 10.c6 Ke6 11.Rb7 Kd6 12.c7 Rg4+ 13.Kb5
+- (2.50) Depth: 20/51 00:00:18 142mN
1.f4+ Kxf4 2.Ra8 Rh7 3.Kd4 Kf3 4.c6 Ke2 5.Kxd5 Kd3 6.Kd6 Kxc3 7.c7 Rxc7 8.Kxc7 b4 9.Rc8 b3 10.Kd6+ Kb4 11.Rb8+ Kc3 12.Kd5 b2 13.Ke4
+- (3.14) Depth: 21/57 00:01:06 511mN
jdart
Posts: 4367
Joined: Fri Mar 10, 2006 5:23 am
Location: http://www.arasanchess.org

Re: Kamsky-Yussupow, Tilburg 1992

Post by jdart »

I'm not getting to 14 ply in 1 second on this, not even on a quad.

For some reason my branching factor isn't that high on this position. I have null move pretty much disabled for this because of the low material.

--Jon
Harald Johnsen

Re: Kamsky-Yussupow, Tilburg 1992

Post by Harald Johnsen »

Eelco de Groot wrote:Just to give you an idea where the big bonuses were coming from, and no tablebases to correct it. An enemy Rook controlling qsq and a big material plus for Black might be a way to scale the bonuses a bit :oops:

Eelco
[D] 4r3/1K6/2P3k1/8/8/2P5/8/8 w - - 2 12

1/6 00:00 99 0 -2,04 c7 Re7
2/10 00:00 526 0 -2,22 c7 Re7 Kc6 Re8
3/8 00:00 880 0 0,00 c7 Re7 Kb8 Re8+ c8Q Rxc8+ Kxc8

The position is quickly a draw when probing the kpk bitbase after the pawn & rook exchange and the king on c8.

[D] 8/1K6/6k1/8/8/2P5/8/8 w - - 0 12
This position is won for white with white or black to move

What we see here is that some code to handle the first pawn promotion could work but only the bitbase can accuratly evaluate the second passed pawn. To handle that kind of position (kpp vs k+piece) with a protected passed pawn one could perhaps handle the exchange of the first passed pawn and then try an oracle probes (with the white king placed on the promotion square). Well perhaps it's not worth it because it's only a 5 man.

HJ.
User avatar
Eelco de Groot
Posts: 4567
Joined: Sun Mar 12, 2006 2:40 am
Full name:   

Re: Kamsky-Yussupow, Tilburg 1992

Post by Eelco de Groot »

jdart wrote:I'm not getting to 14 ply in 1 second on this, not even on a quad.

For some reason my branching factor isn't that high on this position. I have null move pretty much disabled for this because of the low material.

--Jon
Jon have you tried if you don't get better plydepths with Arasan by not disabling nullmove here, or in endings in general? I wonder if it really is worth it to detect a few more zugzwang positions by disabling null.

Looking at Toga's or Glaurung's code it seems fairly simple to do a verification search after nullmove, it won't catch everything I think especially if you make it a shallow search, but I think the overall reduction is worth it; for Glaurung does a nullmove search that is 5 plies shorter than the normal search, in Toga Checkov it was the same, R=5, and verification search I believe was even more shortened, 7 or 8 plies.

I tried some sort of adaptive R for the nullmove search in Toga but that did not seem to work very well, the verification search I did make shorter/adaptive and that is still in: if the result of the nullmove search was very low a larger R(eduction) for the verification search is tried. But I'm not sure that is a correct interpretation of what nullmove returns. Anyway it did not seem to hurt much to do it that way. 8-)

Regards, Eelco
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan
User avatar
Eelco de Groot
Posts: 4567
Joined: Sun Mar 12, 2006 2:40 am
Full name:   

Re: Kamsky-Yussupow, Tilburg 1992

Post by Eelco de Groot »

Harald Johnsen wrote:
Eelco de Groot wrote:Just to give you an idea where the big bonuses were coming from, and no tablebases to correct it. An enemy Rook controlling qsq and a big material plus for Black might be a way to scale the bonuses a bit :oops:

Eelco
[D] 4r3/1K6/2P3k1/8/8/2P5/8/8 w - - 2 12

1/6 00:00 99 0 -2,04 c7 Re7
2/10 00:00 526 0 -2,22 c7 Re7 Kc6 Re8
3/8 00:00 880 0 0,00 c7 Re7 Kb8 Re8+ c8Q Rxc8+ Kxc8

The position is quickly a draw when probing the kpk bitbase after the pawn & rook exchange and the king on c8.

[D] 8/1K6/6k1/8/8/2P5/8/8 w - - 0 12
This position is won for white with white or black to move

What we see here is that some code to handle the first pawn promotion could work but only the bitbase can accuratly evaluate the second passed pawn. To handle that kind of position (kpp vs k+piece) with a protected passed pawn one could perhaps handle the exchange of the first passed pawn and then try an oracle probes (with the white king placed on the promotion square). Well perhaps it's not worth it because it's only a 5 man.

HJ.
Harald, I think agree with what you say here.

As an aside more or less; has anybody tried a deeper search in the root position? I now get all of a sudden that directly playing f4 is not best at all and Ancalagon wants to play 1. Ra8 :o

All I changed in Build No. 2 is that the bonus for a passed pawn can't get more than 2 pawns worth if the promotion square is under attack, the check for this is only made on rank 6 or higher so before that it might be possible that searches return higher bonuses. But scores of +10.13 for a tablebase draw I think are no longer possible..

Harald, if I understand you correctly it is probably not necessary to do anything extra in eval for the second possible passer here at least not in Glaurung because Tord has implemented a bitbase for KPK, and White can only make some progress exchanging the first pawn for the Rook at least starting from your position from Ancalagon's PV. After the exchange it automatically becomes a position that can be judged by the small bitbase in Glaurung. I think you meant the same when you write about oracle probes?

A problem in Ancalagon so far was I think if the bonus for a Passed Pawn became so high that White does not ever want to give it up even for a Rook, so the promotion is pushed over the horizon, at least I hope that this interpretation of what happened in the PV is somewhat correct...

But now Ancalagon does not want to play 1.f4 no more :!: I sure hope the PVs make some more sense this time :)


[D]8/8/R7/1pPpk2r/8/2PK1P2/8/8 w - -

Engine: Ancalagon 1.08 Beta Build 2 (Athlon 2009 MHz, 256 MB)
by Tord Romstad, Eelco de Groot

2.00 0:00 +4.19 1.f4+ Kf5 2.Kd4 (280) 0

2.00 0:00 +7.50 1.Rg6 Rh7 (338) 0

3.00 0:00 +3.52 1.Rg6 Kf5 2.Rg4 (687) 1

3.00 0:00 +7.39 1.f4+ Kxf4 2.Kd4 Kf5 (1.032) 2

4.00 0:00 +4.05 1.f4+ Kf5 2.Kd4 Rh1 3.Kxd5 Rd1+
4.Kc6 (2.798) 7

4.00 0:00 +5.21 1.Rd6 Rh1 2.f4+ Kf5 3.Rxd5+ Ke6
4.f5+ Ke7 (4.699) 13

5.00 0:00 +3.11 1.Rd6 Rf5 2.Ke3 Rf4 3.Ra6 (10.139) 27

5.00 0:00 +5.72 1.f4+ Kf5 2.Kd4 Rh2 3.Kxd5 Rd2+
4.Kc6 Ke6 5.Kxb5+ Kd7 (12.848) 34

6.00 0:00 +4.66 1.f4+ Kf5 2.Rd6 Rh1 3.Rxd5+ Ke6
4.Rd6+ Ke7 5.Ke4 (26.589) 65

7.00 0:00 +5.23 1.f4+ Kf5 2.Kd4 Rh1 3.Kxd5 Re1 4.Kc6 Re6+
5.Kxb5 Rxa6 6.Kxa6 (53.478) 118

8.00 0:00 +5.03 1.f4+ Kf5 2.Kd4 Rh3 3.Rb6 Rh1 4.Kxd5 Rb1
5.Kd6 Rd1+ 6.Ke7 (102.343) 187

9.00 0:00 +3.82 1.f4+ Kxf4 2.Kd4 Kf5 3.Kxd5 Rh3
4.Ra2 Rd3+ 5.Kc6 Rxc3 6.Rf2+ Ke5
7.Re2+ Kd4 (189.489) 269

10.01 0:01 +3.60 1.f4+ Kxf4 2.Kd4 Kf5 3.Kxd5 Rh3
4.Ra2 Rd3+ 5.Kc6 Rxc3 6.Rf2+ Ke5
7.Re2+ Kd4 8.Rd2+ Ke5 9.Kxb5 (481.656) 375

11.01 0:02 +3.72 1.f4+ Kxf4 2.Kd4 Kf5 3.Kxd5 Rh3
4.Kc6 Rxc3 5.Kxb5 Rb3+ 6.Kc4 Rb2
7.Rd6 (883.403) 441

12.01 0:02 +3.98 1.f4+ Kxf4 2.Kd4 Kf5 3.Kxd5 Rh3
4.Ra3 Rh1 5.Kc6 Ke6 6.Ra6 Ke7 7.Kxb5 Rb1+
8.Kc4 (1.373.227) 477

13.01 0:04 +3.98 1.f4+ Kxf4 2.Kd4 Kf5 3.Kxd5 Rh3
4.Ra3 Rh1 5.Ra2 Kf6 6.Re2 Rh3 7.Kd4 Rh4+
8.Kd5 (2.097.940) 502

14.01 0:07 +3.64 1.f4+ Kxf4 2.Kd4 Kf5 3.Kxd5 Rh3
4.Kc6 Rxc3 5.Kxb5 Ke5 6.Rh6 Rb3+
7.Kc4 Rf3 8.Rh4 Ke6 (3.709.874) 525

15.01 0:15 +3.54 1.f4+ Kxf4 2.Kd4 Kf5 3.Kxd5 Rh3
4.Kc6 Rxc3 5.Kxb5 Ke5 6.Rg6 Rd3
7.Kb6 Rh3 8.Rd6 Rb3+ 9.Kc7 (8.538.464) 541


15.02 0:19 +3.82 1.Rg6 Rh4 2.Rg4 Rh3 3.Ke3 Kf6 4.c6 Rh2
5.c7 Rh8 6.Rh4 Rc8 7.Rh7 Kg6 8.Re7 Ra8 (10.699.261) 540

16.01 0:31 +3.58 1.Rg6 Rh4 2.Rg4 Rh3 3.Ke3 Kf6 4.Rg8 Ke7
5.Rg7+ Ke6 6.Rg5 Kd7 7.Rxd5+ Kc6
8.Rg5 Rh8 9.f4 Re8+ 10.Kd4 (16.936.686) 542

17.01 1:04 +3.72 1.Rg6 Rh4 2.Rg4 Rh3 3.Ke3 Ke6 4.Rg7 Rh2
5.Rg6+ Kd7 6.f4 Rh5 7.Rg5 Rh1
8.Rxd5+ Kc6 9.Rg5 Re1+ 10.Kf3 Rf1+
11.Ke4 Re1+ 12.Kd4 (35.128.409) 546

18.01 1:55 +3.72 1.Rg6 Rh4 2.Rg4 Rh3 3.Ke3 Ke6 4.Rg7 Rh2
5.Rg6+ Kd7 6.f4 Rh5 7.Rg5 Rh1
8.Rxd5+ Kc6 9.Rg5 Re1+ 10.Kd3 Rd1+
11.Ke2 Rd8 (63.101.787) 546


18.08 3:16 +4.27 1.Ra8 Ke6 2.f4 Rf5 3.Ke3 Kd7 4.Ra6 Rh5
5.Rg6 Rh3+ 6.Kd4 Rh4 7.Rf6 Ke7 8.Rf5 Ke6
9.Re5+ Kd7 10.Rxd5+ Kc7 11.Ke5 (107.351.513) 547

19.01 4:09 +4.27 1.Ra8 Ke6 2.f4 Rf5 3.Ke3 Kd7 4.Ra6 Rh5
5.Rb6 Rf5 6.Rd6+ Kc7 7.Kf3 Rf8
8.Rxd5 Rh8 9.Ke3 Rh3+ 10.Kd4 Rh4
11.Ke5 (136.400.555) 547

20.01 6:18 +4.19 1.Ra8 Ke6 2.f4 Rf5 3.Ke3 Kd7 4.Ra6 Rh5
5.Rb6 Rh3+ 6.Kd4 Rf3 7.Rf6 Ke7 8.Rf5 Ke6
9.Re5+ Kf6 10.Re8 Kf7 11.Re1 Rxf4+
12.Kxd5 (207.003.567) 546

21.01 11:54 +4.21 1.Ra8 Ke6 2.f4 Rf5 3.Ra6+ Kd7 4.Ke3 Rh5
5.Rg6 Ke7 6.Rg7+ Ke6 7.Rb7 Rh3+
8.Kd4 Rf3 9.Rb6+ Ke7 10.Ke5 Rxc3
11.Rxb5 Rc4 12.Kxd5 Rxf4 13.Rb7+ Kd8 (392.521.782) 549

22.01 21:10 +3.84 1.Ra8 Ke6 2.f4 Rf5 3.Ra6+ Kd7 4.Ke3 Kc7
5.Rd6 Kb7 6.Kf3 Rf8 7.Rxd5 Kc6 8.Re5 Ra8
9.Ke3 Ra4 10.f5 Rc4 11.Kd3 Rxc5
12.Ke4 Rc4+ 13.Kd3 (691.779.624) 544

23.01 39:35 +3.84 1.Ra8 Ke6 2.f4 Rf5 3.Ra6+ Kd7 4.Ke3 Kc7
5.Rd6 Kb7 6.Kf3 Rf8 7.Rxd5 Kc6 8.Re5 Ra8
9.Ke3 Ra3 10.Kd2 Ra4 11.f5 Rc4
12.Kd3 Rxc5 13.Kd4 Rc4+ 14.Kd3 (1.294.217.883) 544
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan