Author: Uri Blass
Date: 12:23:19 05/04/03
Go up one level in this thread
On May 04, 2003 at 14:19:14, Jim Bond wrote: >On May 04, 2003 at 13:27:35, Uri Blass wrote: > >>On May 04, 2003 at 12:11:11, Jim Bond wrote: >> >>>On May 04, 2003 at 11:20:56, Uri Blass wrote: >>> >>>>On May 04, 2003 at 10:44:15, Jim Bond wrote: >>>> >>>><snipped> >>>>>>possible reasons for shredder's success in the endgame or gettting better >>>>>>endgames may be better search rules and better evaluation of endgames. >>>>>> >>>>>>Uri >>>>> >>>>>You are making sense. I only said in the beginning that Shredder's success in >>>>>the ending game COULD be PARTLY due to its ability to probe TB more often than >>>>>other engines. >>>> >>>>No >>>> >>>>It is very easy to teach programs to probe tablebases at every node but >>>>programmers found that it is counter productive because being significantly >>>>slower in nodes per seconds is not worth the extra knolwedge. >>>> >>>>I do not think that programmers of Fritz,Tiger are stupid and I assume that they >>>>tested and found that probing TB more often is not productive for them. >>>> >>>>Note also that I see no tablebases probes in analysis of shredder7.04 even when >>>>it is clear from the analysis that shredder is using them so I have no way to >>>>test your theory that shredder7.04 is using more tablebases than Fritz. >>>> >>>>Shredder7 reports about tablebases but the best shredder(7.04) does not report >>>>about tablebases. >>>> >>>>New game >>>>[D]7k/7p/8/P5p1/7P/8/8/6K1 w - - 0 1 >>>> >>>>Analysis by Shredder 7.04: >>>> >>>>1.hxg5 >>>> +- (#14) Depth: 1/1 00:00:00 >>>>1.hxg5 >>>> +- (#14) Depth: 1/1 00:00:00 >>>>1.hxg5 >>>> +- (#14) Depth: 2/2 00:00:00 >>>>1.hxg5 >>>> +- (#14) Depth: 3/3 00:00:00 >>>>1.hxg5 >>>> +- (#14) Depth: 4/4 00:00:00 >>>>1.hxg5 >>>> +- (#14) Depth: 5/5 00:00:00 >>>>1.hxg5 >>>> +- (#14) Depth: 6/6 00:00:00 >>>>1.hxg5 >>>> +- (#14) Depth: 7/7 00:00:00 >>>>1.hxg5 >>>> +- (#14) Depth: 8/8 00:00:00 >>>>1.hxg5 >>>> +- (#14) Depth: 9/9 00:00:00 1kN >>>>1.hxg5 >>>> +- (#14) Depth: 10/10 00:00:00 3kN >>>>1.hxg5 >>>> +- (#14) Depth: 11/11 00:00:00 7kN >>>>1.hxg5 >>>> +- (#14) Depth: 12/12 00:00:00 19kN >>>>1.hxg5 >>>> +- (#14) Depth: 13/13 00:00:01 74kN >>>>1.hxg5 >>>> +- (#14) Depth: 14/14 00:00:01 155kN >>>>1.hxg5 >>>> +- (#14) Depth: 15/15 00:00:02 288kN >>>>1.hxg5 >>>> +- (#14) Depth: 16/16 00:00:03 488kN >>>>1.hxg5 >>>> +- (#14) Depth: 17/17 00:00:05 791kN >>>>1.hxg5 >>>> +- (#14) Depth: 18/18 00:00:07 1255kN >>>>1.hxg5 >>>> +- (#14) Depth: 19/19 00:00:13 2253kN >>>> >>>>(Blass, Tel-Aviv 04.05.2003) >>>> >>>> >>>>Uri >>> >>>It looks like you might have a six men TB for this position already otherwise >>>you should see main lines. >> >>No >> >>There is a main line of one move that leads to 5 piece tablebase position >>shredder7.04 simply does not report the tablebases hits(shredder7 does). >> >>Shredder7 had tablesbases hits and 7.04 simply does not publish them because it >>is clear that without them it cannot see the mate. >> >>You probably do not have the KPP vs KP endgame tablebases so your shredder7 >>cannot see mate in 14 at the first plies. > >You are correct that it was done on an older PIII which has TBs installed but >that was sufficient to show you the TB probes which you were having trouble to >see right? You can't deny the fact that TB signficantly improved the accuracy >of the main lines. > >> >> You also should want to make sure you deleted the >>>shredder.plr (position learning file) in your engines directory before each >>>test. >> >>The poisition was a new position that shredder never saw before so no need to do >>it. >> >>> >>>Let me show you the difference between with and without TB. You will see that >>>without TB, shredder never for sure that there is a mate in 14 whereas with TB, >>>Shredder knows for sure there is mate in 14 in 4 seconds (slower PIII machine). >>>That is the power of TB. >> >>I know that tablebases can help to see the exact distance to mate but the point >>is that the exact distance to mate is important only when you have already a >>winning position and you need to win it. >> >>It is possible to save time by not probing tablebases in cases when the score is >>not high and you do not care if against some illogical line you win in 20 moves >>or in 18 moves. > >That's exact the point, the score is high in one depth does not always guarantee >the score is high in later depths. You do not understand my point. It is possible to know that position is winning without tablebases in part of the cases with 100% certainty and the program can detect it and save the expensive time of looking at tablebases in case that the score is not a winning score. In case that the score is a winning score(I talk about +7 and not +2) in more than 99% of the cases the program win even without tablebases so these positions are not very important. The only important thing is to be careful to have no new bugs. The idea that I suggested may create a new bug if the program has a winning position because if it is going always prune positions when it can win then it is possible that it will be able to make no progress in KR vs K positions. This is the reason that the pruning should be done only when you do not know that you win. Uri
This page took 0.04 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.