Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Position for Endgame Tablebase programs

Author: Wayne Lowrance

Date: 09:07:00 09/23/99

Go up one level in this thread


On September 23, 1999 at 10:24:20, Wayne Lowrance 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...
>
>Sorry Bob I do not know the answer. I can tell you that the table base search
>printout varied from time to time. In the Hiarcs instructions for loading the
>tablebases it illustrated a printout like  the one i posted except the "tb=12"
>of course was different. I do not think that it is related to the number of
>probes but rather it appears to me to be a root position of the table base that
>the captures sent it to !. I have noted in other positional encounters that the
>tablebase (tb= ?) value increments random, that is to say it can jump to a very
>much larger value then back down to a lower value. Please, that is my
>obervation. It was interesting to me Bob that b2+ was Hiarcs 2nd best move in
>its evaluation very very early on (i wish i kept track of exactly when).
>
>On the other hand Fritz5.32 is running right now without tablebases and is at
>the 33 minute mark at depth 19 where as Hiarcs found the move at depth 13. I
>doubt it is  going to find b2+ as b2+  is still down to number 11 position in
>Fritz5.32 evaluation.
>
>I forgot to mention Hiarcs/Fritz are running on a pentium 11 400 mhz with hash
>set at 128 meg.
>Fritz5.32 is still wrestling with the problem at the 48 minute mark and is no
>where near finding b2+. gonna stop it and put it out of its misery !

Ran Hiarcs again and here is what happened !
1) It took Hiarcs 17 seconds to promote b2+ to second on its evaluation.
2) The tablebase print out did not appear until depth 12 at the 4:55 second
mark. The complete tablebase listing follows.
       =(-0.18) depth 12/30 00:04:55 18018kn tb=4
       =(-0.05) depth 13/30 00:11:28 41806kn tb=9
       =(-0.36) depth 13/30 00:19:10 68488kn tb=10
       =(-0.45) depth 14/31 00:38:38 137098kn tb=44

At depth 14 Hiarcs maintained b2+ as its move but the line and table base value
changed as well.
here is the move lines.

At the 10:10 min mark:  1..b2+ 2. Kc2 exf4 3. Bxc3 f3 4. Be1 Kd4 5. Kxb2 Kxe4
6.Bf2 Kd3 7. h4 Ke2 8. Bg3 Ke3 9. Bb8  (tb=10), depth 13/30, eval. =-0.36

At the 38:38 min mark:  1..b2+ 2. Kc2 exf4 3. Bxc3 f3 4. Be1 Kd4 5.e5 Kxe5 6 Bf2
Ke4 7 Bc5 b1Q 8. Kxb1 Kd3 9 h4 Ke2  (tb=44) depth 14/31, eval. =-0.43

I wish to retract a positive stateme previously made. In view of this second
run, seeing that table base searches are increasingly positive value, My recall
of the tablebase value changes being random, _may_ or _may not_ be accurate !
I continue this thread because of the opinion expressed that Hiarcs has a
problem because crafty took 60000 probes and the intrepetation that Hiarcs took
12 probes. I don't think that the crafty 60000 probes is in any way equated to
tb=x in Hiarcs.
I have played multiple hundreds of games without incident and in the month that
Tablebases have been loaded into Hiarcs I have encountered zero apparent mal
function. Hiarcs has found b2+ move twice now so that is not by accident albeit
I am confused that this time it referred to table base 10 as opposed to 12.
p.s. Hiarcs now at depth 15 and b2+ is still its preference with move listing
and table base value unchanged from depth 14 value.



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.