Author: Steve Maughan
Date: 06:08:14 06/14/04
I've been tinkering with Monarch's qsearch and wondered if I could get some
input from other engine authors as to best practice for the quiescent search.
Take for example this random (TWIC500) middlegame position:
[D]2r2rk1/1p1b1p2/1p4pp/3pPnQ1/3P4/5P1P/PPB2BP1/R3R1K1 b - -
There's nothing special going on and here's Monarch's analysis:
Engine: Monarch 1.1 (64 MB)
by Steve Maughan
3/04 0:00 -3.78++ 24...hxg5 (729)
3/04 0:00 -1.52 24...hxg5 25.Bd3 Ne7 (861)
4/07 0:00 -1.48 24...hxg5 25.Bd3 Rfd8 26.g4 (2.388)
5/09 0:00 -1.51 24...hxg5 25.Bd3 Ne7 26.Be3 Nc6 (8.013)
6/11 0:00 -1.57 24...hxg5 25.Bd3 Ne7 26.g4 Nc6 27.Rad1 (18.410)
7/13 0:00 -1.51 24...hxg5 25.Bd3 Ne7 26.a3 Rfe8 27.Be3 Nc6 (64.452)
8/15 0:00 -1.49 24...hxg5 25.Bd3 Ng7 26.h4 gxh4 27.Bxh4 Ne6 28.Be7
(218.401)
9/19 0:00 -1.49 24...hxg5 25.Bb3 Be6 26.g4 Nh4 27.Bd1 f6 28.f4 fxe5
(629.445) 750
10/20 0:01 -1.48 24...hxg5 25.Bb3 Be6 26.g4 Nh4 27.Re3 f6 28.exf6 Rxf6 29.f4
(1.060.099) 858
11/23 0:07 -1.47 24...hxg5 25.Bd3 Ng7 26.Be3 Ne6 27.g3 f5 28.f4 gxf4 29.gxf4
Rfe8 (7.291.429) 895
12/24 0:12 -1.48 24...hxg5 25.Bb3 Bc6 26.Rad1 f6 27.Rd3 Rc7 28.g4 Ne7 29.e6
f5 30.Bc2 (12.437.456) 945
13/28 0:19 -1.47 24...hxg5 25.Bb3 Bc6 26.Rad1 f6 27.Rd3 Rc7 28.a4 Rg7 29.g4
Ne7 30.e6 f5 (18.894.237) 957
14/29 0:58 -1.47 24...hxg5 25.Bb3 Bc6 26.Rad1 f6 27.Rd3 Ng7 28.exf6 Rxf6
29.Re5 Rf5 30.Re7 Re8 31.Rde3 (57.553.890) 964
15/16 1:22 -1.47 24...hxg5 25.Bb3 Bc6 26.Rad1 f6 27.Rd3 Ng7 28.exf6 Rxf6
29.Re5 Rf5 30.Re7 Re8 31.Rde3 (79.374.564) 978
best move: h6xg5 time: 1:22.929 min n/s: 957.369 nodes: 79.374.564
Total Nodes : 79374564
Quiescent Nodes : 26210648 (33.0%)
Leaf Nodes : 38072779 (48.0%)
Hash Probe Effectiveness: 28.2%
Move Order Effectiveness: 93.1%
I define leaf nodes as positions that return a score without calling any move
generation routine; quiescent nodes are those that call a move generation from
within the qsearch and the others are those that call a move generation routine
from within the main search (alpha_beta) includung null moves.
So you can see that of the 79 million nodes searched 26 million (33%) were in
the qsearch. This seams a bit high to me considering that 38 million (48%) were
leaf nodes. Currently I'm doing check in the first ply of the qsearch and SEE
based pruning. The pseudo code looks like the following:
if in_check
generate all moves and handle as a normal node
else
e = evaluate();
if (e>=a){
if (e>=b){
leaf_nodes++;
return e;
}
a = e;
}
if (max_check_ply >= current_ply){
move_count = generate_check_captures(); //GENERATE ALL GOOD CAPTURES &
CHECKS (ONLY DONE ON THE FIRST PLY OF THE QSEARCH)
}
else if (e+90>a){
move_count = generate_all_good_captures(); // GENERATE ALL GOOD CAPTURES
}
else
//GENERATE ONLY THE GOOD CAPTURES THAT WILL GET THE SCORE CLOSE TO ALPHA
move_count = generate_captures_with_threshold(p,a-e-90);
Loop though all the moves as normal...
Of course the '90' in the above pseudo code is somewhat arbitrary.
So two questions:
1. Are Monarch's ratios of qnodes and lead nodes to total nodes reasonable?
2. What else can I do improve my QSearch?
Thanks,
Steve
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.