Medium difficulty testmove 17.Qe3

Eelco de Groot · Post by **Eelco de Groot** » Tue Apr 08, 2008 3:54 am

Hello,

Maybe not a very interesting move, it may not even be a winning move if Black defends well, but apparently it can cause some difficulties in QSearches, at least the last builds of Toga that I made totally exploded their searches for some reason. Either that or it must be a bug somewhere in the search possibly introduced by my own spaghetti-code

The hashfill-rate goes to zero but the NPS does not stop, search goes on so I think it must be the quiescence search because that does not use the hashtables.

[Event "12 Minutes/Game + 6 Seconds/Move"]
[Site "Engine Match"]
[Date "2008.04.07"]
[Round "2"]
[White "Naum 3"]
[Black "Shredder 11+ Beta6c"]
[Result "1-0"]

1. e4 {book 0s} e5 {book 0s} 2. Nf3 {book 0s} Nc6 {book 0s}
3. Bb5 {book 0s} a6 {book 0s} 4. Bxc6 {book 0s} dxc6 {book
0s} 5. O-O {book 0s} Qd6 {book 0s} 6. Na3 {book 0s} Be6
{book 0s} 7. Qe2 {book 0s} f6 {book 0s} 8. Rd1 {book 0s}
O-O-O {book 0s} 9. Nc4 {book 0s} Qe7 {book 0s} 10. d3 {book
0s} h5 {-0.10/14 33s} 11. b3 {+0.31/13 29s} Qe8 {-0.19/14
35s} 12. Be3 {+0.27/13 32s (Bb2)} h4 {-0.21/14 29s} 13. d4
{+0.28/13 20s (h3)} h3 {+0.30/14 35s} 14. dxe5 {+0.15/13
19s} Rxd1+ {+0.28/14 33s} 15. Rxd1 {+0.04/14 28s} hxg2
{+0.29/15 38s} 16. Bf4 {0.00/14 45s} Bg4 {?}{-0.86/14 3:39m}

{[D]2k1qbnr/1pp3p1/p1p2p2/4P3/2N1PBb1/1P3N2/P1P1QPpP/3R2K1 w - - bm Qe3;

In this testgame Naum 3 - Shredder 11 the Shredder settings I was testing produced a bad move 16... Bg4 {?!?} the move unfortunately is not reproducible in Analysis mode, at least, I have to be more precise: Bg4 is seen to be a bad move, in Analysis mode earlier, in the game Shredder sees it is -0.86 at depth 14 but maybe there is not time anymore to find a better move after thinking 3 minutes 39 seconds? For 17... c5 {?!} Shredder also takes more than three minutes and that probably is much worse than exchanging on f3. Anyway, it may just be a problem with these settings. Naum 3 does well in finding 17.Qe3 {!}, in analysismode, with more hash, Naum takes longer than the 33 seconds it needed in the game.}

17. Qe3 {!} {Not sure if it is enough for a full point if Black plays 17... Bxf3}{+0.78/12 33s} c5 {Probably the decisive mistake}{-1.92/14 3:47m} 18. exf6 {+1.79/13 1:01m} Rh3 {-1.92/14 14s} 19. Bg3 {+1.74/14 17s} gxf6 {-1.97/13 17s} 20. Qf4 {+2.52/16 41s} Rxg3 {-2.24/14 25s} 21. fxg3 {+2.52/16 19s (Qxg3)} Bd7 {-2.21/13 20s}
22. e5 {+2.62/15 31s} Bh6 {-2.32/13 8s} 23. Qe4 {+2.70/15
22s} f5 {-2.26/14 12s} 24. Qh4 {+2.69/14 34s (Qd5)} b5
{-2.27/14 9s} 25. Na5 {+2.69/15 14s (e6)} Qg6 {-2.63/14 9s}
26. Kxg2 {+2.56/15 19s} f4 {-2.83/14 22s} 27. Rd3 {+2.57/15
23s} fxg3 {-2.83/14 1:06m} 28. hxg3 {+2.57/15 9s} Bg7
{-2.72/12 4s} 29. a3 {+2.57/15 37s (a4)} Nh6 {-2.58/12 5s}
30. Qe7 {+4.03/16 13s} Qxg3+ {-2.93/13 4s} 31. Kh1
{+4.12/18 17s (Kxg3)} Qg4 {-2.71/12 4s} 32. e6 {+4.12/18
25s} Qh3+ {-3.45/14 14s} 33. Nh2 {+4.12/19 20s} Qxe6
{-3.45/15 4s} 34. Qxg7 {+4.17/18 23s} Nf5 {-3.45/14 6s}
35. Qf8+ {+4.81/13 10s (Qh8+)} Be8 {-3.17/13 8s} 36. Qxc5
{+4.81/15 10s} Bg6 {-3.17/12 3s} 37. Qf8+ {+4.81/16 33s}
Be8 {-3.26/12 5s} 38. Nf1 {+4.81/17 13s (Kg1)} Qg6
{-3.67/12 7s} 39. b4 {+4.81/17 24s (c4)} Qe6 {-3.60/12 6s}
40. Kg1 {+5.10/15 8s} Qg6+ {-4.45/13 8s} 41. Kf2 {+5.12/16
13s} Nd6 {-4.21/13 6s} 42. Ng3 {+5.12/16 9s (Ne3)} Kb8
{-4.53/13 5s} 43. Nf5 {+5.42/15 11s} Qxf5+ {-5.12/14 5s}
44. Qxf5 {+5.12/4 0s} Nxf5 {-4.71/16 0s} 45. Rd8+ {+6.24/16
9s} Ka7 {-4.71/10 0s} 46. Rxe8 {+6.24/18 54s} Nd6 {-4.99/17
3s} 47. Rf8 {+7.10/17 43s (Re7)} c6 {-6.83/16 15s}
48. Nxc6+ {+7.17/16 38s (Rd8)} Kb7 {-8.58/18 7s} 49. Na5+
{+7.17/15 14s (Ne5)} Kc7 {-10.72/19 7s} 50. Ke3 {+7.17/15
13s} Kd7 {-10.72/18 6s} 51. Ra8 {+7.90/15 12s} Nf5+
{-10.89/16 6s} 52. Kd3 {+8.10/15 6s} Nh4 {-11.14/15 6s}
53. Rxa6 {+8.10/14 10s} Nf3 {-11.84/16 6s} 54. Rb6
{+8.10/14 9s} Ne5+ {-12.04/16 5s} 55. Kc3 {+8.10/14 5s
(Kd4)} Kc7 {-12.83/16 14s} 56. Rxb5 {+8.10/14 6s} Ng6
{-12.83/15 0s} 57. Rb7+ {+10.22/14 12s} Kc8 {-14.10/16 2s}
58. b5 {+14.91/15 6s (a4)} Nf4 {-279.83/18 6s} 59. Kc4
{+M29/14 2s (b6)} Ng6 {-M7/20 5s} 60. Rg7 {+M24/10 0s (b6)}
Kd8 {-M8/17 10s} 61. Rxg6 {+M9/9 0s (Nc6+)} Ke7 {-M7/16 3s}
62. b6 {+M8/7 0s (Nc6+)} Kf7 {-M5/15 3s} 63. Rg1 {+M7/5 0s
(Rc6)} Kf6 {-M5/15 6s} 64. b7 {+M6/2 0s} Ke5 {-M4/13 2s}
65. b8=Q+ {+M5/2 0s} Ke6 {-M3/12 4s} 66. Qe8+ {+M4/1 0s
(Nc6)} Kf5 {-M2/12 3s} 67. Kd5 {+M2/1 0s} Kf4 {-M1/11 1s}
68. Qe4# {+M1/1 0s} 1-0

Build 70 of Toga here only gets as far as 9 ply, does see Qe3 but can't resolve it:

Build 70: tries to reign in extensions in QSearch but is not successful enough, extensions only allowed if depth > -1 instead of depth > 0, still QSearch explodes on ply 9, does find Ne3 at this depth what Build 69 does not. Changes in search_full.cpp:

// extensions

if (MOVE_IS_PROMOTE(move) && depth > -20 && depth < -1) {
ASSERT(PIECE_IS_PAWN(piece));
depth++; // pawn promotion extension
}
else if (single_reply && depth > -30 && depth < -1) {
depth++; // single reply extension
}

2k1qbnr/1pp3p1/p1p2p2/4P3/2N1PBb1/1P3N2/P1P1QPpP/3R2K1 w - -

Engine: Toga 1.5 Checkov_beta1 bb5men test4 (256 MB, Athlon 2009 MHz, Build 70, d.d. 8-04-2008 2:42 CET, "test 4" just refers to the used settings, no bitbases working as yet although switched on in settings)
by Letouzey, Gaksch, Pudas and de Groot

1/14 0:00 +0.79 17.exf6 Nxf6 (102)

1/14 0:00 +0.99 17.Kxg2 Kb8 18.exf6 Nxf6 (393)

2/16 0:00 +0.98 17.Kxg2 Kb8 18.exf6 Nxf6 (4.342)

3/16 0:00 +0.48 17.Kxg2 Kb8 18.Kg1 Bc5 19.exf6 Nxf6 (6.972)

3/16 0:00 +0.54 17.exf6 Nxf6 18.Be5 Kb8 19.Bxf6 gxf6
20.Kxg2 (7.625)

4/16 0:00 +0.20 17.exf6 Nxf6 18.Nce5 Bc5 19.Nxg4 Nxg4
20.Kxg2 Nxf2 (10.839)

4/17 0:00 +0.25 17.Kxg2 g5 18.Be3 Rh3 19.Ncd2 fxe5
20.Bxg5 (19.212)

5/24 0:00 +0.25 17.Kxg2 g5 18.Be3 Rh3 19.Ncd2 fxe5
20.Bxg5 (55.738)

6/24 0:00 +0.25 17.Kxg2 g5 18.Bg3 Kb8 19.Ne3 Bh3+
20.Kh1 Bc5 21.exf6 Qxe4 22.Rd8+ Bc8 (82.471)

7/26 0:00 +0.19 17.Kxg2 g5 18.Bg3 Kb8 19.Ne3 Bh3+
20.Kh1 g4 21.Nh4 (221.305)

8/31 0:01 0.00 17.Kxg2 g5 18.Bg3 Bc5 19.a4 Kb8
20.Kh1 Qf8 21.Ne3 (565.906) 423

8/31 0:01 +0.41 17.Ne3 Be6 18.Nxg2 g5 19.Bg3 g4
20.Nd4 Bc5 21.Nxe6 Qxe6 (785.772) 423

9/31 0:02 +0.38 17.Ne3 Be6 18.Nxg2 g5 19.Bg3 Bc5
20.Nd4 Bxd4 21.Rxd4 Kb8 22.Ne3 (878.818) 411

best move: Nc4-e3 time: 7:39.750 min n/s: 566.572 CPU 100.0% n/s(1CPU): 566.572 nodes: 260.340.000

Build 71 was a bit more succesful I'm happy to say

But in Blitzgames I don't think very many engines will find 17.Qe3

I have not tried it yet though, maybe it's an easy move.

Eelco

Eelco de Groot · Post by **Eelco de Groot** » Tue Apr 08, 2008 4:27 am

Output from Naum 3 in analysis mode, only 64 Mb hash, as in the game:

2k1qbnr/1pp3p1/p1p2p2/4P3/2N1PBb1/1P3N2/P1P1QPpP/3R2K1 w - -

Engine: Naum 3 (64 MB)
by Aleksandar Naumov

9/24 0:03 +0.54 17.Kxg2 Bc5 18.c3 Ne7 19.b4 Qg6
20.Bg3 Ba7 21.h4 (1.080.349) 354

10/26 0:04 +0.57 17.Kxg2 Bc5 18.c3 Ne7 19.b4 Qg6
20.Bg3 Ba7 21.Kg1 Kb8 (1.721.215) 356

11/29 0:11 +0.39 17.Kxg2 Ne7 18.exf6 Ng6 19.Bg3 gxf6
20.Qe3 Bh6 21.Qd4 Bf4 22.Ne3 (3.927.826) 354

12/32 0:18 +0.34 17.Kxg2 Ne7 18.exf6 Ng6 19.Bg3 gxf6
20.Qe3 Bh6 21.Qd4 Qf7 22.h3 Be6 (6.675.115) 353

12/36 1:07 +0.88 17.Qe3 Bxf3 18.Qxf3 Qe6 19.Kxg2 Bc5
20.a4 Ne7 21.Bg3 Kb8 22.h4 Ng6 (23.598.932) 351

13/35 1:34 +0.65 17.Qe3 c5 18.Kxg2 b5 19.Na5 Rh3
20.Bg3 fxe5 21.Rd5 Nf6 22.Rxe5 Qd7
23.Ng5 (33.164.231) 349

14/38 2:18 +0.68 17.Qe3 c5 18.Kxg2 b5 19.Na5 Rh3
20.Bg3 fxe5 21.Rd5 Nf6 22.Rxe5 Be6
23.Rxc5 Rxg3+ (48.622.251) 350

15/44 4:46 +0.99 17.Qe3 Bxf3 18.Qxf3 Qe6 19.Qe3 c5
20.exf6 Nxf6 21.f3 b5 22.Qd2 Be7
23.Qa5 Ne8 24.Ne5 (102.400.613) 357

16/36 6:48 +1.03 17.Qe3 Bxf3 18.Qxf3 Qe6 19.Qe3 c5
20.exf6 Nxf6 21.e5 Nd7 22.Bg3 Nb8
23.Kxg2 Nc6 24.c3 b5 (146.620.432) 358

Build 70: tries to reign in extensions in QSearch but is not successful enough, extensions only allowed if depth > -1 instead of depth > 0, still QSearch explodes on ply 9, does find Ne3 at this depth what Build 69 does not. Changes in search_full.cpp:

Correction, that should have read: extensions allowed if depth < -1, not > -1
Everything with depth <= 0 is QSearch, but for some reason allowing the depth to go up (depth++) is a problem somewhere in the code.

This is Toga Checkov 1.5 Beta1 Build 71:

codechanges:

// extensions are commented out in Build 71
/*
if (MOVE_IS_PROMOTE(move) && depth > -20 && depth < -1) {
ASSERT(PIECE_IS_PAWN(piece));
depth++; // pawn promotion extension
}
else if (single_reply && depth > -30 && depth < -1) {
depth++; // single reply extension
}
else if (capture_value(move,board)>= 500 && depth > -10) {
depth--;
}*/

move_do(board,move,undo);
value = -full_quiescence(board,-beta,-alpha,depth-1,height+1,new_pv,cd,ThreadId);
move_undo(board,move,undo);

[D]2k1qbnr/1pp3p1/p1p2p2/4P3/2N1PBb1/1P3N2/P1P1QPpP/3R2K1 w - -

Engine: Toga 1.5 Checkov_beta1 bb5men test4 (256 MB)
by Letouzey, Gaksch, Pudas and de Groot

1/14 0:00 +0.79 17.exf6 Nxf6 (102)

1/14 0:00 +0.99 17.Kxg2 Kb8 18.exf6 Nxf6 (393)

2/16 0:00 +0.98 17.Kxg2 Kb8 18.exf6 Nxf6 (4.342)

3/16 0:00 +0.48 17.Kxg2 Kb8 18.Kg1 Bc5 19.exf6 Nxf6 (6.972)

3/16 0:00 +0.54 17.exf6 Nxf6 18.Be5 Kb8 19.Bxf6 gxf6
20.Kxg2 (7.625)

4/16 0:00 +0.20 17.exf6 Nxf6 18.Nce5 Bc5 19.Nxg4 Nxg4
20.Kxg2 Nxf2 (10.839)

4/17 0:00 +0.25 17.Kxg2 g5 18.Be3 Rh3 19.Ncd2 fxe5
20.Bxg5 (19.212)

5/24 0:00 +0.25 17.Kxg2 g5 18.Be3 Rh3 19.Ncd2 fxe5
20.Bxg5 (55.742)

6/24 0:00 +0.25 17.Kxg2 g5 18.Bg3 Kb8 19.Ne3 Bh3+
20.Kh1 Bc5 21.exf6 Qxe4 22.Rd8+ Bc8 (82.475)

7/26 0:00 +0.19 17.Kxg2 g5 18.Bg3 Kb8 19.Ne3 Bh3+
20.Kh1 g4 21.Nh4 (221.309)

8/31 0:01 0.00 17.Kxg2 g5 18.Bg3 Bc5 19.a4 Kb8
20.Kh1 Qf8 21.Ne3 (565.790) 420

8/31 0:01 +0.41 17.Ne3 Be6 18.Nxg2 g5 19.Bg3 g4
20.Nd4 Bc5 21.Nxe6 Qxe6 (785.616) 420

9/31 0:02 +0.38 17.Ne3 Be6 18.Nxg2 g5 19.Bg3 Bc5
20.Nd4 Bxd4 21.Rxd4 Kb8 22.Ne3 (878.661) 411

9/38 0:10 +0.58 17.Qe3 c5 18.Kxg2 b5 19.Na5 Rh3
20.Bg3 fxe5 21.Qd3 Nf6 22.Nxe5 Bxd1
23.Kxh3 (4.516.098) 429

10/38 0:12 +0.88 17.Qe3 c5 18.Bg3 g5 19.Kxg2 Rh5
20.Kg1 Kb8 21.exf6 Nxf6 22.e5 Nh7
23.a4 Qf7 24.Rd8+ Bc8 (5.459.949) 429

11/38 0:18 +0.48 17.Qe3 c5 18.Bg3 Bh3 19.exf6 gxf6
20.Qf4 Rh7 21.Nh4 Bh6 22.Qf3 Re7 (7.883.683) 430

12/38 0:36 +0.64 17.Qe3 c5 18.Kxg2 Rh5 19.exf6 Nxf6
20.Bxc7 Qxe4 21.Qxe4 Nxe4 22.Be5 b5
23.Re1 Bh3+ 24.Kg1 Bf5 25.Nb6+ Kb7 (16.083.851) 439

13/42 1:52 +1.36 17.Qe3 Bxf3 18.Qxf3 Qe6 19.Kxg2 fxe5
20.Nxe5 Bd6 21.Nd3 Be7 22.Be5 Kb8
23.Qg3 Nf6 24.Bxc7+ Ka8 25.f3 (51.116.691) 453

14/52 3:34 +0.89 17.Qe3 Bxf3 18.Qxf3 Qe6 19.Kxg2 fxe5
20.Nxe5 Bd6 21.Nd3 Ne7 22.Kg1 Rh3
23.Bg3 Ng6 24.a4 Nh4 25.Qe3 (99.286.232) 462

15/52 7:48 +1.08 17.Qe3 Bxf3 18.Qxf3 Qe6 19.Qe3 c5
20.Qf3 fxe5 21.Bxe5 Nf6 22.Qxg2 Rh5
23.Bxf6 gxf6 24.Kf1 Bd6 25.Rd5 Rh4
26.f3 Bxh2 27.Rxc5 (220.069.909) 469

16/52 17:47 +0.94 17.Qe3 Bxf3 18.Qxf3 Qe6 19.Qe3 c5
20.Qf3 Ne7 21.exf6 gxf6 22.Kxg2 Nc6
23.c3 Bh6 24.Bxh6 Rxh6 25.Qf5 Qxf5
26.exf5 Rh7 27.Kg3 Rg7+ 28.Kf4 (502.270.116) 470

17/62 53:15 +1.09 17.Qe3 Bxf3 18.Qxf3 Qe6 19.Qe3 c5
20.Qf3 fxe5 21.Bxe5 Nf6 22.Qxg2 Rh5
23.Kf1 Rxe5 24.Nxe5 Qxe5 25.Qh3+ Kb8
26.Rd8+ Ka7 27.Rxf8 Qxe4 28.Qd3 Qh1+
29.Ke2 Qxh2 30.Qe3 (1.497.463.158) 468

At my wits end, I just disabled the extensions in QSearch for Build 71 and that worked

kgburcham · Post by **kgburcham** » Tue Apr 08, 2008 5:21 am

[D] 2k1qbnr/1pp3p1/p1p2p2/4P3/2N1PBb1/1P3N2/P1P1QPpP/3R2K1 w - -

Rybka 2.3.2a mp x64
(node count modified version)
Hash 2048

9.00 0:01 +0.26 1.Kxg2 Bc5 2.c3 Qg6 3.Kf1 Ne7 (475.046) 366
10.00 0:02 +0.31 1.Kxg2 Bc5 2.Bg3 Qg6 3.Kg1 Ne7 4.exf6 (802.262) 355
11.00 0:03 +0.22 1.Kxg2 Bc5 2.Bg3 Qg6 3.Kg1 Ne7 4.exf6 gxf6 5.a3 (1.254.820) 360
12.01 0:06 +0.32 1.Kxg2 Bc5 2.Bg3 Qh5 3.a3 Ne7 4.exf6 gxf6 5.b4 Ba7 (2.299.193) 358
12.09 0:09 +0.81 1.e6 Qxe6 2.Bxc7 Bc5 3.Bg3 Ne7 4.b4 b5 5.bxc5 Qxc4 6.Qxc4 bxc4 7.Kxg2 Bh3+ (3.341.561) 347
13.01 0:11 +0.92 1.e6 Qxe6 2.Bxc7 Bc5 3.Bg3 Ne7 4.b4 b5 5.bxc5 Qxc4 6.Qxc4 bxc4 7.Kxg2 Bh3+ (3.917.184) 345
14.01 0:15 +0.93 1.e6 Qxe6 2.Bxc7 Bc5 3.Bg3 b5 4.Nd6+ Bxd6 5.Rxd6 Qe8 6.Qe3 Kb7 7.Kxg2 Ne7 (5.086.369) 343
15.01 0:26 +0.98 1.e6 Qxe6 2.Bxc7 Nh6 3.Bg3 Bc5 4.b4 Rd8 5.Rxd8+ Kxd8 6.bxc5 Bxf3 7.Qxf3 Qxc4 (9.174.988) 355
16.01 0:46 +1.46 1.e6 Bxe6 2.Qe3 Bxc4 3.Qa7 Bd6 4.Qa8+ Kd7 5.Qxb7 Bd5 6.Bxd6 Qc8 7.Qxc7+ Qxc7 (15.829.152) 349
17.01 1:41 +2.10 1.e6 g5 2.Qe3 c5 3.Rd7 gxf4 4.Qxf4 Qxd7 5.exd7+ Bxd7 6.e5 Be7 7.Qg3 Be6 (33.795.255) 340
18.01 2:20 +2.19 1.e6 g5 2.Qe3 c5 3.Rd7 gxf4 4.Qxf4 Qxd7 5.exd7+ Bxd7 6.e5 Rh6 7.Na5 f5 (44.942.644) 328
19.01 4:11 +2.30 1.e6 g5 2.Qe3 c5 3.Rd7 gxf4 4.Qxf4 Qxd7 5.exd7+ Bxd7 6.e5 Rh6 7.Na5 f5 (77.503.937) 315

Dann Corbit · Post by **Dann Corbit** » Tue Apr 08, 2008 5:52 am

For this position, about half of the programs like Qe3 and the other half like e6.
Here is one e6 sample:

Code: Select all

Analysis from E&#58;\qe3.epd   
4/7/2008 8&#58;07&#58;21 PM Level&#58; Infinite
Analyzing engine&#58; Rybkav2.3.2a.w32

1&#41; Qe3;                 
    Searching move&#58; Qe2-e3
    Best move &#40;Rybkav2.3.2a.w32&#41;&#58; e5-e6
    Not found in&#58; 03&#58;00
      5	00&#58;01	      11.246	45.880	+0.54	Kg1xg2 Bf8c5
      6	00&#58;02	      21.080	55.066	+0.38	Kg1xg2 Bf8c5 Bf4g3
      7	00&#58;02	      38.341	59.758	+0.43	Kg1xg2 Bf8c5 Bf4g3 Kc8b8
      8	00&#58;03	      95.437	63.790	+0.33	Kg1xg2 Bf8c5 c2c3 Qe8g6 Kg2f1
      9	00&#58;03	     138.568	65.298	+0.34	Kg1xg2 Bf8c5 c2c3 Qe8g6 Kg2f1 Ng8e7
     10	00&#58;06	     297.857	65.705	+0.27	Kg1xg2 Bf8c5 a2a3 Qe8e6 Bf4g3 Ng8e7 b3b4
     10	00&#58;11	     595.603	64.192	+0.57	e5e6 Qe8xe6 Bf4xc7 Bf8c5 Bc7b6 Bc5xb6 Nc4xb6+ Kc8b8 Kg1xg2 Ng8e7
     11	00&#58;15	     869.237	63.856	+0.83	e5e6 Qe8xe6 Bf4xc7 Bf8c5 Bc7g3 Ng8e7 b3b4 b7b5 b4xc5 Qe6xc4
     12	00&#58;20	   1.126.155	62.172	+0.89	e5e6 Qe8xe6 Bf4xc7 Bf8c5 Bc7g3 Ng8h6 b3b4 Rh8d8 Rd1xd8+ Kc8xd8 b4xc5 Bg4xf3 Qe2xf3 Qe6xc4
     13	00&#58;28	   1.593.006	61.015	+0.92	e5e6 Qe8xe6 Bf4xc7 Bf8c5 Bc7g3 Ng8h6 b3b4 Rh8d8 Rd1xd8+ Kc8xd8 b4xc5 Bg4xf3 Qe2xf3 Qe6xc4
     14	00&#58;41	   2.296.968	59.498	+0.93	e5e6 Qe8xe6 Bf4xc7 Bf8c5 Bc7g3 Ng8h6 b3b4 Rh8d8 Rd1xd8+ Kc8xd8 b4xc5 Bg4xf3 Qe2xf3 Qe6xc4
     15	02&#58;04	   7.669.649	64.070	+0.91	e5e6 Qe8xe6 Bf4xc7 Ng8h6 Bc7g3 Bf8c5 b3b4 Rh8d8 Rd1xd8+ Kc8xd8 b4xc5 Bg4xf3 Qe2xf3 Qe6xc4
   4/7/2008 8&#58;13&#58;39 PM, Time for this analysis&#58; 00&#58;03&#58;01, Rated time&#58; 03&#58;00

0 of 1 matching moves
4/7/2008 8&#58;13&#58;40 PM, Total time&#58; 12&#58;06&#58;19 AM
Rated time&#58; 03&#58;00 = 180 Seconds

Eelco de Groot · Post by **Eelco de Groot** » Tue Apr 08, 2008 6:41 am

Yes! 17. e6 looks very good too, and Rybka finds it very fast. Thanks! I don't know if Toga rates e6 as much better or somewhat equal to Qe3, it was still calculating at 17 ply, you guessed it, trying to resolve 17. e6. But I think there is a problem with the QSearch again, hash is already 100% so I am not 100% sure what it is, but resolving e6 takes too long.

Anyway, the fact that Rybka has no problems here I think illustrates it has a superior quiescence search. We have all known since day one of Rybka 1.0 that the reported nodecounts where not correct, because the numbers did not vary with the amount of hash, I don't know anymore who actually posted that first but it was not a secret for longer than a day... We have also known for a long time that probably meant Rybka was searching very deeply and that the PV did not show the quiescence search.

No need to do any decompiling for that, I don't agree with this method but in some countries the legal definitions and "acceptable" forms of decompiling, reverse engineering are different than in others I suppose, if there is any legal definition at all as legislation is slow to change. Don't want to go into that but as the obfuscated nodecount has come up again, I think it is more interesting to see I think where other programmers and programmers are finally trying to catch up with the early Rybkas, I think for a part the Q-Search is key and I hope programmers will find their own way instead of playing copycat from the Strelka-code. There is such a thing as honour even among programmers

It is enough to know that it can be done.

About this "node count obfuscation", and if that is really all that it is, another reason for not counting all nodes could simply be that you want to separate Search and QSearch, and a more meaningful number in trying to keep the search within bounds is the amount of QSearches done in a search. I don't know if that is the case with Ryka or if that was Vas' thinking in desiging this form of output, but it has some logic to it I think.

My five cents,
Eelco

Eelco de Groot · Post by **Eelco de Groot** » Tue Apr 08, 2008 6:59 am

Phew, Toga Checkov was not totally hanging on 17.e6, it was finally resolved!

2k1qbnr/1pp3p1/p1p2p2/4P3/2N1PBb1/1P3N2/P1P1QPpP/3R2K1 w - -

Engine: Toga 1.5 Checkov_beta1 bb5men test4 (256 MB)
by Letouzey, Gaksch, Pudas and de Groot

1/14 0:00 +0.79 17.exf6 Nxf6 (102)

1/14 0:00 +0.99 17.Kxg2 Kb8 18.exf6 Nxf6 (393)

2/16 0:00 +0.98 17.Kxg2 Kb8 18.exf6 Nxf6 (4.342)

3/16 0:00 +0.48 17.Kxg2 Kb8 18.Kg1 Bc5 19.exf6 Nxf6 (6.972)

3/16 0:00 +0.54 17.exf6 Nxf6 18.Be5 Kb8 19.Bxf6 gxf6
20.Kxg2 (7.625)

4/16 0:00 +0.20 17.exf6 Nxf6 18.Nce5 Bc5 19.Nxg4 Nxg4
20.Kxg2 Nxf2 (10.839)

4/17 0:00 +0.25 17.Kxg2 g5 18.Be3 Rh3 19.Ncd2 fxe5
20.Bxg5 (19.212)

5/24 0:00 +0.25 17.Kxg2 g5 18.Be3 Rh3 19.Ncd2 fxe5
20.Bxg5 (55.742)

6/24 0:00 +0.25 17.Kxg2 g5 18.Bg3 Kb8 19.Ne3 Bh3+
20.Kh1 Bc5 21.exf6 Qxe4 22.Rd8+ Bc8 (82.475)

7/26 0:00 +0.19 17.Kxg2 g5 18.Bg3 Kb8 19.Ne3 Bh3+
20.Kh1 g4 21.Nh4 (221.309)

8/31 0:01 0.00 17.Kxg2 g5 18.Bg3 Bc5 19.a4 Kb8
20.Kh1 Qf8 21.Ne3 (565.790) 420

8/31 0:01 +0.41 17.Ne3 Be6 18.Nxg2 g5 19.Bg3 g4
20.Nd4 Bc5 21.Nxe6 Qxe6 (785.616) 420

9/31 0:02 +0.38 17.Ne3 Be6 18.Nxg2 g5 19.Bg3 Bc5
20.Nd4 Bxd4 21.Rxd4 Kb8 22.Ne3 (878.661) 411

9/38 0:10 +0.58 17.Qe3 c5 18.Kxg2 b5 19.Na5 Rh3
20.Bg3 fxe5 21.Qd3 Nf6 22.Nxe5 Bxd1
23.Kxh3 (4.516.098) 429

10/38 0:12 +0.88 17.Qe3 c5 18.Bg3 g5 19.Kxg2 Rh5
20.Kg1 Kb8 21.exf6 Nxf6 22.e5 Nh7
23.a4 Qf7 24.Rd8+ Bc8 (5.459.949) 429

11/38 0:18 +0.48 17.Qe3 c5 18.Bg3 Bh3 19.exf6 gxf6
20.Qf4 Rh7 21.Nh4 Bh6 22.Qf3 Re7 (7.883.683) 430

12/38 0:36 +0.64 17.Qe3 c5 18.Kxg2 Rh5 19.exf6 Nxf6
20.Bxc7 Qxe4 21.Qxe4 Nxe4 22.Be5 b5
23.Re1 Bh3+ 24.Kg1 Bf5 25.Nb6+ Kb7 (16.083.851) 439

13/42 1:52 +1.36 17.Qe3 Bxf3 18.Qxf3 Qe6 19.Kxg2 fxe5
20.Nxe5 Bd6 21.Nd3 Be7 22.Be5 Kb8
23.Qg3 Nf6 24.Bxc7+ Ka8 25.f3 (51.116.691) 453

14/52 3:34 +0.89 17.Qe3 Bxf3 18.Qxf3 Qe6 19.Kxg2 fxe5
20.Nxe5 Bd6 21.Nd3 Ne7 22.Kg1 Rh3
23.Bg3 Ng6 24.a4 Nh4 25.Qe3 (99.286.232) 462

15/52 7:48 +1.08 17.Qe3 Bxf3 18.Qxf3 Qe6 19.Qe3 c5
20.Qf3 fxe5 21.Bxe5 Nf6 22.Qxg2 Rh5
23.Bxf6 gxf6 24.Kf1 Bd6 25.Rd5 Rh4
26.f3 Bxh2 27.Rxc5 (220.069.909) 469

16/52 17:47 +0.94 17.Qe3 Bxf3 18.Qxf3 Qe6 19.Qe3 c5
20.Qf3 Ne7 21.exf6 gxf6 22.Kxg2 Nc6
23.c3 Bh6 24.Bxh6 Rxh6 25.Qf5 Qxf5
26.exf5 Rh7 27.Kg3 Rg7+ 28.Kf4 (502.270.116) 470

17/62 53:15 +1.09 17.Qe3 Bxf3 18.Qxf3 Qe6 19.Qe3 c5
20.Qf3 fxe5 21.Bxe5 Nf6 22.Qxg2 Rh5
23.Kf1 Rxe5 24.Nxe5 Qxe5 25.Qh3+ Kb8
26.Rd8+ Ka7 27.Rxf8 Qxe4 28.Qd3 Qh1+
29.Ke2 Qxh2 30.Qe3 (1.497.463.158) 468

17/66 216:24 +1.10 17.e6 Qxe6 18.Bxc7 Nh6 19.Bf4 Bc5
20.b4 g5 21.Bg3 b5 22.Nd6+ Bxd6
23.Rxd6 Qe8 24.Qd3 Kb7 25.Nd4 Nf7
26.Rxf6 Ne5 27.Qa3 Qe7 (6.334.148.946) 487

Eelco

Eelco de Groot · Post by **Eelco de Groot** » Tue Apr 08, 2008 1:46 pm

It took a while to get an 18 ply result, the qsearch is a bit expensive, test has become an endurance test to see if there actually would be a result without crashes or exploding searches:

.
.
17/62 53:15 +1.09 17.Qe3 Bxf3 18.Qxf3 Qe6 19.Qe3 c5
20.Qf3 fxe5 21.Bxe5 Nf6 22.Qxg2 Rh5
23.Kf1 Rxe5 24.Nxe5 Qxe5 25.Qh3+ Kb8
26.Rd8+ Ka7 27.Rxf8 Qxe4 28.Qd3 Qh1+
29.Ke2 Qxh2 30.Qe3 (1.497.463.158) 468

17/66 216:24 +1.10 17.e6 Qxe6 18.Bxc7 Nh6 19.Bf4 Bc5
20.b4 g5 21.Bg3 b5 22.Nd6+ Bxd6
23.Rxd6 Qe8 24.Qd3 Kb7 25.Nd4 Nf7
26.Rxf6 Ne5 27.Qa3 Qe7 (6.334.148.946) 487

18/67 633:40 +2.56 17.e6 Qxe6 18.Bxc7 Bc5 19.Bb6 Bxb6
20.Nxb6+ Kb8 21.Rd8+ Kc7 22.Rc8+ Qxc8
23.Nxc8 Kxc8 24.Kxg2 Nh6 25.Qe3 Bxf3+
26.Qxf3 Rd8 27.Qg3 Rd7 28.h4 b5
29.c4 Kb7 30.c5 (18.682.625.988) 491

bob · Post by **bob** » Tue Apr 08, 2008 6:02 pm

Eelco de Groot wrote:Yes! 17. e6 looks very good too, and Rybka finds it very fast. Thanks! I don't know if Toga rates e6 as much better or somewhat equal to Qe3, it was still calculating at 17 ply, you guessed it, trying to resolve 17. e6. But I think there is a problem with the QSearch again, hash is already 100% so I am not 100% sure what it is, but resolving e6 takes too long.

Anyway, the fact that Rybka has no problems here I think illustrates it has a superior quiescence search. We have all known since day one of Rybka 1.0 that the reported nodecounts where not correct, because the numbers did not vary with the amount of hash, I don't know anymore who actually posted that first but it was not a secret for longer than a day... We have also known for a long time that probably meant Rybka was searching very deeply and that the PV did not show the quiescence search.

No need to do any decompiling for that, I don't agree with this method but in some countries the legal definitions and "acceptable" forms of decompiling, reverse engineering are different than in others I suppose, if there is any legal definition at all as legislation is slow to change. Don't want to go into that but as the obfuscated nodecount has come up again, I think it is more interesting to see I think where other programmers and programmers are finally trying to catch up with the early Rybkas, I think for a part the Q-Search is key and I hope programmers will find their own way instead of playing copycat from the Strelka-code. There is such a thing as honour even among programmers It is enough to know that it can be done.

About this "node count obfuscation", and if that is really all that it is, another reason for not counting all nodes could simply be that you want to separate Search and QSearch, and a more meaningful number in trying to keep the search within bounds is the amount of QSearches done in a search. I don't know if that is the case with Ryka or if that was Vas' thinking in desiging this form of output, but it has some logic to it I think.

My five cents,
Eelco

There is a reason for the obfuscation, and it is pretty obvious. Nobody would use a _slower_ way to count nodes. And nobody would exclude nodes unless there was a concrete reason for doing so. I count 'em all, because it is a critical debugging tool. If you make a speed optimization to the q-search, and the node count changes, the optimization broke something. Do you expect me to believe that he can't make use of this classic debugging technique?

I don't think so...

michiguel · Post by **michiguel** » Tue Apr 08, 2008 7:12 pm

bob wrote:
Eelco de Groot wrote:Yes! 17. e6 looks very good too, and Rybka finds it very fast. Thanks! I don't know if Toga rates e6 as much better or somewhat equal to Qe3, it was still calculating at 17 ply, you guessed it, trying to resolve 17. e6. But I think there is a problem with the QSearch again, hash is already 100% so I am not 100% sure what it is, but resolving e6 takes too long.

Anyway, the fact that Rybka has no problems here I think illustrates it has a superior quiescence search. We have all known since day one of Rybka 1.0 that the reported nodecounts where not correct, because the numbers did not vary with the amount of hash, I don't know anymore who actually posted that first but it was not a secret for longer than a day... We have also known for a long time that probably meant Rybka was searching very deeply and that the PV did not show the quiescence search.

No need to do any decompiling for that, I don't agree with this method but in some countries the legal definitions and "acceptable" forms of decompiling, reverse engineering are different than in others I suppose, if there is any legal definition at all as legislation is slow to change. Don't want to go into that but as the obfuscated nodecount has come up again, I think it is more interesting to see I think where other programmers and programmers are finally trying to catch up with the early Rybkas, I think for a part the Q-Search is key and I hope programmers will find their own way instead of playing copycat from the Strelka-code. There is such a thing as honour even among programmers It is enough to know that it can be done.

About this "node count obfuscation", and if that is really all that it is, another reason for not counting all nodes could simply be that you want to separate Search and QSearch, and a more meaningful number in trying to keep the search within bounds is the amount of QSearches done in a search. I don't know if that is the case with Ryka or if that was Vas' thinking in desiging this form of output, but it has some logic to it I think.

My five cents,
Eelco
There is a reason for the obfuscation, and it is pretty obvious. Nobody would use a _slower_ way to count nodes. And nobody would exclude nodes unless there was a concrete reason for doing so. I count 'em all, because it is a critical debugging tool. If you make a speed optimization to the q-search, and the node count changes, the optimization broke something. Do you expect me to believe that he can't make use of this classic debugging technique? I don't think so...

How do you know he is not using it?
You know that things that are disallowed with preprocessor #if are not going to be observed in the code.

Miguel

bob · Post by **bob** » Tue Apr 08, 2008 7:34 pm

michiguel wrote:
bob wrote:
Eelco de Groot wrote:Yes! 17. e6 looks very good too, and Rybka finds it very fast. Thanks! I don't know if Toga rates e6 as much better or somewhat equal to Qe3, it was still calculating at 17 ply, you guessed it, trying to resolve 17. e6. But I think there is a problem with the QSearch again, hash is already 100% so I am not 100% sure what it is, but resolving e6 takes too long.

Anyway, the fact that Rybka has no problems here I think illustrates it has a superior quiescence search. We have all known since day one of Rybka 1.0 that the reported nodecounts where not correct, because the numbers did not vary with the amount of hash, I don't know anymore who actually posted that first but it was not a secret for longer than a day... We have also known for a long time that probably meant Rybka was searching very deeply and that the PV did not show the quiescence search.

No need to do any decompiling for that, I don't agree with this method but in some countries the legal definitions and "acceptable" forms of decompiling, reverse engineering are different than in others I suppose, if there is any legal definition at all as legislation is slow to change. Don't want to go into that but as the obfuscated nodecount has come up again, I think it is more interesting to see I think where other programmers and programmers are finally trying to catch up with the early Rybkas, I think for a part the Q-Search is key and I hope programmers will find their own way instead of playing copycat from the Strelka-code. There is such a thing as honour even among programmers It is enough to know that it can be done.

About this "node count obfuscation", and if that is really all that it is, another reason for not counting all nodes could simply be that you want to separate Search and QSearch, and a more meaningful number in trying to keep the search within bounds is the amount of QSearches done in a search. I don't know if that is the case with Ryka or if that was Vas' thinking in desiging this form of output, but it has some logic to it I think.

My five cents,
Eelco
There is a reason for the obfuscation, and it is pretty obvious. Nobody would use a _slower_ way to count nodes. And nobody would exclude nodes unless there was a concrete reason for doing so. I count 'em all, because it is a critical debugging tool. If you make a speed optimization to the q-search, and the node count changes, the optimization broke something. Do you expect me to believe that he can't make use of this classic debugging technique? I don't think so...
How do you know he is not using it?
You know that things that are disallowed with preprocessor #if are not going to be observed in the code.

Miguel

You completely missed my point. Why would one actually count the nodes when debugging, and then suddenly not count some of them in the production code? There is but one realistic answer, that one does not want anyone to see the _real_ numbers because they might lead to discovery of "the secret"...

So, again, why would one use #ifdef's to remove code that has no effect on performance, but is useful for debugging, unless one wants to hide something? Why not just do something like:

printf("nodes: %d\n", random() * 500000 + constant * time used);

Then you display a non-constant nodes searched and have no search overhead for counting them at all. But why would you do that? You could just omit the number and not count 'em nor display anything at all. Why would you display an incorrect number? Why, indeed? It doesn't take Holmes to figure this one out, IMHO. If you don't want to show a number, don't show it. But don't show a made-up number in its place either... particularly when you use a very precisely defined term "nodes" in the output.

Medium difficulty testmove 17.Qe3

Medium difficulty testmove 17.Qe3

Re: Medium difficulty testmove 17.Qe3

Eelco what about e6!!

Re: Medium difficulty testmove 17.Qe3

Re: Eelco what about e6!!

Re: Eelco what about e6!!

Re: Eelco what about e6!!

Re: Eelco what about e6!!

Re: Eelco what about e6!!

Re: Eelco what about e6!!