Author: Antonio Dieguez
Date: 11:46:27 12/29/01
Go up one level in this thread
On December 29, 2001 at 14:20:18, Severi Salminen wrote: >Hi! > >I made a run with Requiem on position (1.e4 e5 2.d4 d5) > >[d] rnbqkbnr/ppp2ppp/8/3pp3/3PP3/8/PPP2PPP/RNBQKBNR w KQkq - 0 1 > >I let the engine increment a counter every time it called qsearch() at certain >depth. The numbers include only 10 ply search, not previous iterations. I want >to emphasize that this "experiment" only applies to this particular (allthough >quite typical) position. This was the output (the interesting part is at the >end): > >Requiem v0.50, Copyright (C) 2001 Severi Salminen >All rights reserved. > >rnbqkbnr >ppp..ppp >........ >...pp... >...PP... >........ >PPP..PPP >RNBQKBNR > >CW: 129 CB: 129 EP: 0 > > Time Depth Score Nodes PV > 0.00 1 0.00 8 dxe5 > 0.00 1 0.03 30 h3 > 0.00 1 0.06 48 g3 > 0.00 1 0.07 100 Nf3 > 0.00 1 0.12 121 Be2 > 0.00 (1) 144 > 0.00 2 0.03 307 Be2 Be7 > 0.00 2 0.05 1060 Bb5+ Bd7 Nc3 > 0.00 (2) 1299 > 0.00 3 0.05 2544 Bb5+ c6 Be2 Nf6 > 0.06 3 0.14 4113 dxe5 dxe4 Bc4 > 0.06 (3) 4519 > 0.06 4 0.15 5974 dxe5 dxe4 Qxd8+ Kxd8 Be2 > 0.11 (4) 9590 > 0.16 5 0.11 14031 dxe5 dxe4 Qxd8+ Kxd8 Bc4 Bb4+ Bd2 > 0.38 (5) 28645 > 0.49 6 0.17 39164 dxe5 dxe4 Qxd8+ Kxd8 Bc4 Nc6 Bxf7 > 0.82 (6) 62199 > 1.21 7 0.17 91852 dxe5 dxe4 Qxd8+ Kxd8 Nc3 Bb4 Bg5+ f6 Rd1+ Bd7 > 2.97 (7) 213308 > 4.61 8 0.21 335261 dxe5 dxe4 Qxd8+ Kxd8 Bc4 Nc6 Bf4 Nh6 Bxh6 > 8.68 (8) 660117 >13.62 9 0.24 1075397 dxe5 dxe4 Qxd8+ Kxd8 Bg5+ f6 exf6 gxf6 Bd2 Be6 Bb5 >27.02 (9) 2055337 >41.08 10 0.36 3179248 dxe5 dxe4 Qxd8+ Kxd8 Nc3 Nc6 Bg5+ Ke8 Bb5 h6 >Bxc6+ bxc6 Be3 >68.27 (10) 5121547 > >Eval: 0.36, time: 68.27, nps: 75019 >Nodes: 5121547, (qnodes: 3506216, leaves: 2790857) >Futile moves: 2783942, ordering: 96.2% > >Ply: 8, count: 258910 >Ply: 9, count: 453813 >Ply: 10, count: 345434 >Ply: 11, count: 281178 >Ply: 12, count: 246945 >Ply: 13, count: 176222 >Ply: 14, count: 77837 >Ply: 15, count: 32984 >Ply: 16, count: 11041 >Ply: 17, count: 3329 >Ply: 18, count: 1219 >Ply: 19, count: 399 >Ply: 20, count: 105 >Ply: 21, count: 39 >Ply: 22, count: 7 >Ply: 23, count: 3 >Ply: 24, count: 1 > >Total: 1889466 (manually counted) > >What can be seen, is that 97.4% of qnodes remain below ply 14 (0=root). The >reason for qnodes at ply=8 and ply=9 is of course null moves. So performance >wise you won't get much by limiting qsearch depth. On the other hand by limiting >qsearch and returning static score would have allways resulted totally wrong >score. I don't know if that would have affected PV or something else but there >is a great risk. This was with SEE, I don't know how SEEless engine would do, >probably the distribution would be wider and longer. > >I made a few games between version with limiting and one without. Limiting to 1 >and 2 resulted horrible tactical mistakes. At 3 the "handicapped" version played >more securely but lost. It would have definitely played worse without SEE >because SEE still gives you allmost accurate scores for every capture (pins, for >example, will affect this) even if you don't actually search them: with SEE you >can prune seemingly losing captures easily. hello! After 1.e3 e5 2.Nf3 Nc6 3.Bb5 a6 in the qsearch, the expected material gain for Bxc6 is not at least a pawn? and if the d7 pawn doesn't exist, do you prune Nxe5? thanks.
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.