Hi all,
I tested Rybka 2.3.2a with the Eigenmann Endspiel Test. See here
http://www.ordichec.net/testfinales.html
This is in French but ok you can anyway read numbers and look at the graphs. In this test I let 2 minutes per position.
The new version of Rybka is much better for the endings. This is the best one among the ones I tested. Hiarcs 11.1 can find the same number of positions, but it needs 27 minutes more.
So Rybka 2.3.2a can find 74 positions/100 using 2 min/position. But she can find 73 positions using only 1 min/position! So she clearly saturates.
My hardware seems a bit faster than the one of Walter Eigenmann (he has Athlon64/3000+, and I have Athlon64/3200+) but he use up to 5-men tablebase, I use up to 4-men. And as I point out here
http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?pid=16497#pid16497
I have also to specify the hash size (256MB, Walter use 128MB) because the result of the analysis can depend on the size of the hash...
Now with the engine I tested, only 5 positions remain unsolved.
Regards,
Fabian
I tested Rybka 2.3.2a with the Eigenmann Endspiel Test. See here
http://www.ordichec.net/testfinales.html
This is in French but ok you can anyway read numbers and look at the graphs. In this test I let 2 minutes per position.
The new version of Rybka is much better for the endings. This is the best one among the ones I tested. Hiarcs 11.1 can find the same number of positions, but it needs 27 minutes more.
So Rybka 2.3.2a can find 74 positions/100 using 2 min/position. But she can find 73 positions using only 1 min/position! So she clearly saturates.
My hardware seems a bit faster than the one of Walter Eigenmann (he has Athlon64/3000+, and I have Athlon64/3200+) but he use up to 5-men tablebase, I use up to 4-men. And as I point out here
http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?pid=16497#pid16497
I have also to specify the hash size (256MB, Walter use 128MB) because the result of the analysis can depend on the size of the hash...
Now with the engine I tested, only 5 positions remain unsolved.
Regards,
Fabian
Nice representation of the data, really like that!. :) To bad it's in French :(
thanks a lot! Yes this is in french, perhaps when I will have more time I could try to make and english version, at least of the test part of my website, but anyway the interesting part is the tables and the figures, the text is not so important. :)
Oh, I see, you are interested in testsuites. I make the test also and my results are 74 solutions after 60 seconds with T7200 (2 GHz) and 256 MB memory and 4 man EGTBs on 32-bit OS. But: Have a look to the analysis and the evaluation. Understand the engine or is it just luck? Is the line correct? Will the engine understand the line, when she has more time or never (you have to go in the line)? This all is much more important than the pure result. When you have done this, you have a much better idea about the knowledge of the engine.
After you have doing this, you will confirm that Rybka lacks of these features in endgames (in order of easiest to do):
1. Wrong bishop
2. Rook endgames in general (but first: It isn´t so good, to secure the free edge pawn from above and pushing him forward, so that the play of the rook increases).
3. Very last: Fortress! For a normal user it´s not to understand, that a line, which makes no progress (always the same +5 eval in depth 20 and 30) can´t be sorted out (vice versa for black, who will hold the line). Every Patzer sees it, but it can´t rebuild in an engine? I can´t believe it. For the experts, it should be controlled by a parameter.
After you have doing this, you will confirm that Rybka lacks of these features in endgames (in order of easiest to do):
1. Wrong bishop
2. Rook endgames in general (but first: It isn´t so good, to secure the free edge pawn from above and pushing him forward, so that the play of the rook increases).
3. Very last: Fortress! For a normal user it´s not to understand, that a line, which makes no progress (always the same +5 eval in depth 20 and 30) can´t be sorted out (vice versa for black, who will hold the line). Every Patzer sees it, but it can´t rebuild in an engine? I can´t believe it. For the experts, it should be controlled by a parameter.
Thanks for your comment. It's true that for example the "fortress" problem is a very well known one and quite common for all engine, they do not see the draw at all, they are driven by the material advantage (and in some position it can be huge).
It's true that you have also to look at the whole variation proposed by the engine and not just the first move, I have indeed an example where the first move is found by almost all engine but they give a drawish evaluation while there is a mate... so in that case in can be seen like pure luck.
I am preparing a test suite collecting interesting not-too-easy-not-too-hard positions from other tests (but the engine would have to think sometime 10 minutes or so), where I will give a detailled analysis of each position. The test will not have so much position 20 is a maximum, but then you can obviously look in each case if the engine understand the position and if the variation it proposes make sense. For the eigenmann test, there are 100 positions, I do not have the time to go through all variation proposed by the engine. :)
It's true that you have also to look at the whole variation proposed by the engine and not just the first move, I have indeed an example where the first move is found by almost all engine but they give a drawish evaluation while there is a mate... so in that case in can be seen like pure luck.
I am preparing a test suite collecting interesting not-too-easy-not-too-hard positions from other tests (but the engine would have to think sometime 10 minutes or so), where I will give a detailled analysis of each position. The test will not have so much position 20 is a maximum, but then you can obviously look in each case if the engine understand the position and if the variation it proposes make sense. For the eigenmann test, there are 100 positions, I do not have the time to go through all variation proposed by the engine. :)
Genorb, Rybka 2.3.2.a 32 Bits solves position 32 fast.
Deep Fritz with 1 core also solves this position.
Paulo Soares
Deep Fritz with 1 core also solves this position.
Paulo Soares
Sorry the correct number of the position is 34
Paulo Soares
Paulo Soares
Of course, as I mentionned above, you have to specified the size of your hash and also the number of "men" in your tablebases.
I tried with 256MB and 32MB for the hash and I use 3 and 4-men tablebases. In both cases, I get the same analysis for the position 34. Rybka 2.3.2a cannot solve it on my system. Here it is
10.00 0:00 -3.18 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rc5 (13.611) 38
11.00 0:00 -3.19 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 (21.779) 44
12.00 0:00 -3.19 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 (32.880) 53 TB:2
13.00 0:00 -3.20 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 Dd7+ (48.733) 60 TB:7
14.00 0:01 -3.26 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rf4 Df8+ (84.311) 71 TB:17
15.01 0:01 -3.29 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 Dd7+ (137.757) 77 TB:37
16.01 0:02 -3.30 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rf4 Df8+ (212.462) 81 TB:66
17.01 0:03 -3.31 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rf4 Df8+ (326.325) 88 TB:113
18.01 0:06 -3.35 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rf4 Df8+ (537.360) 90 TB:190
19.01 0:08 -3.35 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 Dd7+ (783.421) 94 TB:329
20.01 0:12 -3.38 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 Dd7+ (1.201.257) 94 TB:564
21.01 0:17 -3.38 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 Dd7+ (1.673.605) 98 TB:887
22.01 0:27 -3.40 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 Dd7+ (2.642.840) 98 TB:1.588
23.01 0:45 -3.42 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 Dd7+ (4.460.588) 100 TB:2.725
24.01 1:10 -3.43 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 Dd7+ (7.092.271) 103 TB:4.257
25.01 2:05 -3.49 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 Dd7+ (12.338.082) 100 TB:7.419
26.01 3:45 -3.50 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rf3 Dd7 (21.356.969) 96 TB:13.265
27.01 5:38 -3.51 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rf3 Dd7 (32.676.979) 98 TB:19.745
28.01 10:31 -3.66 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd4 Dd7+ (57.817.469) 93 TB:40.199
Meilleur coup: Fd3xf1 Temps: 15:09.547 min K/s: 89.582 Noeuds: 79.556.022 TB: 58.145
Regards,
Fabian
I tried with 256MB and 32MB for the hash and I use 3 and 4-men tablebases. In both cases, I get the same analysis for the position 34. Rybka 2.3.2a cannot solve it on my system. Here it is
10.00 0:00 -3.18 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rc5 (13.611) 38
11.00 0:00 -3.19 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 (21.779) 44
12.00 0:00 -3.19 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 (32.880) 53 TB:2
13.00 0:00 -3.20 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 Dd7+ (48.733) 60 TB:7
14.00 0:01 -3.26 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rf4 Df8+ (84.311) 71 TB:17
15.01 0:01 -3.29 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 Dd7+ (137.757) 77 TB:37
16.01 0:02 -3.30 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rf4 Df8+ (212.462) 81 TB:66
17.01 0:03 -3.31 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rf4 Df8+ (326.325) 88 TB:113
18.01 0:06 -3.35 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rf4 Df8+ (537.360) 90 TB:190
19.01 0:08 -3.35 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 Dd7+ (783.421) 94 TB:329
20.01 0:12 -3.38 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 Dd7+ (1.201.257) 94 TB:564
21.01 0:17 -3.38 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 Dd7+ (1.673.605) 98 TB:887
22.01 0:27 -3.40 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 Dd7+ (2.642.840) 98 TB:1.588
23.01 0:45 -3.42 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 Dd7+ (4.460.588) 100 TB:2.725
24.01 1:10 -3.43 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 Dd7+ (7.092.271) 103 TB:4.257
25.01 2:05 -3.49 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd5 Dd7+ (12.338.082) 100 TB:7.419
26.01 3:45 -3.50 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rf3 Dd7 (21.356.969) 96 TB:13.265
27.01 5:38 -3.51 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rf3 Dd7 (32.676.979) 98 TB:19.745
28.01 10:31 -3.66 1.Fxf1 Rb1 2.Fd3+ Rc1 3.Cxa3 a1D 4.Cc4 Da8+ 5.Rd4 Dd8+ 6.Re4 De7+ 7.Rd4 Dd7+ (57.817.469) 93 TB:40.199
Meilleur coup: Fd3xf1 Temps: 15:09.547 min K/s: 89.582 Noeuds: 79.556.022 TB: 58.145
Regards,
Fabian
Ah.... I din´t specifyed my hash or processor.
Don´t need, I found that you have to do the 5 man tablebases
for Rybka 2.3.2a found the solution.
Regards,
Paulko Soares
Don´t need, I found that you have to do the 5 man tablebases
for Rybka 2.3.2a found the solution.
Regards,
Paulko Soares
Have you tried 2.3.2a or 2.3.2a mp (with MaxCPUs=1).
They are not the same :-)
They are not the same :-)
I have only the single processor version :) .
Thanks for those links, Genorb.
I found the Walter's endgame database. It is very useful to have something like that and to test with the engines.
Regards,
Gambito.
I found the Walter's endgame database. It is very useful to have something like that and to test with the engines.
Regards,
Gambito.
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill