Author: Vincent Diepeveen
Date: 14:36:26 04/28/04
Go up one level in this thread
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.
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.