Author: Tony Werten
Date: 14:49:43 11/20/02
Go up one level in this thread
On November 20, 2002 at 17:31:57, Omid David Tabibi wrote: >On November 20, 2002 at 16:55:41, Gian-Carlo Pascutto wrote: > >>Nullmove in Deep Sjeng uses an algorithm of my own, but I can >>switch it back to other systems easily. I did so for running >>a few tests. >> >>I made a version which uses Heinz Adaptive Nullmove Pruning >>and a version which uses your verification nullmove. >> >>I did a run over ECM-GCP, at 10 seconds per position. >> >> >>So, you can see here that verification nullmove searches 20% more >>nodes, took 12% more time, searched 1/3 of a ply less deep and >>missed three more positions. >> >>That's pretty much a 'total loss' :) >> > >That is a typical result when the quiescence search is too big. With the help of >its extensions, even the standard version of your algorithm manages to detect >most of the problems that verified null-move is meant to detect. So the >verification search is just a waste of time in this case (and since your test >was conducted in a fixed time per position, this waste of time didn't enable the >verified version to reach deeper and detect what the other version did). > >Solution: > >By shifting to a far simpler quiescence search, you will get about the same >tactical strength as you get currently (since this time, verified null-move will >detect the problems, instead of your immense quiescence), but will end up with a >significantly smaller search tree. And positionally a weaker program :( Tony > >The quiescence search of Genesis which I conducted the tests on, consisted of >only captures/recaptures. > > >>-- >>GCP
This page took 0.03 seconds to execute
Last modified: Thu, 07 Jul 11 08:48:38 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.