Author: Wayne Lowrance
Date: 18:28:24 09/23/99
Go up one level in this thread
On September 23, 1999 at 16:18:36, Robert Hyatt wrote: >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. Just one thing my tablebases are stored on hard drive. I find it hard to fault the program and its author's in there implementation. The fact is it worked ! on a single pentium 11 @ 400 mhz. You are unfair by declaring that Hiarcs has a problem based on your implementation of crafty to make this judgement. Not a very unbiased stance I think > >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... Who's to say whats right ? What is right is, Hiarcs tablebase accessing works, at least in this difficult positiom and it did not need a quad Xeon system to do it, and it found the correct move at depth 13 !> > > >> >>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.