Author: Vincent Diepeveen
Date: 14:50:43 04/28/04
Go up one level in this thread
On April 28, 2004 at 17:36:26, Vincent Diepeveen wrote: >On April 28, 2004 at 17:04:27, Gerd Isenberg wrote: > >>On April 28, 2004 at 16:50:56, Vincent Diepeveen wrote: >> >>>On April 28, 2004 at 15:03:41, Gerd Isenberg wrote: >> >><snip> >> >>>>I thought BT-test positions are from some gm matches? >>> >>>They just have tried to locate anti-positional near to random positions where >>>computers had problems with AFAIK and nullmove especially. >>> >>>So positions where bruteforce is not doing bad. >> >>aha, interesting. >> >>> >>>So if you do less selective search somehow in such positions, especially near >>>the leafs knowing the poor qsearch from isichess, i am sure that will be >>>helpful. >>> >> >>I'm always impressed how you appraise other programs. >>Thought my qsearch and huge eval too is one of the most sophisticated ;-) >> >>>As long as you do not realize that, then we will continue misunderstanding each >>>other here. >>> >> >>Sorry i don't get that. >>Anyway thanks for your stimulations and lessons. >> >>Gerd > >It's not meant as a lesson. And i definitely do not want to get down your work. >But i hope you realize the only thing Omid's verification search implementation >is doing is at the first few nodes, especially those crucial nodes around PV to >add another ply of search at the last ply. > >Just write down for the first 100 inner nodes you visit (not counting qsearch) >what *exactly* it is doing. > >It just adds a ply of search there. > >So trivially you are missing something either in eval or qsearch then. > >The difference with adaptive nullmove is just that it always adds that ply, so >adaptive nullmove will protect the PV just as good as find other shots. > >I never knew what to do the last 4 ply of my search. We all struggle with the >same problems there. I do know however that verification search is not the way >to go as it has hashtable bugs. by the way the emergency solution i do now in diep which works bad is: I try R=3 always. If depthleft == 4 && eval(position) < beta+450 then try R=2 It sucks. I'm going to do something else there. Johan had to tell to me again the truth there in ict4 on how bad diep sucks there :) That's what people do not realize here at CCC. In those tournaments i learn more than at internet *ever*, simply because no commercial is objectively posting here but just seeing it here as a chatbox. Yet the above code is already working a lot better than verification. Verification will always add a last ply which doesn't ever happen here. So the overhead of verification search is *huge*, especially if you consider how big my qsearch is. 80%+ of all diep's node in openings search are already qsearch nodes.
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.