Author: Robert Hyatt
Date: 13:18:36 09/23/99
Go up one level in this thread
On September 23, 1999 at 15:14:24, blass uri wrote: >On September 23, 1999 at 09:43:20, Robert Hyatt wrote: > >>On September 23, 1999 at 09:24:43, Wayne Lowrance wrote: >> >>>On September 22, 1999 at 22:54:07, Robert Hyatt wrote: >>> >>>>On September 22, 1999 at 20:25:56, Howard Exner wrote: >>>> >>>>>On September 22, 1999 at 13:42:26, Robert Hyatt wrote: >>>>> >>>>>>On September 22, 1999 at 13:40:37, Robert Hyatt wrote: >>>>>> >>>>>>>On September 22, 1999 at 11:46:29, Howard Exner wrote: >>>>>>> >>>>>>>>Do any of the programs with endgame tablebases solve this position? >>>>>>>> >>>>>>>>8/6Bp/6p1/2k1p3/4PPP1/1pb4P/8/2K5 b - - id Pos 111 - ECM98H.EPD; bm b3b2 >>>>>>>> >>>>>>>>It looks too difficult for non tablebase programs. >>>>>>> >>>>>>> >>>>>>>Crafty solves it, but it takes longer than I would like to see... 11 minutes. >>>>>>> >>>>>>>here is the output: (quad xeon with all the 5 piece ending databases). >>>>>>> >>>>>>> 15-> 1:46 -0.09 1. ... Kd6 2. Bf8+ Ke6 3. f5+ Kf6 4. >>>>>>> Kb1 Bd4 5. Ba3 h6 6. Bb2 h5 7. Bxd4 >>>>>>> exd4 8. Kb2 hxg4 9. hxg4 d3 10. Kxb3 >>>>>>> d2 11. Kc2 >>>>>>> 16 2:21 -0.17 1. ... Kd6 2. Bf8+ Ke6 3. f5+ gxf5 >>>>>>> 4. gxf5+ Kf6 5. Bc5 h5 6. Kb1 Kf7 7. >>>>>>> Ba3 Kf6 8. Kc1 h4 9. Bb2 Be1 10. Kd1 >>>>>>> Bf2 >>>>>>> (3) 16-> 4:07 -0.17 1. ... Kd6 2. Bf8+ Ke6 3. f5+ gxf5 >>>>>>> 4. gxf5+ Kf6 5. Bc5 h5 6. Kb1 Kf7 7. >>>>>>> Ba3 Kf6 8. Kc1 h4 9. Bb2 Be1 10. Kd1 >>>>>>> Bf2 >>>>>>> (2) 17 6:09 -0.26 1. ... Kd6 2. Bf8+ Ke6 3. f5+ Kf6 4. >>>>>>> Ba3 Bd4 5. Kb1 Bc3 6. g5+ Kf7 7. f6 >>>>>>> Bd2 8. Bc1 <HT> >>>>>>> 17 11:26 0.00 1. ... b2+ 2. Kc2 exf4 3. Bxc3 f3 4. >>>>>>> Be1 Kd4 5. Bf2+ Kxe4 6. Ba7 Kf4 7. >>>>>>> Bf2 Ke4 >>>>>>> (4) 17-> 11:42 0.00 1. ... b2+ 2. Kc2 exf4 3. Bxc3 f3 4. >>>>>>> Be1 Kd4 5. Bf2+ Kxe4 6. Ba7 Kf4 7. >>>>>>> Bf2 Ke4 >>>>>>> >>>>>>>Don't know whether it will fail high at 18 or not, however... >>>>>> >>>>>> >>>>>>depth 18 analysis: >>>>>> >>>>>> (3) 18 13:55 0.31 1. ... b2+ 2. Kc2 exf4 3. Bxc3 f3 4. >>>>>> Be1 Kd4 5. Bf2+ Kxe4 6. Ba7 b1=Q+ 7. >>>>>> Kxb1 Kd3 8. h4 Ke2 9. h5 gxh5 10. gxh5 >>>>>> f2 11. Bxf2 Kxf2 12. Kc2 Ke3 >>>>> >>>>>I tried this on CM6000 and Rebel 10c but stopped after 30 minutes(this >>>>>on an AMD 233). The 11 minutes looks impressive to me. In your final analysis >>>>>on move number 9 rather than capturing with gxh5 the winning move is g5, >>>>>so that the black king can capture both of white's pawns. However in an actual >>>>>game Crafty would no doubt see that when it reached that point in the game. >>>>> >>>>>My guess is that we won't see to many people posting that program X >>>>>finds this one. Hope I'm wrong in this guess. >>>>> >>>>>Now I'm also wondering if tablebases will help here as after the initial >>>>>exchanges there remain two pawns each on the king's side? >>>> >>>> >>>>It was definitely probing tablebases during the search. The disk was very >>>>active due to the captures... >>> >>>Yes, Hiarcs was probing table bases during its search as well. Hiarcs found the >>>solution at the 21:04 minute mark and made the move shortly there after. The >>>Table Base print out that followed the Hiarcs search listing was: >>> >>>=+ (-0.26) depth 13/30 00:21:04 72203kn, tb=12 >> >> >>what does "tb=12" mean? My program did over 60,000 probes. If that means only >>12 were done, something is not done right in Hiarcs... > >Hiarcs is different than crafty so you cannot say that something is wrong with >it only because it does different number of probes. I have seen evidence to suggest that it is done wrong. IE I have no chance in a game where I try to access egtb's on CD. It is just _way_ too slow. Yet I hear of hiarcs users doing just this. That implies (to me) that he is not probing very deeply in the search, only "near" the root. That is _not_ as good as probing deeply, when it is done right... > >Maybe it does not call tablebases everywhere in the tree but only if it believe >that calling tablebases is going to save time. a hit _always_ saves time. Because you do _not_ search anywhere below a hit, you stop there, knowing the perfect score... > >If you are not close to the leaves of the tree then calling tablebases is >clearly saving time because the time of search is bigger then time of probing >but if you are close to the leaves then you lose time from calling tablebases >and it is not clear to me if the perfect information that you get is more >important then the time that you lose. > >Uri I tried several thousand games when I first did this. The current approach was much better... of course you only probe after a capture, and only after a capture where total pieces is <= 5.. that doesn't happen a rediculous number of times...
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.