1
2
I had fun two games last night vs. the mighty cluster.
On the first I believe I dropped a winning position to a draw. The second was an uneventful draw.
Here's the first:
[Event "Friendly Game, 60m + 15s"]
[Site "Engine Room"]
[Date "2009.10.25"]
[Round "?"]
[White "Highendman"]
[Black "Rechenschieber"]
[Result "1/2-1/2"]
[ECO "B49"]
[WhiteElo "2562"]
[PlyCount "90"]
[EventDate "2009.10.25"]
[TimeControl "3600+15"]
1. e4 {2} c5 {-0.05/1 0} 2. Nf3 {8} e6 {-0.05/1 0} 3. Nc3 {151} a6 {-0.05/1 0}
4. Be2 {66} Nc6 {-0.05/1 0} 5. d4 {83} cxd4 {-0.05/1 0} 6. Nxd4 {1} Qc7 {
-0.05/1 0} 7. O-O {131} Nf6 {-0.05/1 0} 8. Be3 {46} h5 {-0.05/1 0} 9. f4 {93}
d6 {-0.05/1 0} 10. a3 {66} Bd7 {-0.05/1 0} 11. Nb3 {70} Rc8 {-0.05/1 0} 12. Qd3
{160} Ne7 {0.19/19 224} 13. Rad1 {(Bd4) 256} d5 {0.05/19 232} 14. Nd4 {206} g6
{0.05/19 70} 15. f5 {(Bf3) 181} exf5 {0.60/17 308} 16. exf5 {(exd5) 47} Bg7 {
0.30/18 175} 17. Bf4 {(fxg6) 47} Qb6 {0.23/18 269} 18. fxg6 {183} fxg6 {
0.21/17 0} 19. Qe3 {81} Qc5 {0.46/18 0} 20. Qe5 {47} Rg8 {0.44/19 291} 21. Qe3
{94} Kf7 {0.59/17 13} 22. Be5 {125} Rge8 {0.75/18 41} 23. Bd3 {58} Nf5 {
0.71/19 68} 24. Nxf5 {28} Rxe5 {0.74/20 153} 25. Qxc5 {8} Rxc5 {0.75/21 11} 26.
Nh4 {23} g5 {0.74/20 274} 27. Nf3 {32} Re3 {0.84/18 161} 28. Nxg5+ {10} Kg8 {
0.84/19 181} 29. Rd2 {6} h4 {0.83/19 237} 30. Nf3 {(Rdf2) 360} h3 {0.63/18 135}
31. Ng5 {13} d4 {0.53/19 125} 32. Nce4 {8} Nxe4 {0.52/19 41} 33. Nxe4 {9} Rc6 {
0.56/21 112} 34. g3 {4} Bh6 {0.57/22 156} 35. Nf6+ {29} Rxf6 {0.56/23 53} 36.
Rxf6 {6} Re1+ {0.57/24 17} 37. Kf2 {7} Bxd2 {0.57/24 4} 38. Bc4+ {6} Kg7 {
0.56/25 163} 39. Rf7+ {5} Kh8 {0.56/25 77} 40. Rxd7 {10} Rh1 {0.58/24 16} 41.
Kf3 {(Bd3) 15} Rxh2 {0.57/24 108} 42. Bd3 {7} b5 {0.57/24 111} 43. a4 {(b3) 7}
Be3 {0.38/22 96} 44. axb5 {31} axb5 {0.45/21 0} 45. Kg4 {(g4) 203} b4 {
Highendman offers a draw (Lag: Av=0.49s, max=1.7s) 0.38/23 60} 1/2-1/2
An interesting position is move 15 by white:
Interesting, imho, that the Cluster pruned out and didn't consider 15. f5 - instead it was expecting bf3. Before it gave the position 0.05 eval, but after 15. f5! it's eval jumped to 0.6 for white.
From my side, while the engines didn't consider f5, it's sort of an obvious thematic move for a human white - I played it without hardly analysing it - the position just asked for it.
I do believe, after some further analysis post game, that white should win after that move.
And where I dropped a possible win was move 30. Nf3? instead of the more obvious Rdf2 - my engine wanted rdf2, but I didn't like the end-game and wanted to simplify to something 'easier' and played the wrong move. Mental blackout I guess. Just shows again how difficult it is to win won positions :)
Anyway was lots of fun crossing swords again with the new and improved Cluster. I hope to get a chance to play few more games when Lukas's schedule allows.
Lukas - thanks again for your time - was a lovely evening for me despite that move 30 that keeps chasing me all night and on my way to work this morning ;)
On the first I believe I dropped a winning position to a draw. The second was an uneventful draw.
Here's the first:
[Event "Friendly Game, 60m + 15s"]
[Site "Engine Room"]
[Date "2009.10.25"]
[Round "?"]
[White "Highendman"]
[Black "Rechenschieber"]
[Result "1/2-1/2"]
[ECO "B49"]
[WhiteElo "2562"]
[PlyCount "90"]
[EventDate "2009.10.25"]
[TimeControl "3600+15"]
1. e4 {2} c5 {-0.05/1 0} 2. Nf3 {8} e6 {-0.05/1 0} 3. Nc3 {151} a6 {-0.05/1 0}
4. Be2 {66} Nc6 {-0.05/1 0} 5. d4 {83} cxd4 {-0.05/1 0} 6. Nxd4 {1} Qc7 {
-0.05/1 0} 7. O-O {131} Nf6 {-0.05/1 0} 8. Be3 {46} h5 {-0.05/1 0} 9. f4 {93}
d6 {-0.05/1 0} 10. a3 {66} Bd7 {-0.05/1 0} 11. Nb3 {70} Rc8 {-0.05/1 0} 12. Qd3
{160} Ne7 {0.19/19 224} 13. Rad1 {(Bd4) 256} d5 {0.05/19 232} 14. Nd4 {206} g6
{0.05/19 70} 15. f5 {(Bf3) 181} exf5 {0.60/17 308} 16. exf5 {(exd5) 47} Bg7 {
0.30/18 175} 17. Bf4 {(fxg6) 47} Qb6 {0.23/18 269} 18. fxg6 {183} fxg6 {
0.21/17 0} 19. Qe3 {81} Qc5 {0.46/18 0} 20. Qe5 {47} Rg8 {0.44/19 291} 21. Qe3
{94} Kf7 {0.59/17 13} 22. Be5 {125} Rge8 {0.75/18 41} 23. Bd3 {58} Nf5 {
0.71/19 68} 24. Nxf5 {28} Rxe5 {0.74/20 153} 25. Qxc5 {8} Rxc5 {0.75/21 11} 26.
Nh4 {23} g5 {0.74/20 274} 27. Nf3 {32} Re3 {0.84/18 161} 28. Nxg5+ {10} Kg8 {
0.84/19 181} 29. Rd2 {6} h4 {0.83/19 237} 30. Nf3 {(Rdf2) 360} h3 {0.63/18 135}
31. Ng5 {13} d4 {0.53/19 125} 32. Nce4 {8} Nxe4 {0.52/19 41} 33. Nxe4 {9} Rc6 {
0.56/21 112} 34. g3 {4} Bh6 {0.57/22 156} 35. Nf6+ {29} Rxf6 {0.56/23 53} 36.
Rxf6 {6} Re1+ {0.57/24 17} 37. Kf2 {7} Bxd2 {0.57/24 4} 38. Bc4+ {6} Kg7 {
0.56/25 163} 39. Rf7+ {5} Kh8 {0.56/25 77} 40. Rxd7 {10} Rh1 {0.58/24 16} 41.
Kf3 {(Bd3) 15} Rxh2 {0.57/24 108} 42. Bd3 {7} b5 {0.57/24 111} 43. a4 {(b3) 7}
Be3 {0.38/22 96} 44. axb5 {31} axb5 {0.45/21 0} 45. Kg4 {(g4) 203} b4 {
Highendman offers a draw (Lag: Av=0.49s, max=1.7s) 0.38/23 60} 1/2-1/2
An interesting position is move 15 by white:
2r1kb1r/1pqbnp2/p3pnp1/3p1P1p/3NP3/P1NQB3/1PP1B1PP/3R1RK1 b k - 0 15
Interesting, imho, that the Cluster pruned out and didn't consider 15. f5 - instead it was expecting bf3. Before it gave the position 0.05 eval, but after 15. f5! it's eval jumped to 0.6 for white.
From my side, while the engines didn't consider f5, it's sort of an obvious thematic move for a human white - I played it without hardly analysing it - the position just asked for it.
I do believe, after some further analysis post game, that white should win after that move.
And where I dropped a possible win was move 30. Nf3? instead of the more obvious Rdf2 - my engine wanted rdf2, but I didn't like the end-game and wanted to simplify to something 'easier' and played the wrong move. Mental blackout I guess. Just shows again how difficult it is to win won positions :)
Anyway was lots of fun crossing swords again with the new and improved Cluster. I hope to get a chance to play few more games when Lukas's schedule allows.
Lukas - thanks again for your time - was a lovely evening for me despite that move 30 that keeps chasing me all night and on my way to work this morning ;)
![[de]](/mwf/v12/flags/de.png "Germany")
My impression is that you could already have won earlier. What does black play after simply 16.exd5? ...Nxd5 17.Nxd5 Nxd5 18.Bf3 doesn't seem to work, and if black doesn't take on d5, his position is horrible.
Of course Rybka on that cluster is extremely strong. But given this, it's even more surprising how bad it is capable of playing. The idea to play 12...Ne7 and 13...d5 looks just silly.
Anyway, congratulations. You seem to be an uncomfortable opponent for the cluster, and consistently so.
Of course Rybka on that cluster is extremely strong. But given this, it's even more surprising how bad it is capable of playing. The idea to play 12...Ne7 and 13...d5 looks just silly.
Anyway, congratulations. You seem to be an uncomfortable opponent for the cluster, and consistently so.
Very good Highendman!
I gave the position to Ancalagon Build 375 but I believe he is drowning in the complications. It finds 15. f5 after 9 minutes but then after a long think concludes that the cluster should have played 15... gxf5 instead of exf5. The score drops a lot when in PV-search, the first score could have been only the last fail high search. I don't really believe the 8 ply PV-search is correct but don't see why it behaves like that. It is very rare to see such a big drop in the evaluation unless the PV search is not deep enough, but it took 33 minutes so that is not the explanation I think.
Engine: Ancalagon 1.3 Weak Squares 180 Board Control middlegame 50 endgame 50
Build 375 (Athlon 2009 MHz, 16 MB) by Romstad, Costalba, Kiiski, de Groot
2.00 0:04 +1.25 15.Nf3 Nxe4 (1.758.755) 410
3.01 1:21 +0.37 15.Nf3 Nxe4 16.Nxe4 dxe4 17.Qxe4 Nf5
18.Bf2 Bc5 19.Ne5 Bc6 20.Nxc6 Qxc6
21.Qxc6+ Rxc6 22.Bf3 Bxf2+ 23.Rxf2 Rc7
24.Rfd2 Ke7 25.Kf2 Rhc8 (34.568.156) 422
3.02 1:26 +0.63 15.Rf3 dxe4 16.Nxe4 Ned5 17.Nxf6+ Nxf6
18.c4 Be7 19.Nb3 Bc6 20.Rff1 O-O (36.312.275) 420
3.04 1:49 +1.15 15.Bf2 dxe4 16.Nxe4 Nxe4 17.Qxe4 f5
18.Qf3 Bg7 19.c3 O-O 20.Bh4 Bf6
21.Bxf6 Rxf6 (45.888.121) 418
4.01 3:28 +1.02 15.Bf2 Bg7 16.e5 Ng4 17.Bxg4 hxg4
18.Qg3 Nf5 19.Qxg4 Nxd4 20.Rxd4 O-O (84.568.986) 406
5.01 4:06 +0.94 15.Bf2 Bg7 16.e5 Ng4 17.Bxg4 hxg4
18.Qg3 Bf8 19.Qxg4 Nf5 20.Nxf5 gxf5
21.Qf3 Qc4 (99.798.033) 404
6.01 5:32 +0.81 15.Bf2 dxe4 16.Nxe4 Bg7 17.Nxe6 Bxe6
18.Nd6+ Kf8 19.Nxc8 Nxc8 20.Bf3 Ng4
21.Qd8+ Qxd8 22.Rxd8+ Ke7 23.Rxh8 Bxh8
24.Bc5+ Ke8 25.Bxb7 Bxb2 26.Bxa6 (133.456.045) 401
7.01 9:00 +0.61 15.Bf2 dxe4 (215.223.468) 398
7.02 9:17 +1.15 15.f5 (221.422.031) 397
8.01 32:54 +0.29 15.f5 gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Kh1 O-O 19.Nb3 Qd6 20.Bf4 e5
21.Bg5 Qe6 22.Bxf6 Rxf6 23.Rxf6 Bxf6
24.Bxh5 e4 25.Nxe4 dxe4 26.Qxd7 Qxd7
27.Rxd7 Rxc2 28.Rxb7 (715.474.909) 362
8.02 35:11 +0.68 15.Bf2 dxe4 16.Nxe4 Nxe4 17.Qxe4 Bg7
18.Bf3 O-O 19.Qxb7 Qxb7 20.Bxb7 Rb8
21.Bxa6 Rxb2 22.Nf5 Nxf5 23.Rxd7 Ra8
24.Bd3 Rxa3 (767.505.544) 363
I now see that Ancalagon only had 16 Mb for the transposition tables but that should not make much difference, just slows it down.
Eelco
I gave the position to Ancalagon Build 375 but I believe he is drowning in the complications. It finds 15. f5 after 9 minutes but then after a long think concludes that the cluster should have played 15... gxf5 instead of exf5. The score drops a lot when in PV-search, the first score could have been only the last fail high search. I don't really believe the 8 ply PV-search is correct but don't see why it behaves like that. It is very rare to see such a big drop in the evaluation unless the PV search is not deep enough, but it took 33 minutes so that is not the explanation I think.
2r1kb1r/1pqbnp2/p3pnp1/3p3p/3NPP2/P1NQB3/1PP1B1PP/3R1RK1 w k -
Engine: Ancalagon 1.3 Weak Squares 180 Board Control middlegame 50 endgame 50
Build 375 (Athlon 2009 MHz, 16 MB) by Romstad, Costalba, Kiiski, de Groot
2.00 0:04 +1.25 15.Nf3 Nxe4 (1.758.755) 410
3.01 1:21 +0.37 15.Nf3 Nxe4 16.Nxe4 dxe4 17.Qxe4 Nf5
18.Bf2 Bc5 19.Ne5 Bc6 20.Nxc6 Qxc6
21.Qxc6+ Rxc6 22.Bf3 Bxf2+ 23.Rxf2 Rc7
24.Rfd2 Ke7 25.Kf2 Rhc8 (34.568.156) 422
3.02 1:26 +0.63 15.Rf3 dxe4 16.Nxe4 Ned5 17.Nxf6+ Nxf6
18.c4 Be7 19.Nb3 Bc6 20.Rff1 O-O (36.312.275) 420
3.04 1:49 +1.15 15.Bf2 dxe4 16.Nxe4 Nxe4 17.Qxe4 f5
18.Qf3 Bg7 19.c3 O-O 20.Bh4 Bf6
21.Bxf6 Rxf6 (45.888.121) 418
4.01 3:28 +1.02 15.Bf2 Bg7 16.e5 Ng4 17.Bxg4 hxg4
18.Qg3 Nf5 19.Qxg4 Nxd4 20.Rxd4 O-O (84.568.986) 406
5.01 4:06 +0.94 15.Bf2 Bg7 16.e5 Ng4 17.Bxg4 hxg4
18.Qg3 Bf8 19.Qxg4 Nf5 20.Nxf5 gxf5
21.Qf3 Qc4 (99.798.033) 404
6.01 5:32 +0.81 15.Bf2 dxe4 16.Nxe4 Bg7 17.Nxe6 Bxe6
18.Nd6+ Kf8 19.Nxc8 Nxc8 20.Bf3 Ng4
21.Qd8+ Qxd8 22.Rxd8+ Ke7 23.Rxh8 Bxh8
24.Bc5+ Ke8 25.Bxb7 Bxb2 26.Bxa6 (133.456.045) 401
7.01 9:00 +0.61 15.Bf2 dxe4 (215.223.468) 398
7.02 9:17 +1.15 15.f5 (221.422.031) 397
8.01 32:54 +0.29 15.f5 gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Kh1 O-O 19.Nb3 Qd6 20.Bf4 e5
21.Bg5 Qe6 22.Bxf6 Rxf6 23.Rxf6 Bxf6
24.Bxh5 e4 25.Nxe4 dxe4 26.Qxd7 Qxd7
27.Rxd7 Rxc2 28.Rxb7 (715.474.909) 362
8.02 35:11 +0.68 15.Bf2 dxe4 16.Nxe4 Nxe4 17.Qxe4 Bg7
18.Bf3 O-O 19.Qxb7 Qxb7 20.Bxb7 Rb8
21.Bxa6 Rxb2 22.Nf5 Nxf5 23.Rxd7 Ra8
24.Bd3 Rxa3 (767.505.544) 363
I now see that Ancalagon only had 16 Mb for the transposition tables but that should not make much difference, just slows it down.
Eelco
Stays with 15. Bf2
8.02 35:11 +0.68 15.Bf2 dxe4 16.Nxe4 Nxe4 17.Qxe4 Bg7
18.Bf3 O-O 19.Qxb7 Qxb7 20.Bxb7 Rb8
21.Bxa6 Rxb2 22.Nf5 Nxf5 23.Rxd7 Ra8
24.Bd3 Rxa3 (767.505.544) 363
9.01 75:10 +0.61 15.Bf2 dxe4 16.Nxe4 Bg7 17.Nxe6 Bxe6
18.Nd6+ Kf8 19.Nxc8 Qxc8 20.Qd8+ Ne8
21.c3 Bf6 22.Qb6 Kg7 23.Bf3 Nc6
24.Bd5 Bxd5 25.Rxd5 Nc7 26.Rdd1 Re8 (1.679.302.654) 372
10.01 135:26 +0.62 15.Bf2 dxe4 16.Nxe4 Nxe4 17.Qxe4 Bg7
18.Bf3 O-O 19.Qxb7 Qxb7 20.Bxb7 Rb8
21.Bxa6 Rxb2 22.Nf5 Nxf5 23.Rxd7 Rxc2
24.Bd3 Rcc8 25.Rb1 Rfd8 26.Rxd8+ Rxd8
27.Rb3 Nd4 (3.021.443.812) 371
8.02 35:11 +0.68 15.Bf2 dxe4 16.Nxe4 Nxe4 17.Qxe4 Bg7
18.Bf3 O-O 19.Qxb7 Qxb7 20.Bxb7 Rb8
21.Bxa6 Rxb2 22.Nf5 Nxf5 23.Rxd7 Ra8
24.Bd3 Rxa3 (767.505.544) 363
9.01 75:10 +0.61 15.Bf2 dxe4 16.Nxe4 Bg7 17.Nxe6 Bxe6
18.Nd6+ Kf8 19.Nxc8 Qxc8 20.Qd8+ Ne8
21.c3 Bf6 22.Qb6 Kg7 23.Bf3 Nc6
24.Bd5 Bxd5 25.Rxd5 Nc7 26.Rdd1 Re8 (1.679.302.654) 372
10.01 135:26 +0.62 15.Bf2 dxe4 16.Nxe4 Nxe4 17.Qxe4 Bg7
18.Bf3 O-O 19.Qxb7 Qxb7 20.Bxb7 Rb8
21.Bxa6 Rxb2 22.Nf5 Nxf5 23.Rxd7 Rxc2
24.Bd3 Rcc8 25.Rb1 Rfd8 26.Rxd8+ Rxd8
27.Rb3 Nd4 (3.021.443.812) 371
To be honest I'm not really convinced that the Rybka Cluster sees anything real after 15. f5, although it does chose that move as Lukas posted in the cluster thread, if you look at the scores further in the game, it goes to 0.23 for White at move 17. Would 15... gxf5 not have been better than exf5? Ancalagon does not want to play 15. f5 but I do have a version that prefers 15. Bf3 instead of Bf2.
Engine: Ancalagon 1.3 Weak Squares 180 Board Control middlegame 50 endgame 50
Build 377 (Athlon 2009 MHz, 256 MB) by Romstad, Costalba, Kiiski, de Groot
2.00 0:05 +1.25 15.Nf3 dxe4 (2.287.877) 428
3.01 1:13 +0.15 15.Nf3 dxe4 16.Nxe4 Nxe4 17.Qxe4 Nf5
18.Bf2 Bd6 19.Nh4 Bc6 20.Nxf5 gxf5
21.Qd4 Rg8 22.Bg3 Bd5 23.Bf3 (32.671.427) 446
3.02 1:16 +0.54 15.a4 dxe4 16.Nxe4 Nxe4 17.Qxe4 Bg7
18.Bf3 Rb8 19.Nb3 O-O 20.Bc5 Bc6 (34.162.440) 446
3.11 1:26 +0.70 15.Rf3 dxe4 16.Nxe4 Nxe4 17.Qxe4 Bg7
18.Bf2 O-O 19.Rc3 Qb8 20.Rxc8 Rxc8 (38.621.076) 445
3.24 1:35 +0.76 15.Rfe1 Bg7 16.e5 Ng4 17.Nb3 Nxe3
18.Qxe3 (42.122.848) 442
4.01 1:44 +0.50 15.Rfe1 Bg7 16.e5 Ng4 17.Bxg4 hxg4
18.Qe2 g3 19.hxg3 Kf8 20.Qg4 (45.989.113) 440
4.05 1:49 +0.56 15.g3 dxe4 16.Nxe4 Nxe4 17.Qxe4 Bg7
18.Bf3 h4 19.Qxb7 Qxb7 20.Bxb7 Rb8
21.Bxa6 Rxb2 22.Rb1 Rxb1 23.Rxb1 hxg3
24.hxg3 (48.276.678) 440
4.07 2:20 +1.01 15.Bf2 dxe4 16.Nxe4 Ned5 17.Nxf6+ Nxf6
18.Qb3 b5 19.Bh4 Be7 20.Bf3 O-O (61.495.253) 438
5.01 4:16 +0.66 15.Bf2 dxe4 16.Nxe4 Bg7 17.Bh4 Ned5
18.c4 Nxe4 19.Qxe4 Nf6 20.Qd3 O-O
21.b3 e5 22.fxe5 Qxe5 (111.628.638) 434
5.15 4:31 +0.78 15.Bf3 Bg7 16.Nb3 O-O 17.Bc5 Bc6
18.e5 Ng4 (117.722.100) 433
6.01 9:17 +0.87 15.Bf3 Qc4 16.Nb3 Qxd3 17.cxd3 Bg7
18.Bd4 O-O 19.Rc1 Nc6 20.Bc5 Rfe8
21.e5 Ng4 22.h3 Nh6 23.g4 Na5
24.Nxa5 Rxc5 25.Nxb7 (238.805.647) 428
7.01 11:25 +0.89 15.Bf3 Qc4 16.Nb3 Qxd3 17.cxd3 Bg7
18.Bd4 O-O 19.Rfe1 Rfe8 20.e5 Ng4
21.h3 Nh6 22.g4 hxg4 23.hxg4 (293.922.138) 428
8.01 13:16 +0.88 15.Bf3 Qc4 16.h3 Qxd3 17.cxd3 Bh6
18.Nc2 O-O 19.g3 Bg7 20.Rf2 Bc6
21.e5 Nd7 22.b3 (342.375.360) 429
9.01 48:27 +0.85 15.Bf3 dxe4 16.Nxe4 Bg7 17.Nc5 Nfd5
18.Bxd5 Nxd5 19.Nxd7 Qxd7 20.f5 gxf5
21.Nxf5 exf5 22.Bd4 f6 23.Rfe1+ Kf8
24.Bf2 Qc6 25.Qxd5 Qxd5 26.Rxd5 Rxc2 (1.207.655.707) 415
10.01 69:37 +0.70 15.Bf3 dxe4 16.Nxe4 Ned5 17.Rfe1 Nxe4
18.Bxe4 Nxe3 19.Rxe3 Bc5 20.Kh1 Rg8
21.c4 Rd8 22.b4 Be7 23.Qc3 Ba4 (1.728.710.589) 413
I only had limited hardware available and I did not let the analysis run long enough to compensate. Maybe somebody with Rybka or a Hippo :)?
2r1kb1r/1pqbnp2/p3pnp1/3p3p/3NPP2/P1NQB3/1PP1B1PP/3R1RK1 w k -
Engine: Ancalagon 1.3 Weak Squares 180 Board Control middlegame 50 endgame 50
Build 377 (Athlon 2009 MHz, 256 MB) by Romstad, Costalba, Kiiski, de Groot
2.00 0:05 +1.25 15.Nf3 dxe4 (2.287.877) 428
3.01 1:13 +0.15 15.Nf3 dxe4 16.Nxe4 Nxe4 17.Qxe4 Nf5
18.Bf2 Bd6 19.Nh4 Bc6 20.Nxf5 gxf5
21.Qd4 Rg8 22.Bg3 Bd5 23.Bf3 (32.671.427) 446
3.02 1:16 +0.54 15.a4 dxe4 16.Nxe4 Nxe4 17.Qxe4 Bg7
18.Bf3 Rb8 19.Nb3 O-O 20.Bc5 Bc6 (34.162.440) 446
3.11 1:26 +0.70 15.Rf3 dxe4 16.Nxe4 Nxe4 17.Qxe4 Bg7
18.Bf2 O-O 19.Rc3 Qb8 20.Rxc8 Rxc8 (38.621.076) 445
3.24 1:35 +0.76 15.Rfe1 Bg7 16.e5 Ng4 17.Nb3 Nxe3
18.Qxe3 (42.122.848) 442
4.01 1:44 +0.50 15.Rfe1 Bg7 16.e5 Ng4 17.Bxg4 hxg4
18.Qe2 g3 19.hxg3 Kf8 20.Qg4 (45.989.113) 440
4.05 1:49 +0.56 15.g3 dxe4 16.Nxe4 Nxe4 17.Qxe4 Bg7
18.Bf3 h4 19.Qxb7 Qxb7 20.Bxb7 Rb8
21.Bxa6 Rxb2 22.Rb1 Rxb1 23.Rxb1 hxg3
24.hxg3 (48.276.678) 440
4.07 2:20 +1.01 15.Bf2 dxe4 16.Nxe4 Ned5 17.Nxf6+ Nxf6
18.Qb3 b5 19.Bh4 Be7 20.Bf3 O-O (61.495.253) 438
5.01 4:16 +0.66 15.Bf2 dxe4 16.Nxe4 Bg7 17.Bh4 Ned5
18.c4 Nxe4 19.Qxe4 Nf6 20.Qd3 O-O
21.b3 e5 22.fxe5 Qxe5 (111.628.638) 434
5.15 4:31 +0.78 15.Bf3 Bg7 16.Nb3 O-O 17.Bc5 Bc6
18.e5 Ng4 (117.722.100) 433
6.01 9:17 +0.87 15.Bf3 Qc4 16.Nb3 Qxd3 17.cxd3 Bg7
18.Bd4 O-O 19.Rc1 Nc6 20.Bc5 Rfe8
21.e5 Ng4 22.h3 Nh6 23.g4 Na5
24.Nxa5 Rxc5 25.Nxb7 (238.805.647) 428
7.01 11:25 +0.89 15.Bf3 Qc4 16.Nb3 Qxd3 17.cxd3 Bg7
18.Bd4 O-O 19.Rfe1 Rfe8 20.e5 Ng4
21.h3 Nh6 22.g4 hxg4 23.hxg4 (293.922.138) 428
8.01 13:16 +0.88 15.Bf3 Qc4 16.h3 Qxd3 17.cxd3 Bh6
18.Nc2 O-O 19.g3 Bg7 20.Rf2 Bc6
21.e5 Nd7 22.b3 (342.375.360) 429
9.01 48:27 +0.85 15.Bf3 dxe4 16.Nxe4 Bg7 17.Nc5 Nfd5
18.Bxd5 Nxd5 19.Nxd7 Qxd7 20.f5 gxf5
21.Nxf5 exf5 22.Bd4 f6 23.Rfe1+ Kf8
24.Bf2 Qc6 25.Qxd5 Qxd5 26.Rxd5 Rxc2 (1.207.655.707) 415
10.01 69:37 +0.70 15.Bf3 dxe4 16.Nxe4 Ned5 17.Rfe1 Nxe4
18.Bxe4 Nxe3 19.Rxe3 Bc5 20.Kh1 Rg8
21.c4 Rd8 22.b4 Be7 23.Qc3 Ba4 (1.728.710.589) 413
I only had limited hardware available and I did not let the analysis run long enough to compensate. Maybe somebody with Rybka or a Hippo :)?
Vas wrote:
Some comments about your latest games from the epic series
1) In the game here, Rybka needs a really long time to understand 15. f5!! This is going to be tough even for Lukas' 72 cores. I know it's a little strange to have such trouble with such a thematic move, but that's search. This is just a good example of where the human intervention helps.
Thanks for the comments Vas! That is more interesting than all the other goings on. But back to the game, what exactly means "really long" in case of the cluster. Hours :)? And is the Rybka cluster able to divide work over the nodes if she has to go really deep? Well probably not, and if the cluster needs a very long time it could also be because it has a particular blind spot here. For the moment I'm not persuaded that the cluster played its defence correctly and judging from the analysis output 15... exf5 is 90% likely to have been a blunder! For a long time it is not among the four best moves anymore, in multi-PV. But I'm not good enough a player at all to judge about the other 10%, which would correspond to the chance the position still turns into White's favour with longer analysis. Also this is just an experimental version of Ancalagon and it is the first position tested after it was made today :) So, about 10% uncertain..
After 15. f5
Engine: Ancalagon 1.3 Weak Squares 180 Board Control middlegame 50 endgame 50
Build 382 (Athlon 2009 MHz, 256 MB) by Romstad, Costalba, Kiiski, de Groot
6 17:19 0.00 15...dxe4 16.Nxe4 Nxe4 17.Qxe4 gxf5
18.Qd3 Bg7 19.Bg5 Qb6 20.Be3 Qc7 (427.492.335) 411
6 17:19 -0.14 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Bxh5 Qb6 20.Bxf6 Rxf6
21.Rxf6 Bxf6 22.Qg3+ Kh7 23.Qf2 e5
24.Nde2 Qxf2+ 25.Kxf2 d4 26.Ne4 (427.492.335) 411
6 17:19 -0.91 15...Ng4 16.Bf4 e5 17.Bxg4 hxg4
18.f6 exf4 19.fxe7 Bxe7 20.Nxd5 Qc4
21.Qxc4 Rxc4 22.Nxe7 Kxe7 23.Rxf4 (427.492.335) 411
6 17:19 -1.15 15...Bg7 16.e5 Ng4 17.Bxg4 hxg4
18.f6 Bxf6 19.exf6 Qxh2+ 20.Kf2 Ng8
21.Rh1 Qxh1 22.Rxh1 Rxh1 23.Bg5 Rh5
24.Qe3 Kf8 (427.492.335) 411
___________________________________________________________________
7 35:49 +0.38 15...dxe4 16.Nxe4 Nxe4 17.Qxe4 gxf5
18.Qd3 Bg7 19.c4 Ng6 20.Qb3 f4
21.Bf2 Bf6 22.Nf3 O-O 23.Bd3 Bc6
24.Qc2 Bxf3 25.gxf3 Qe5 26.Rfe1 Qg5+
27.Kh1 (868.930.956) 404
7 35:49 -0.15 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Bxh5 Qb6 20.Bxf6 Rxf6
21.Nce2 Rcf8 22.Rxf6 Rxf6 23.Qg3 Qxb2 (868.930.956) 404
7 35:49 -0.77 15...Ng4 16.Bf4 e5 17.Bxg4 hxg4
18.f6 exf4 19.fxe7 Bg7 20.Nxd5 Qc4
21.c3 Qxd3 22.Rxd3 Be5 23.Nxf4 b6
24.g3 Bxf4 25.gxf4 Kxe7 (868.930.956) 404
7 35:49 -1.16 15...Bg7 16.fxe6 fxe6 17.Bg5 O-O
18.e5 Qxe5 19.Bf4 Rxc3 20.Bxe5 Rxd3
21.cxd3 Nh7 22.Rxf8+ Kxf8 23.Nf3 Bxe5
24.Nxe5 (868.930.956) 404
___________________________________________________________________
8 82:16 +0.41 15...dxe4 16.Nxe4 Nxe4 17.Qxe4 gxf5
18.Qd3 Bg7 19.Rf2 Ng6 20.Bg5 Be5
21.g3 f6 22.Be3 h4 23.g4 Bg3 24.Rg2 Nf4
25.Bxf4 Bxf4 26.gxf5 (1.949.314.323) 394
8 82:16 +0.01 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Qd2 Ng4 19.Bxg4 hxg4 20.Bf4 Qb6
21.Qe3 Rh5 22.Nce2 e5 23.Bg5 Qd6
24.Bxe7 exd4 25.Bxd6+ dxe3 26.c3 (1.949.314.323) 394
8 82:16 -0.57 15...Ng4 16.Bf4 e5 17.Bxg4 hxg4
18.f6 exf4 19.fxe7 Bg7 20.Nxd5 Qc4
21.Qxc4 Rxc4 22.c3 f3 23.gxf3 gxf3
24.Nb6 Bxd4+ 25.Rxd4 Rxd4 26.cxd4 Be6
27.Rxf3 (1.949.314.323) 394
8 82:16 -1.29 15...Bg7 16.e5 Ng4 17.Bxg4 hxg4
18.f6 Bxf6 19.exf6 Qxh2+ 20.Kf2 Ng8
21.Rh1 Qxh1 22.Rxh1 Rxh1 23.Bg5 Rh5
24.Qe3 Rc4 25.Nxd5 Rxg5 26.Qxg5 Rxd4 (1.949.314.323) 394
___________________________________________________________________
9 166:35 +0.64 15...dxe4 16.Nxe4 Nxe4 17.Qxe4 gxf5
18.Qd3 Bg7 19.Rd2 h4 20.Qb3 h3 21.g3 Be5
22.Kh1 O-O 23.Nf3 Bc6 24.Bb6 Qb8
25.Rfd1 f4 26.gxf4 Bxf4 (3.937.300.864) 393
9 166:35 0.00 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Nb3 Qd6 20.Bf4 e5
21.Bg5 Be8 22.Be3 Bg6 (3.937.300.864) 393
9 166:35 -0.58 15...Ng4 16.Bf4 e5 17.Bxg4 hxg4
18.f6 exf4 19.fxe7 Bg7 20.Nxd5 Qc4
21.Qxc4 Rxc4 22.c3 f3 23.gxf3 gxf3
24.Ne3 Rc5 25.Nxf3 Kxe7 26.Nd5+ Kd6 (3.937.300.864) 393
9 166:35 -1.93 15...Bg7 16.fxe6 fxe6 17.Bg5 Ng4
18.Bxg4 hxg4 19.g3 Qb6 20.Bxe7 Qxd4+
21.Qxd4 Bxd4+ 22.Rxd4 Kxe7 23.exd5 e5
24.Rb4 b5 25.Re4 Rh5 26.Ree1 Rch8 (3.937.300.864) 393
Some comments about your latest games from the epic series
1) In the game here, Rybka needs a really long time to understand 15. f5!! This is going to be tough even for Lukas' 72 cores. I know it's a little strange to have such trouble with such a thematic move, but that's search. This is just a good example of where the human intervention helps.
Thanks for the comments Vas! That is more interesting than all the other goings on. But back to the game, what exactly means "really long" in case of the cluster. Hours :)? And is the Rybka cluster able to divide work over the nodes if she has to go really deep? Well probably not, and if the cluster needs a very long time it could also be because it has a particular blind spot here. For the moment I'm not persuaded that the cluster played its defence correctly and judging from the analysis output 15... exf5 is 90% likely to have been a blunder! For a long time it is not among the four best moves anymore, in multi-PV. But I'm not good enough a player at all to judge about the other 10%, which would correspond to the chance the position still turns into White's favour with longer analysis. Also this is just an experimental version of Ancalagon and it is the first position tested after it was made today :) So, about 10% uncertain..
After 15. f5
2r1kb1r/1pqbnp2/p3pnp1/3p1P1p/3NP3/P1NQB3/1PP1B1PP/3R1RK1 b k -
Engine: Ancalagon 1.3 Weak Squares 180 Board Control middlegame 50 endgame 50
Build 382 (Athlon 2009 MHz, 256 MB) by Romstad, Costalba, Kiiski, de Groot
6 17:19 0.00 15...dxe4 16.Nxe4 Nxe4 17.Qxe4 gxf5
18.Qd3 Bg7 19.Bg5 Qb6 20.Be3 Qc7 (427.492.335) 411
6 17:19 -0.14 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Bxh5 Qb6 20.Bxf6 Rxf6
21.Rxf6 Bxf6 22.Qg3+ Kh7 23.Qf2 e5
24.Nde2 Qxf2+ 25.Kxf2 d4 26.Ne4 (427.492.335) 411
6 17:19 -0.91 15...Ng4 16.Bf4 e5 17.Bxg4 hxg4
18.f6 exf4 19.fxe7 Bxe7 20.Nxd5 Qc4
21.Qxc4 Rxc4 22.Nxe7 Kxe7 23.Rxf4 (427.492.335) 411
6 17:19 -1.15 15...Bg7 16.e5 Ng4 17.Bxg4 hxg4
18.f6 Bxf6 19.exf6 Qxh2+ 20.Kf2 Ng8
21.Rh1 Qxh1 22.Rxh1 Rxh1 23.Bg5 Rh5
24.Qe3 Kf8 (427.492.335) 411
___________________________________________________________________
7 35:49 +0.38 15...dxe4 16.Nxe4 Nxe4 17.Qxe4 gxf5
18.Qd3 Bg7 19.c4 Ng6 20.Qb3 f4
21.Bf2 Bf6 22.Nf3 O-O 23.Bd3 Bc6
24.Qc2 Bxf3 25.gxf3 Qe5 26.Rfe1 Qg5+
27.Kh1 (868.930.956) 404
7 35:49 -0.15 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Bxh5 Qb6 20.Bxf6 Rxf6
21.Nce2 Rcf8 22.Rxf6 Rxf6 23.Qg3 Qxb2 (868.930.956) 404
7 35:49 -0.77 15...Ng4 16.Bf4 e5 17.Bxg4 hxg4
18.f6 exf4 19.fxe7 Bg7 20.Nxd5 Qc4
21.c3 Qxd3 22.Rxd3 Be5 23.Nxf4 b6
24.g3 Bxf4 25.gxf4 Kxe7 (868.930.956) 404
7 35:49 -1.16 15...Bg7 16.fxe6 fxe6 17.Bg5 O-O
18.e5 Qxe5 19.Bf4 Rxc3 20.Bxe5 Rxd3
21.cxd3 Nh7 22.Rxf8+ Kxf8 23.Nf3 Bxe5
24.Nxe5 (868.930.956) 404
___________________________________________________________________
8 82:16 +0.41 15...dxe4 16.Nxe4 Nxe4 17.Qxe4 gxf5
18.Qd3 Bg7 19.Rf2 Ng6 20.Bg5 Be5
21.g3 f6 22.Be3 h4 23.g4 Bg3 24.Rg2 Nf4
25.Bxf4 Bxf4 26.gxf5 (1.949.314.323) 394
8 82:16 +0.01 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Qd2 Ng4 19.Bxg4 hxg4 20.Bf4 Qb6
21.Qe3 Rh5 22.Nce2 e5 23.Bg5 Qd6
24.Bxe7 exd4 25.Bxd6+ dxe3 26.c3 (1.949.314.323) 394
8 82:16 -0.57 15...Ng4 16.Bf4 e5 17.Bxg4 hxg4
18.f6 exf4 19.fxe7 Bg7 20.Nxd5 Qc4
21.Qxc4 Rxc4 22.c3 f3 23.gxf3 gxf3
24.Nb6 Bxd4+ 25.Rxd4 Rxd4 26.cxd4 Be6
27.Rxf3 (1.949.314.323) 394
8 82:16 -1.29 15...Bg7 16.e5 Ng4 17.Bxg4 hxg4
18.f6 Bxf6 19.exf6 Qxh2+ 20.Kf2 Ng8
21.Rh1 Qxh1 22.Rxh1 Rxh1 23.Bg5 Rh5
24.Qe3 Rc4 25.Nxd5 Rxg5 26.Qxg5 Rxd4 (1.949.314.323) 394
___________________________________________________________________
9 166:35 +0.64 15...dxe4 16.Nxe4 Nxe4 17.Qxe4 gxf5
18.Qd3 Bg7 19.Rd2 h4 20.Qb3 h3 21.g3 Be5
22.Kh1 O-O 23.Nf3 Bc6 24.Bb6 Qb8
25.Rfd1 f4 26.gxf4 Bxf4 (3.937.300.864) 393
9 166:35 0.00 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Nb3 Qd6 20.Bf4 e5
21.Bg5 Be8 22.Be3 Bg6 (3.937.300.864) 393
9 166:35 -0.58 15...Ng4 16.Bf4 e5 17.Bxg4 hxg4
18.f6 exf4 19.fxe7 Bg7 20.Nxd5 Qc4
21.Qxc4 Rxc4 22.c3 f3 23.gxf3 gxf3
24.Ne3 Rc5 25.Nxf3 Kxe7 26.Nd5+ Kd6 (3.937.300.864) 393
9 166:35 -1.93 15...Bg7 16.fxe6 fxe6 17.Bg5 Ng4
18.Bxg4 hxg4 19.g3 Qb6 20.Bxe7 Qxd4+
21.Qxd4 Bxd4+ 22.Rxd4 Kxe7 23.exd5 e5
24.Rb4 b5 25.Re4 Rh5 26.Ree1 Rch8 (3.937.300.864) 393
I think after 15...exf5 16.exd5 black's position may already be lost.
If I recall correctly, Highendman said during the game (before black's fifteenth move) that 15...gxf5 loses and that he expects Ng4. Maybe he (or Lukas) can shed some light on this.
If I recall correctly, Highendman said during the game (before black's fifteenth move) that 15...gxf5 loses and that he expects Ng4. Maybe he (or Lukas) can shed some light on this.
>And is the Rybka cluster able to divide work over the nodes if she has to go really deep?
What else should Rybka cluster use the nodes for?
>> And is the Rybka cluster able to divide work over the nodes if she has to go really deep?
> What else should Rybka cluster use the nodes for?
Hello Lukas,
Being no programmer I will just have to try to explain my thoughts loosely, I'll probably not use very correct terminology. What I meant was that a cluster can't share all the hash tables with all the other nodes and Vas stated himself somewhere on CCC it was I believe, that it is important, once you have build up transposition tables for one part of the searchtree, to keep working on those contents, deepening them as much as possible without destroying the information learned earlier.
So a node just can't do too much switching and in fact when information bandwith is limited will be have to be doing something much like multi-PV analysis, simply to be efficient. But if you want to go really deep, for a lot of the moves in the root it will become more and more certain that they are not best. Okay, at that point I assume it is safe to let a node that was doing work on the least favourable moves also take over some work on what is the PV. But you can't transfer all the hash contents from the "PV-node" to the "slave node"and also the hash in this slave node, that is needed for the move it was assigned to, has to stay intact as much as possible. All this means that even in deep analysis the cluster will to some extent still be operating in multi-PV mode, when maybe you would rather assign 50% of your resources, half of your nodes, solely to the PV at that point. Because the other moves become less interesting. Only with unlimited hash and full sharing across the nodes you could do that without a penalty I suppose. But in a cluster, when you go deeper the multi-PV character of the search is to some extent a limit on how deep you can search the PV.
Am I still making some sense?
Regards, Eelco
Okay, at that point I assume it is safe to let a node that was doing work on the least favourable moves also take over some work on what is the PV. But you can't transfer all the hash contents from the "PV-node" to the "slave node"and also the hash in this slave node, that is needed for the move it was assigned to, has to stay intact as much as possible.
I had not thought about this before but in the mentioned situation, where you would like to switch in a node, with "Preserve hash" that Rybka has it is probably possible to temporarily move all the transposition tables in the node to the local harddisk. That increases the possibilities for switching moves between nodes quite a bit I presume :) Clever solution from Vas :)!
Well, I'm sorry - I can't tell you how it really works ;)
But your thoughts are basically right.
But your thoughts are basically right.
![[pl]](/mwf/v12/flags/pl.png "Poland")
First paragraph - pretty good. Second paragraph - you lost me.
Lukas' cluster's tactical strength should be roughly proportional to its overall playing strength. There will be some differences, but they shouldn't be major.
Vas
Lukas' cluster's tactical strength should be roughly proportional to its overall playing strength. There will be some differences, but they shouldn't be major.
Vas
![[it]](/mwf/v12/flags/it.png "Italy")
> Engine: Ancalagon 1.3 Weak Squares 180 Board Control middlegame 50 endgame 50
> Build 382 (Athlon 2009 MHz, 256 MB) by Romstad, Costalba, Kiiski, de Groot
>
Sorry for the stupid question, but I don't want to open a new thread just to ask "what engine is Ancalagon?"
Is it freeware?
![[mx]](/mwf/v12/flags/mx.png "Mexico")
It's his private engine based on Glaurung's code.
![[us]](/mwf/v12/flags/us.png "United States")
He's going to run out of dragons soon...
Hello, no stupid question at all! Yes, in principle Ancalagon should of course be freeware, because it is a Stockfish 1.3 clone, possibly it could become a "fork" one day but for a fork or just a release I think it would have to justify that by having enough differences, or other functions etc. For now I'm afraid Ancalagon is very buggy and not fit for a release... I made too many changes for which I did not do any testing and apparently something went rather wrong, it is seeing false mates etc :( I'm also not in a big hurry to finish it, it is more of an experimental project, it is just a nuisance that I can't trust the analysis anymore. For analysis I have switched to 'Rainbow Serpent' which is just Stockfish 1.5 with very little change, just so I can have more reliable variations again. There is at the moment just a few lines difference, it is not much point releasing 'Rainbow Serpent' either... I just wanted to have my own [Deleted] version of Stockfish 1.5. Making the 2 line changes was a work of about five minutes this afternoon. Hopefully without adding bugs to Stockfish in those two new lines :)
In this Talkchess thread I wrote something about the plans for Ancalagon.
Regards,
Eelco
In this Talkchess thread I wrote something about the plans for Ancalagon.
Regards,
Eelco
9 166:35 +0.64 15...dxe4 16.Nxe4 Nxe4 17.Qxe4 gxf5
18.Qd3 Bg7 19.Rd2 h4 20.Qb3 h3 21.g3 Be5
22.Kh1 O-O 23.Nf3 Bc6 24.Bb6 Qb8
25.Rfd1 f4 26.gxf4 Bxf4 (3.937.300.864) 393
Sorry, it appears this version of Ancalagon is buggy and the analysis above can't be trusted. With a Stockfish 1.5 clone I get the line 15... gxf5 again but no +0.64. I still believe this does not really look worse for Black. If it turns out that Highendman had real advantage now against the cluster, and if the cluster had played a better move than 15... exf5? and it would still have gone down quickly, then Rainbow Serpent must have serious positional shortcomings for just displaying 0.00 or even +0.04. It could be, the threats to Black's King for instance are all long range threats that engines have difficulty scoring in the King Safety code.
Engine: Rainbow Serpent 1.5 (128 MB)
by Romstad, Costalba, Kiiski, De Groot
16.01 1:08 -0.04 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Bxf6 Rxf6 20.Rxf6 Bxf6
21.Bxh5 Qb6 22.Qg3+ Kh7 23.Qf2 e5
24.Nf3 Qxb2 25.Nxd5 Nxd5 26.Rxd5 (29.931.584) 433
17.01 2:12 -0.04 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Nb3 Qd6 20.Nd4 Qc7
21.Bf3 Qb6 22.Qe3 Ng6 23.Nb3 Qxe3+
24.Bxe3 Ng4 (58.367.574) 440
18.01 4:54 0.00 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Nb3 Qd6 20.Nd4 Qc7
21.Nb3 Qd6 (129.710.065) 441
19.01 10:50 +0.12 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Nb3 Qd6 20.Bf4 e5
21.Bg5 Be8 22.Qg3 Qe6 23.Bh6 Ng4
24.Rxf8+ Bxf8 25.Bxg4 hxg4 26.Bxf8 Kxf8 (289.364.600) 444
20.01 21:04 0.00 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Nb3 Qd6 20.Bf4 e5
21.Bg5 Qb6+ 22.Kh1 Be6 23.Bxf6 Bxf6
24.Qg3+ Kh8 25.Bxh5 e4 26.Qf4 Bg7
27.Qg5 (571.625.906) 451
21.01 51:30 0.00 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Kh1 e5 20.Bxf6 Bxf6
21.Nxd5 Nxd5 22.Qg6+ Kh8 23.Qh6+ Kg8
24.Qg6+ Kh8 (1.402.935.722) 453
22.01 104:07 0.00 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Kh1 e5 20.Bxf6 Bxf6
21.Nxd5 Nxd5 22.Qg6+ Kh8 23.Qh6+ Kg8
24.Qg6+ Kh8 (2.877.336.665) 460
23.01 224:23 0.00 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Kh1 e5 20.Bxf6 Rxf6
21.Rxf6 Bxf6 22.Nxd5 Nxd5 23.Qg6+ Kh8
24.Qh6+ Kg8 25.Qg6+ Kh8 (6.309.514.610) 468
24.01 607:07 +0.04 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Nb3 Qd6 20.Qd2 Nf5
21.Rxf5 exf5 22.Bxf6 Bxf6 23.Nxd5 Rfd8
24.Nxf6+ Qxf6 25.Nd4 h4 26.c3 Bc6
27.Bc4+ Bd5 28.Bxd5+ Rxd5 (17.236.733.560) 473
best move: g6xf5 time: 684:10.468 min n/s: 475.448 nodes: 19.517.340.188
18.Qd3 Bg7 19.Rd2 h4 20.Qb3 h3 21.g3 Be5
22.Kh1 O-O 23.Nf3 Bc6 24.Bb6 Qb8
25.Rfd1 f4 26.gxf4 Bxf4 (3.937.300.864) 393
Sorry, it appears this version of Ancalagon is buggy and the analysis above can't be trusted. With a Stockfish 1.5 clone I get the line 15... gxf5 again but no +0.64. I still believe this does not really look worse for Black. If it turns out that Highendman had real advantage now against the cluster, and if the cluster had played a better move than 15... exf5? and it would still have gone down quickly, then Rainbow Serpent must have serious positional shortcomings for just displaying 0.00 or even +0.04. It could be, the threats to Black's King for instance are all long range threats that engines have difficulty scoring in the King Safety code.
2r1kb1r/1pqbnp2/p3pnp1/3p1P1p/3NP3/P1NQB3/1PP1B1PP/3R1RK1 b k -
Engine: Rainbow Serpent 1.5 (128 MB)
by Romstad, Costalba, Kiiski, De Groot
16.01 1:08 -0.04 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Bxf6 Rxf6 20.Rxf6 Bxf6
21.Bxh5 Qb6 22.Qg3+ Kh7 23.Qf2 e5
24.Nf3 Qxb2 25.Nxd5 Nxd5 26.Rxd5 (29.931.584) 433
17.01 2:12 -0.04 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Nb3 Qd6 20.Nd4 Qc7
21.Bf3 Qb6 22.Qe3 Ng6 23.Nb3 Qxe3+
24.Bxe3 Ng4 (58.367.574) 440
18.01 4:54 0.00 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Nb3 Qd6 20.Nd4 Qc7
21.Nb3 Qd6 (129.710.065) 441
19.01 10:50 +0.12 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Nb3 Qd6 20.Bf4 e5
21.Bg5 Be8 22.Qg3 Qe6 23.Bh6 Ng4
24.Rxf8+ Bxf8 25.Bxg4 hxg4 26.Bxf8 Kxf8 (289.364.600) 444
20.01 21:04 0.00 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Nb3 Qd6 20.Bf4 e5
21.Bg5 Qb6+ 22.Kh1 Be6 23.Bxf6 Bxf6
24.Qg3+ Kh8 25.Bxh5 e4 26.Qf4 Bg7
27.Qg5 (571.625.906) 451
21.01 51:30 0.00 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Kh1 e5 20.Bxf6 Bxf6
21.Nxd5 Nxd5 22.Qg6+ Kh8 23.Qh6+ Kg8
24.Qg6+ Kh8 (1.402.935.722) 453
22.01 104:07 0.00 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Kh1 e5 20.Bxf6 Bxf6
21.Nxd5 Nxd5 22.Qg6+ Kh8 23.Qh6+ Kg8
24.Qg6+ Kh8 (2.877.336.665) 460
23.01 224:23 0.00 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Kh1 e5 20.Bxf6 Rxf6
21.Rxf6 Bxf6 22.Nxd5 Nxd5 23.Qg6+ Kh8
24.Qh6+ Kg8 25.Qg6+ Kh8 (6.309.514.610) 468
24.01 607:07 +0.04 15...gxf5 16.exf5 Bg7 17.fxe6 fxe6
18.Bg5 O-O 19.Nb3 Qd6 20.Qd2 Nf5
21.Rxf5 exf5 22.Bxf6 Bxf6 23.Nxd5 Rfd8
24.Nxf6+ Qxf6 25.Nd4 h4 26.c3 Bc6
27.Bc4+ Bd5 28.Bxd5+ Rxd5 (17.236.733.560) 473
best move: g6xf5 time: 684:10.468 min n/s: 475.448 nodes: 19.517.340.188
Do you have time for one or 2 games tonight ? Would be a great pleasure for me :)
My wife went for a vacation in Israel (in fact - the taxi arrived yesterday while we were in the middle of the first game, so I didn't even say a proper goodbye) so I'd love a chance for 2 more games tonight. Can we start at 7pm UK / 8pm server time? Thanks for the offer and for finding the time.
:) 20:00 server time is very good for me :)
![[gb]](/mwf/v12/flags/gb.png "United Kingdom")
i Have sent u a message Highendman?
Ultra-d
Ultra-d
![[nl]](/mwf/v12/flags/nl.png "Netherlands")
What an interesting choice of opening for black; it's my pet line with 8... h5! Instead of playing d6 I usually play b6 or b5, put the bishop on b7 followed by Bd6 or Bc5. The idea is that black renouces castling for quite a while and puts pressure on white's king side with h3 etc.
Where did you get the idea for playing this? Is it in a book you are using or...
Where did you get the idea for playing this? Is it in a book you are using or...
rybka 3 spotted & preferred f5 immediately in multi-pv, but has now dropped it out of the 4 candidate moves. strange.
![[kw]](/mwf/v12/flags/kw.png "Kuwait")
I only went through this game very quickly but it seems that white should not have allowed the tension to be released so early with exchanges. It does seem that black was in trouble out of the opening and was much worse. But then again the cluster can see deep and maybe there was nothing there after all ... but I doubt it. I need to look at this a little deeper.
Highe -
Some comments about your latest games from the epic series :)
1) In the game here, Rybka needs a really long time to understand 15. f5!! This is going to be tough even for Lukas' 72 cores. I know it's a little strange to have such trouble with such a thematic move, but that's search. This is just a good example of where the human intervention helps.
2) The 50-move torture in the R v B ending looks ugly but is actually ok. Normally, in won positions, the score climbs steadily with deeper search and this hurries the game along. In some rare cases, the score reaches a sort of "local maximum" and then the 50-move rule is needed to spur further progress. It's not a good idea for many reasons to mislead the engine about the 50-move rule.
3) Nice job luring the cluster into the drawn RPP v RP endgame to save a half-point, this sort of thing has happened many times now and is still on the to-do list for us.
4) Jiri has been playing some risky openings with black, I am sure this is intentional and has been weighed properly.
Vas
Some comments about your latest games from the epic series :)
1) In the game here, Rybka needs a really long time to understand 15. f5!! This is going to be tough even for Lukas' 72 cores. I know it's a little strange to have such trouble with such a thematic move, but that's search. This is just a good example of where the human intervention helps.
2) The 50-move torture in the R v B ending looks ugly but is actually ok. Normally, in won positions, the score climbs steadily with deeper search and this hurries the game along. In some rare cases, the score reaches a sort of "local maximum" and then the 50-move rule is needed to spur further progress. It's not a good idea for many reasons to mislead the engine about the 50-move rule.
3) Nice job luring the cluster into the drawn RPP v RP endgame to save a half-point, this sort of thing has happened many times now and is still on the to-do list for us.
4) Jiri has been playing some risky openings with black, I am sure this is intentional and has been weighed properly.
Vas
![[ch]](/mwf/v12/flags/ch.png "Switzerland")
IMHO - Jiri book is excellent.
It has mainly be designed to play other computer & softare chess engines which are known to be weaker than Cluster Rybka 4 beta.
Therefore his book is mostlikely well designed to play weaker openends.
Here its a strong centaur with strong engine playing the cluster. They are mostelikely about the same level and the book in this very special/specific situation is maybe not 100% tuned for the situation.
But I love to watch the way/openings the cluster is playing with JB book.
This is much more interesting than seeing a Slave or French exchange variation.
regards
It has mainly be designed to play other computer & softare chess engines which are known to be weaker than Cluster Rybka 4 beta.
Therefore his book is mostlikely well designed to play weaker openends.
Here its a strong centaur with strong engine playing the cluster. They are mostelikely about the same level and the book in this very special/specific situation is maybe not 100% tuned for the situation.
But I love to watch the way/openings the cluster is playing with JB book.
This is much more interesting than seeing a Slave or French exchange variation.
regards
Hey whats up with french see our game highendman v Ultra-d a very interesting game in the french.
I think too many get bogged down with Najdorf try something different.
Ultra-d
I think too many get bogged down with Najdorf try something different.
Ultra-d
Where can I see the game ?
Dont worry, I am an OTB French & Caro-Kann player.
But its a fact that if white wants to remove the fan of a French opening he can play 3.exd5
Its even worse in the Slave exchange.
1.d4 d5 2.c4 c6 3.cxd
I am not saying that these lines are 100% draws but winning % for black is not as good as for example the variations JB choosed for black. Its a question of maximizing your %
Dont worry, I am an OTB French & Caro-Kann player.
But its a fact that if white wants to remove the fan of a French opening he can play 3.exd5
Its even worse in the Slave exchange.
1.d4 d5 2.c4 c6 3.cxd
I am not saying that these lines are 100% draws but winning % for black is not as good as for example the variations JB choosed for black. Its a question of maximizing your %
![[pr]](/mwf/v12/flags/pr.png "Puerto Rico")
As a french player you should now that black could not play in the symmetry of the exchange variation, there is the Nc6 variation after exd5 that could be very sharp.
It can be very sharp but if white wants to remove the fun out of it, they can...
May I ask how?
![[cz]](/mwf/v12/flags/cz.png "Czech Republic")
Thank you for your comments. I think that is very objective.
Short summary (and nothing new for you):
With white is situation easier, because one weaker move will lead to equality however weaker or dubious move as black have very often tragic consequences.
We can play 100% "best" moves but this can easily lead to end of game after 5 minut in a draw in 60 moves from book with 2 kings on the board in Merano or Najdorf :-)
Improving any line, which is daily played massive anywhere, means lot of work and very short duration ..
If you have any interesting idea What play please PM ..
Short summary (and nothing new for you):
With white is situation easier, because one weaker move will lead to equality however weaker or dubious move as black have very often tragic consequences.
We can play 100% "best" moves but this can easily lead to end of game after 5 minut in a draw in 60 moves from book with 2 kings on the board in Merano or Najdorf :-)
Improving any line, which is daily played massive anywhere, means lot of work and very short duration ..
If you have any interesting idea What play please PM ..
Jiri - I like the aggressive black play and hope you keep going in this direction. First - because it's working. It's also important to understand what sorts of risks can be taken with the black pieces.
Vas
Vas
>It's not a good idea for many reasons to mislead the engine about the 50-move rule.
Why? The 50-move rule is a rule for human chess. In computer chess it would be much smarter to have a (internal) 25-moves rule. It´s always good to shorten torture! :-)
Btw: Who is counting the moves of the 50-moves rule? Only the GUI (and gives this information to the engine) or the engine by itself?
>Btw: Who is counting the moves of the 50-moves rule? Only the GUI (and gives this information to the engine) or the engine by itself?
The engine counts them.
The Chessbase GUI counts them also and declares draws by force without engines to be able to do anything. GUIs that do that are stupid GUIs.
It's hard for an engine to tell the difference between interesting manoevering and useless shuffling. By limiting the counter to 25 moves, you'll miss out on some manoevers.
You'll also get some crazy things, like the engine playing into a mate-in-1 thinking she's about to be saved by the 25-move-rule, etc.
The GUI can send either the full move list or an FEN (with embedded move ct). Usually, GUIs send the move list.
Vas
You'll also get some crazy things, like the engine playing into a mate-in-1 thinking she's about to be saved by the 25-move-rule, etc.
> Btw: Who is counting the moves of the 50-moves rule? Only the GUI (and gives this information to the engine) or the engine by itself?
The GUI can send either the full move list or an FEN (with embedded move ct). Usually, GUIs send the move list.
Vas
that would be a funny thing to see and watch rybka get away with re: moving into a mating net just to 1/2-1/2 for the 50-move rule LOL. I wanna try this myself
Just don't expect your engine to point the mate out to you - you'll have to find it yourself. :)
Vas
Vas
![[gr]](/mwf/v12/flags/gr.png "Greece")
> 3) Nice job luring the cluster into the drawn RPP v RP endgame to save a half-point, this sort of thing has happened many times now and is still on the to-do list for us.
one way i can think of ( emulating what humans do) is do the following
1) Create a list of endgames with few pieces (7-10 perhaps or even few more 12 for example) and see from search or some other way the %of w/d/l
2) Use that percent (by using a proper function ofcourse) as a contemp factor to avoid entering or entering in certain endgames.
For example the RPPPvRPP has probably more than 95% drawing chances. It is wise to avoid going there. So if there is a proper finetuned function like create_contempt(drawing_percent) it would help Rybka a lot.
Clever idea!
I've tried something similar to this. Surprisingly,
This statement (and weaker forms of it) seems to be false. I need to dig deeper, of course.
Vas
> For example the RPPPvRPP has probably more than 95% drawing chances.
This statement (and weaker forms of it) seems to be false. I need to dig deeper, of course.
Vas
Pretty cool. And sad (not really sad really) - if there's a way to identify type of end-games to be avoided (which would require a lot of fine tuning for something like this to not back fire) I guess our last best hope of occasionally salvaging draws using our human intuition of what gives a chance is now going to diminish farther ;)
Pretty cool idea though.
It keeps amazing me the extent of what seem to be yet uncovered ground to make chess engines stronger via more knowledge.
I guess there are two main parts - search: how to make it as fast as possible as each extra 'correct' depth increase should increase strength.
And the next and equally fun, if not even more fun, to work on is the eval - I guess probably there's a (relatively) simplistic eval at the search level to guide pruning, and then heavier, better albeit much slower eval towards the bottom of a search tree.
I dare guess one of the challenges chess engine developers have is how to write their engine in a way they can keep introducing such new knowledge into the engine via a framework outside the main code to test it.
For example, if I was to write an engine (never gonna happen hehe) I'd probably try to create a pseudo-language that gets interpreted pre-compile into an efficient code, through which such knowledge can be introduced into the search 'eval' and real 'eval' functions. And then whenever a piece of knowledge would prove adding value - and the proving process must be hard! - I would hand-tune the code that pseudo language generated, to re-gain the performance pseudo-language can't possibly have as they are general purpose.
I guess the second important thing would be another pseudo-language to determine certain board conditions that need to apply before a specific knowledge gets fired within the eval. It calls for two distinct set of pseudo-languages - one for defining board conditions that need to apply, and the second for defining the knowledge that needs to get evaluated when those board conditions are reached.
Then of course yet another challenge (which I find less fun than the previous ones) - would be how to weight the various 'knowledge pieces' to flatten all of them to a single score per position to feed back to the search & alpha-beta minimaxing - I'll take another guess - there might be benefits if multiple scores are performed on a node and actually more than one score is given per position and then some further dynamic heuristic weights them and decides the final score of that node. I guess this weighting setting part seems to be less fun for me because the way to determine these weights is less by intuition or mental brilliancy and more by hard work and loooots of games / tests. I would have probably opted for some genetic evolution here as I'm lazy - and just let it run and run and try to reach a weighting I'd have no clue why is good but would be better than others :) I'm very curious what of the above set of wild thoughts bare anything to do with reality. Maybe Vas or GCP can share to the extent possible how wrong my mental stab at this is as in many areas ones first thought process is always proved wrong by reality ;)
As all good software developers are lazy by definition (or else they wouldn't be good at this) - I guess separating knowledge adding and knowledge conditions as then scoring method - would be the way to go to make it easier to add / test. With easier being a major understatement.
Sorry if I've gone in a bad tangent - the post above just triggered this random thought process ;)
Pretty cool idea though.
It keeps amazing me the extent of what seem to be yet uncovered ground to make chess engines stronger via more knowledge.
I guess there are two main parts - search: how to make it as fast as possible as each extra 'correct' depth increase should increase strength.
And the next and equally fun, if not even more fun, to work on is the eval - I guess probably there's a (relatively) simplistic eval at the search level to guide pruning, and then heavier, better albeit much slower eval towards the bottom of a search tree.
I dare guess one of the challenges chess engine developers have is how to write their engine in a way they can keep introducing such new knowledge into the engine via a framework outside the main code to test it.
For example, if I was to write an engine (never gonna happen hehe) I'd probably try to create a pseudo-language that gets interpreted pre-compile into an efficient code, through which such knowledge can be introduced into the search 'eval' and real 'eval' functions. And then whenever a piece of knowledge would prove adding value - and the proving process must be hard! - I would hand-tune the code that pseudo language generated, to re-gain the performance pseudo-language can't possibly have as they are general purpose.
I guess the second important thing would be another pseudo-language to determine certain board conditions that need to apply before a specific knowledge gets fired within the eval. It calls for two distinct set of pseudo-languages - one for defining board conditions that need to apply, and the second for defining the knowledge that needs to get evaluated when those board conditions are reached.
Then of course yet another challenge (which I find less fun than the previous ones) - would be how to weight the various 'knowledge pieces' to flatten all of them to a single score per position to feed back to the search & alpha-beta minimaxing - I'll take another guess - there might be benefits if multiple scores are performed on a node and actually more than one score is given per position and then some further dynamic heuristic weights them and decides the final score of that node. I guess this weighting setting part seems to be less fun for me because the way to determine these weights is less by intuition or mental brilliancy and more by hard work and loooots of games / tests. I would have probably opted for some genetic evolution here as I'm lazy - and just let it run and run and try to reach a weighting I'd have no clue why is good but would be better than others :) I'm very curious what of the above set of wild thoughts bare anything to do with reality. Maybe Vas or GCP can share to the extent possible how wrong my mental stab at this is as in many areas ones first thought process is always proved wrong by reality ;)
As all good software developers are lazy by definition (or else they wouldn't be good at this) - I guess separating knowledge adding and knowledge conditions as then scoring method - would be the way to go to make it easier to add / test. With easier being a major understatement.
Sorry if I've gone in a bad tangent - the post above just triggered this random thought process ;)
The search problem is the problem of shaping the search tree (ie. emphasizing and de-emphasizing moves). A lot of this is done with static analysis and yes, it's fun. :)
The eval problem is the problem of comparing two positions to decide which one is "better", this too is done with static analysis and yes, it's also fun. :)
I may be in a minority, but I like to code "to the metal" throughout, and think from the beginning about a clean, elegant formulation. Sometimes it's a pity to throw away a nice piece of code because it doesn't work.
Two comments here:
1) A simple sum of eval weights is surprisingly effective. Score one for KISS. (There are some exceptions of course.)
2) Thinking about the process for tuning weights is a lot cooler than actually tuning them. Stefan told me in Mainz that over the years, he's has "something like 20" totally different approaches for handling weights. My figure is probably ~5, I overhaul this once or so per year. There was a very interesting discussion about this topic here in this forum before Rybka 3 came out, between me and the artist formerly known as Alan. :)
Vas
The eval problem is the problem of comparing two positions to decide which one is "better", this too is done with static analysis and yes, it's also fun. :)
> For example, if I was to write an engine (never gonna happen hehe) I'd probably try to create a pseudo-language that gets interpreted pre-compile into an efficient code, through which such knowledge can be introduced into the search 'eval' and real 'eval' functions. And then whenever a piece of knowledge would prove adding value - and the proving process must be hard! - I would hand-tune the code that pseudo language generated, to re-gain the performance pseudo-language can't possibly have as they are general purpose.
I may be in a minority, but I like to code "to the metal" throughout, and think from the beginning about a clean, elegant formulation. Sometimes it's a pity to throw away a nice piece of code because it doesn't work.
> Then of course yet another challenge (which I find less fun than the previous ones) - would be how to weight the various 'knowledge pieces' to flatten all of them to a single score per position to feed back to the search & alpha-beta minimaxing - I'll take another guess - there might be benefits if multiple scores are performed on a node and actually more than one score is given per position and then some further dynamic heuristic weights them and decides the final score of that node. I guess this weighting setting part seems to be less fun for me because the way to determine these weights is less by intuition or mental brilliancy and more by hard work and loooots of games / tests.
Two comments here:
1) A simple sum of eval weights is surprisingly effective. Score one for KISS. (There are some exceptions of course.)
2) Thinking about the process for tuning weights is a lot cooler than actually tuning them. Stefan told me in Mainz that over the years, he's has "something like 20" totally different approaches for handling weights. My figure is probably ~5, I overhaul this once or so per year. There was a very interesting discussion about this topic here in this forum before Rybka 3 came out, between me and the artist formerly known as Alan. :)
Vas
>one way i can think of ( emulating what humans do) is do the following
>1) Create a list of endgames with few pieces (7-10 perhaps or even few more 12 for example) and see from search or some other way the %of w/d/l
>2) Use that percent (by using a proper function ofcourse) as a contemp factor to avoid entering or entering in certain endgames.
The above method is a weak method in my opinion because is practically pointless i guess.
Because:
See from search? What search? Of Rybka? But isn't this what we want to "fix" because it's flawed? If we use the flawed search to create this list, then the list will also be flawed so it would be useless. Also to create such list would be a complete struggle. I can't even think how many years it would take.
If not search then what other way? Endgame tablebases? But if we had 7-10 piece tablebases we would not need to fix Rybka's eval and all this conversation would be pointless anyway.
Statistics from previous games? This is the only logical way to do it, but i don't think there is such a big trustworthy list of games available to provide enough useful data, and for the extra reason because humans do not play the endgame optimally=better than Rybka(man top GMs may perhaps play it better than Rybka but their games are so small in number that it can't create such a big database for creating the W/D/L statistics).
>For example the RPPPvRPP has probably more than 95% drawing chances. It is wise to avoid going there. So if there is a proper finetuned function like create_contempt(drawing_percent) it would help Rybka a lot.
The real problem is that Rybka's eval is not correct. So when it will say that in an KRPPKRP is 1.22 it may be drawn. And if it's going to have to make a decision about going or not to that endgame then it would be of course wise to avoid it. But go to what position? Perhaps the new position it will go is a draw too. Or even worse a loss.
The only solution i see is not percentages in the way you described because it is too general and it can't be applied generally as in this way you will lose many wins by avoid going into these positions, but by implementing a hardness_to_win_value for certain types of endgames(e.g KRPKR-with Pawn on corner files), but this is a very difficult task to implement also.
Usually, you don't want to give high scores for totally drawn positions; and usually, engines will manage to draw them once they get there, bad score or not. I think game results do have some value ..
Vas
Vas
> See from search? What search? Of Rybka?
who talked about search.
>Statistics from previous games?
This AND common theory knowledge. Think of it as an evaluation function. It like saying KBvK is a draw, but in a probabilistic way.
For example, its common knowledge the KRppvKRp all in one side is a draw (most of the times). KRpppvKRpp (all in the same side is a draw too.. again most of the times) and even if its not, if there is a better way... the engine could follow that.
Contempt will just guide the engine to avoid such endgames. Basically exchanging pieces. There is a sweet spot in exchanging. If you go too far, you cannot win.
For me, the fewer the pieces, then search loses its importance.
>> See from search? What search? Of Rybka?
>who talked about search.
You. :-)
----------
>1) Create a list of endgames with few pieces (7-10 perhaps or even few more 12 for example) and see from search or some other way the %of w/d/l
----------
>This AND common theory knowledge. Think of it as an evaluation function. It like saying KBvK is a draw, but in a probabilistic way.
>For example, its common knowledge the KRppvKRp all in one side is a draw (most of the times). KRpppvKRpp (all in the same side is a >draw too.. again most of the times) and even if its not, if there is a better way... the engine could follow that.
I find this to be a good idea, but unfortunately it's quite unfeasible to make it work practically due to millions of different cases and exceptions.
> You. <img class="sic sic_sml_pos" src="/mwf/epx.png" alt=":-)">
almost :)
i was talking about searching in human results :)
> it's quite unfeasible to make it work practically due to millions of different cases and exceptions.
The idea is simple. If the engine can choose KRBppp v KRBpp or KRppp v KRpp , the engine should prefer the one with the bishop (except if the evaluation difference is even more than the contempt).
A mechanism to select which endgame has more chances to be a win. Nothing more nothing less. The way human select to exchange or not (based on "knowledge")
It says the post I am replying is 399 days old, but let me do so , because I recently had a game with 4vs3 pawns on king side with bishop and rooks. This game happened in one of the main lines of Grunfeld Slav, so I find it theoretically relevant.
Rybka exchanged the rooks on first opportunity, and in the resulting endgame, I run an engine tournament 4vs3. pawns with bishops.. (the h8 square was the color of the bishops)
Most games were won by Rybka, and i realized if the white's king is active and black cannot activate his own king in time, then the position might indeed be lost. Also the pawn moves of the defending side tend to weaken his position quite a bit and probably lead to loss.
So my views on 4vs.3 pawn scenarios have changed quite a bit.
In the end, I agree there is a sweetspot of exchanging, if bishops were exchanged and rooks were kept, the game would be much easier to draw and probably a draw in perfect play. I think in endgame heuristics should be weighter more than material advantage or search.
Also, in endgames with pawns on the one side of the board, there should be a mini-50 move rule, because in such endgames it is obvious that the even the best maneuvering won't take longer than 10-15 moves. Evaluation function can continue using the 50-move rule in other endgames, but in most endgames, the winning manevuer won't take more then 10-15 moves until a pawn should be pushed, resetting the 50-move counter.
And Vas said something about getting into checkmate net trying to avoid the draw rule. Yes, now I see why it is just a bit difficult to implement it, but probably a checkmate net would have to mate it in 14-15 depth, so checkmate net can probably be avoided with full search until a certain depth.
My 2 cents,
Rybka exchanged the rooks on first opportunity, and in the resulting endgame, I run an engine tournament 4vs3. pawns with bishops.. (the h8 square was the color of the bishops)
Most games were won by Rybka, and i realized if the white's king is active and black cannot activate his own king in time, then the position might indeed be lost. Also the pawn moves of the defending side tend to weaken his position quite a bit and probably lead to loss.
So my views on 4vs.3 pawn scenarios have changed quite a bit.
In the end, I agree there is a sweetspot of exchanging, if bishops were exchanged and rooks were kept, the game would be much easier to draw and probably a draw in perfect play. I think in endgame heuristics should be weighter more than material advantage or search.
Also, in endgames with pawns on the one side of the board, there should be a mini-50 move rule, because in such endgames it is obvious that the even the best maneuvering won't take longer than 10-15 moves. Evaluation function can continue using the 50-move rule in other endgames, but in most endgames, the winning manevuer won't take more then 10-15 moves until a pawn should be pushed, resetting the 50-move counter.
And Vas said something about getting into checkmate net trying to avoid the draw rule. Yes, now I see why it is just a bit difficult to implement it, but probably a checkmate net would have to mate it in 14-15 depth, so checkmate net can probably be avoided with full search until a certain depth.
My 2 cents,
Yes this is an old game. A lot of player consider Highendman the top CC player here on the forum
lets see, although i will be first to admit he is a great player and i notice he sometimes follows my games,and will say he has been complementaary on some of my play atm i have been unable to return compliment as he does not play corr games.
1
2
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill