Author: Bernhard Bauer
Date: 04:35:48 08/10/05
Go up one level in this thread
On August 10, 2005 at 06:25:51, Joachim Rang wrote: >On August 10, 2005 at 04:32:53, Fabien Letouzey wrote: > >>On August 10, 2005 at 04:25:19, Joachim Rang wrote: >> >>>>[D]8/k7/3p4/p2P1p2/P2P1P2/8/8/K7 w >> >>>Intresting observation. Fruit 2.1 solves it on depth 26, the current >>>dev-versionon on depth 27. But both need more then 2 minutes on Pentium M 1.6 >>>GHz. Toga 0.93 also needs some time but Toga 1.0 is quick. I don't know what >>>Thomas has changed though. >> >>Try older Fruit versions. I remember it was easily solved when I tried last >>year. >> >>Hint: that's one of the reasons I know there are bugs in the search :) >> >>Fabien. > >I'm glad you admit that. Gian-Carlo wrote to me once, solving this position >quickly makes your program playing weaker. I'm not sure whether he is right or >not but at least it does not appear to be related to pruning, since even if I >disable all pruning it still needs depth 26. > >regards Joachim Here is output for Toga and Fruit FEN: 8/k7/3p4/p2P1p2/P2P1P2/8/8/K7 w - - 0 1 TogaII: 22/24 00:00 32.283 0 +0,72 Ka1b2 Ka7a8 Kb2c3 Ka8b7 Kc3d2 22/26 00:00 43.164 0 +1,88 Ka1b1 Ka7b6 Kb1c2 Kb6b7 Kc2c3 23/26 00:00 49.247 0 +1,88 Ka1b1 Ka7b6 Kb1c2 Kb6b7 Kc2c3 24/26 00:00 56.905 0 +1,88 Ka1b1 Ka7b6 Kb1c2 Kb6b7 Kc2c3 25/28 00:00 67.192 0 +2,06 Ka1b1 Ka7b6 Kb1c2 Kb6b7 Kc2c3 26/29 00:00 79.497 0 +2,06 Ka1b1 Ka7b6 Kb1c2 Kb6b7 Kc2c3 27/31 00:00 97.124 0 +2,19 Ka1b1 Ka7b6 Kb1c2 Kb6b7 Kc2c3 28/31 00:00 122.579 0 +2,25 Ka1b1 Ka7b6 Kb1c2 Kb6b7 Kc2c3 29/34 00:00 162.994 0 +2,38 Ka1b1 Ka7b6 Kb1c2 Kb6b7 Kc2c3 30/36 00:00 199.238 0 +2,38 Ka1b1 Ka7b6 Kb1c2 Kb6b7 Kc2c3 31/39 00:00 283.718 0 +2,77 Ka1b1 Ka7b6 Kb1c2 Kb6b7 Kc2c3 32/39 00:00 356.413 0 +2,77 Ka1b1 Ka7b6 Kb1c2 Kb6b7 Kc2c3 33/42 00:00 466.703 0 +2,98 Ka1b1 Ka7b6 Kb1c2 Kb6b7 Kc2c3 34/46 00:01 1.073.473 0 +2,74 Ka1b1 Ka7b6 Kb1c2 Kb6b7 Kc2c3 35/46 00:01 1.197.285 0 +2,50 Ka1b1 Ka7b6 Kb1c2 Kb6b7 Kc2c3 36/51 00:02 1.870.972 0 +2,50 Ka1b1 Ka7a8 Kb1b2 Ka8a7 Kb2b3 37/51 00:02 2.042.866 0 +2,50 Ka1b1 Ka7a8 Kb1b2 Ka8a7 Kb2b3 38/51 00:02 2.328.316 0 +2,74 Ka1b1 Ka7a8 Kb1b2 Ka8a7 Kb2b3 39/52 00:02 2.766.927 0 +2,50 Ka1b1 Ka7a8 Kb1b2 Ka8a7 Kb2b3 40/53 00:03 3.452.381 0 +2,50 Ka1b1 Ka7a8 Kb1b2 Ka8a7 Kb2b3 41/61 00:11 11.713.755 1.072.000 +2,38 Ka1b1 Ka7a8 Kb1b2 Fruit_21: 25/27 00:10 20.872.780 2.070.579 +0,74 Ka1b2 Ka7a8 Kb2c3 Ka6b6 26/30 02:19 290.433.750 2.089.065 +1,68 Ka1b1 Ka7b7 Kb1c1 g5xf5 Yes, from the development of crafty I know that fact. Solving special positions may weaken a program. However my approach is that search should find it, even if it takes much time. Here is the famous Ortueta-Sanz position. [D]8/pR4pk/1b6/2p5/N1p5/8/PP1r2PP/6K1/ b Early crafty versions were very quick, but later crafty became as slow as other programs. Here some output from Toga2 and Fruit2.1 running on an Athlon 1800 MHz. FEN: 8/pR4pk/1b6/2p5/N1p5/8/PP1r2PP/6K1 b - - 0 1 TogaII: 17/39 01:11 65.338.841 914.507 +0,17 Bb6d8 h2h3 Bd8f6 a2a3 Rd2d1+ 18/44 03:56 211.396.468 893.727 +0,23 Bb6d8 Kg1f1 Bd8f6 h2h4 Bf6xh4 18/44 11:31 598.718.363 866.060 +2,56 Rd2xb2 Rb7e7 Rb2xa2 Na4c3 19/44 12:06 628.742.769 865.870 +2,57 Rd2xb2 Rb7e7 Rb2xa2 Na4c3 FEN: 8/pR4pk/1b6/2p5/N1p5/8/PP1r2PP/6K1 b - - 0 1 Fruit_21: 17/40 01:19 77.388.137 978.504 +0,21 Bb6d8 Kg1f1 Bd8f6 h2h4 Bf6xh4 18/40 01:56 112.110.579 968.533 +0,19 Bb6d8 Kg1f1 Bd8f6 h2h4 Bf6xh4 19/40 04:09 226.676.837 911.296 +0,10 Bb6d8 Kg1f1 Bd8f6 Na4xc5 19/46 10:20 568.957.864 916.772 +2,32 Rd2xb2 Rb7e7 Rb2xa2 Na4c3 20/46 12:36 693.890.935 917.378 +2,57 Rd2xb2 Rb7e7 Rb2xa2 Na4c3 Kind regards Bernhard
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.