Author: Uri Blass
Date: 14:07:33 03/10/01
Go up one level in this thread
On March 10, 2001 at 16:16:47, Robert Hyatt wrote: >On March 10, 2001 at 10:41:18, Uri Blass wrote: > >>On March 10, 2001 at 10:05:04, Robert Hyatt wrote: >> >>>On March 10, 2001 at 03:34:19, Uri Blass wrote: >>> >>>>On March 10, 2001 at 02:55:29, Dann Corbit wrote: >>>> >>>>>On March 10, 2001 at 00:26:57, Michael Fuhrmann wrote: >>>>> >>>>>>[D] 8/8/7P/5kP1/5P2/r7/5K2/8 b - - 0 114 >>>>>> >>>>>> >>>>>>Crafty scores this as -3.26 for white on my computer, yet it seems to be a draw. >>>>>>I don't have all the 5-piece tbs. Is that the problem? >>>>> >>>>>I have the complete 5 piece tablebase file set. It does not seem to help much. >>>>>However, it is clear that it is a draw. The output of the chase below is rather >>>>>amusing. We might call it "I'll get that f4 pawn if it's the last thing I do!" >>>>> >>>>>Past the last actual search depth in plies, for each new search, it always ends >>>>>in Kxf4. But each time we go one more ply (when we have actually examined the >>>>>consequences of that horizon capture) it gets pushed out. It is clear that this >>>>>is a draw. >>>> >>>>It seems that the problem is that Crafty does not look at the tablebases in the >>>>last ply. >>>>Maybe probing the tablebases everywhere can help Crafty to get more realistic >>>>evaluation because it is not going to have wrong evaluation for KR vs KPP >>>>endgames and evaluation for KR vs KPPP endgames is going to be closer to draw. >>>> >>>>Uri >>> >>> >>>It isn't quite the "last ply". It is the first ply of the q-search, and I >>>don't probe there as it is too expensive. Which means the goal of the search >>>becomes "push the capture off to the q-search where I won't realize it is a >>>draw." I have seen this in rare positions before... :) >> >>I understand the reason that you do it in the first ply of the q-search(in this >>case it was also the last ply). >> >>I do not know if changing it in part of the cases can be an improvement. >> >>Some possible ideas: >> >>1)If the main line leads to tablebases position and if the difference between >>the evaluation of this position with tablebases and without tablebases is big >>enough then probe everywhere in the next iteration. >> >>2)compare evaluations with tablebases and without tablebases for 1 out of 100 >>positions when you probe the tablebases. >>If you get a big difference in significant part of the cases then probe the >>tablebases everywhere. >> >>3)Start the game with probing the tablebases also in the qsearch. >> >>If the number of tablebases hits in the last iteration is not big enough then >>continue probing the tablebases everywhere. >> >>Stop to probe the tablebases in the qsearch only when you get enough tablebases >>hits so you are afraid from a significant reduction in speed. >> >>Uri > > >You seem to have lots of good ideas/suggestions, all the time. Now I wish I >could teach you C so that you can implement them. :) I learned C but I never wrote big programs in C of more than some hundreds lines. Uri
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.