Author: Fabien Letouzey
Date: 04:09:51 07/23/04
Go up one level in this thread
On July 22, 2004 at 20:50:14, Jan K. wrote: Hi Jan, >Hi, i have seen in fruit and in other engines too that there is no test if >(remainingDepth-rFactor-1)>(=)0 before doing null move, only >remainingDepth>=someConstant, which means making many cutoffs based only on the >values given by qsearch. That gived a very nice speed up when I tried it, but I >soon found that my engine makes mistakes in some positions like this one, where >it shows a draw after <almost every move> <e6e2> <d3c4> <f7g6> <c4d3>, altough >only <d3c4> doesn't lose(normally seen at depth 5): About when to try null move, I think "depth >= 2" is the most common. Most authors haven't had any success with pure null move at depth 1 (static threat detection is possible but is not "null move" IMO). At the same time most see benefit in using it at depth 2 and up. >[D]8/5kpp/4rp2/2p5/PP1p4/3Q2PP/2P2q2/R1B4K w - - 3 30 >it didn't help when I used verification search, checks in qsearch.... >But Fruit doesn't seem to have a problem so do I have a bug or just miss >something? :)) No hidden trick that I know of. I tried different combinations of my null-move parameters and this position was always solved correctly. All I can say is that when not trying any checks in the qsearch, one more ply was needed. I can't reproduce your problem with my engine (with any settings) and I haven't studied this position. In general I get the impression that Fruit is relatively quick at obtaining a draw score, not necessarily correctly. Don't forget that draw scores are evaluation-dependent. Draw trees usually contain side lines with negative evaluation. The score of one of these nodes can become positive at larger depth. Draws are tricky. Sorry I can't help you more. Feel free to ask specific questions though. Fabien.
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.