Author: Robert Hyatt
Date: 09:38:45 09/24/99
Go up one level in this thread
On September 24, 1999 at 12:05:44, Wayne Lowrance wrote: >On September 23, 1999 at 22:19:15, Robert Hyatt wrote: > >>On September 23, 1999 at 21:28:24, Wayne Lowrance wrote: >> >>>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 >> >>what I said was that Hiarcs is not probing the tables in an optimal way. In >>the same time that I probed 60,000 times, he probed < 50 times, assuming that >>is what the number means. That is not particularly great for a search that >>size. I didn't knock hiarcs. I only pointed out that the way it is probing >>the tablebases seems to be sub-optimal. Nothing more. Nothing less. >> >>And it isn't about "bias" at all, any more than saying that a quick sort is >>better than a bubble sort. It is a simple statement of observed fact... >> >> >>>> >>>>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 !> >> >> >>And your point would be? Depth is not important. Total time is important. In >>this position, the tablebases really are not causing the programs to find the >>right move, it is tactics. > >Reflecting on what you have just said "it is tactics", perhaps ur right. Hiarcs >program did promote the pawn move from away back to the number two best in just >17 seconds, and it did that without tablebases ! It was not until the 4 minute >mark that tablebase access first popped up. I just ran this test on my notebook. I stopped it after 11 seconds, when it finished 11 plies. It has already done 16 successful probes by that point (I don't have all tablebases on my notebook, so some probes failed). You can only imagine what it does by the time it gets to depth=18 or so... >> >>As far as "who is to say what is right?" Perhaps someone that has been doing >>this for > 4 years? I've had time to try several different options. I didn't >>just release a version that probes in the search. Most refused to do it until >>they _saw_ that it worked in Crafty and Ferret. Everyone was probing only at >>the root until we started doing this in the search... In fact, Bruce and I were > >Yep I recognize that I have been too defensive concerning Hiarcs (why I dont >know I have no interest in it). I respect Bobs comments and I am not qualified >to debate programming technique with him. When I scan the posts of this forum I >_always_ read everything he says, _everything_. This ends this thread from me. > No reason to stop. The comparison is definitely interesting. As the commercial engines are just getting started with tablebases, and still have a learning curve to get over. "Trial by fire" (playing lots of real games against incredibly strong opponents) is one way to figure out whether what you are doing is good or bad. ICC is a _real_ fire to jump into. :) When you play about 50 games vs a group of three GM players, as I did the other day (vic11, cptnbluebear, udav) you _quickly_ learn if you are doing something that is not so good. or if it is _very_ good... I don't give the tablebases a second thought any more, the code works and works well. >>using the tablebases before _any_ of the commercial programs were. >> >>Perhaps 'experience' counts? or perhaps not... >> >> >> >> >>>> >>>> >>>>> >>>>>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.