Author: Vincent Diepeveen
Date: 15:39:55 02/15/06
Go up one level in this thread
On February 15, 2006 at 18:32:11, Nathan Thom wrote: >On February 15, 2006 at 17:59:59, Vincent Diepeveen wrote: > >>On February 15, 2006 at 17:52:35, Nathan Thom wrote: >> >>>My engine is still very young (aptly named LittleThought) and I'm having some >>>issues explaining its behaviour. Features so far: >>>- Iterative Deepening >>>- AlphaBeta with limited move ordering (only captures are scored so far, with >>>SEE) >>>- Eval is simply material+piece sq >>>- Q search non-losing captures+checks+proms >>>- No hashing, no extensions, no pruning >>> >>>I just put in the Q search and a test run of 20 secs from the opening gives: >>> >>>With Q Search >>> >>>00:00:00.00 20n 1/1 0.58 1. e4 >>>00:00:00.01 512n 2/2 0.08 1. e4 d6 >>>00:00:00.01 2364n 3/4 0.00 1. h3 h6 2. g3 >>>00:00:00.03 9224n 4/6 0.00 1. h3 h6 2. g3 h5 >>>00:00:00.18 88Kn 5/9 0.00 1. h3 h6 2. g3 h5 3. f3 >>>00:00:00.65 361Kn 6/17 0.00 1. h3 h6 2. g3 h5 3. f3 h4 >>>00:00:12.97 8628Kn 7/37 0.00 1. h3 h6 2. g3 h5 3. f3 f5 4. e3 >>>00:00:20.00 13Mn 8/38 0.00 1. h3 h6 2. g3 h5 3. f3 f5 4. e3 >>>Total Nodes = 994854 >>>Total Q Nodes = 866141 >>>Total Beta Cuts = 99773 >>>Total Q Beta Cuts = 459231 >>> >>>Then I wanted to see how deep it could get without Q search, assuming it should >>>get further due to less Q nodes searched: >>> >>>Without Q Search >>> >>>00:00:00.02 20n 1/1 0.58 1. e4 >>>00:00:00.05 512n 2/2 0.08 1. e4 d6 >>>00:00:00.08 10Kn 3/3 0.56 1. e4 d6 2. d4 >>>00:00:00.31 148Kn 4/4 -0.05 1. Nf3 d6 2. e4 e5 >>>00:00:02.23 1468Kn 5/5 0.93 1. e4 e6 2. Bc4 d6 3. Bxe6 >>>00:00:20.00 16Mn 6/6 -0.42 1. d4 Nf6 2. Nf3 Nc6 3. e4 Nxe4 >>>Total Nodes = 2709329 >>>Total Q Nodes = 0 >>>Total Beta Cuts = 184327 >>>Total Q Beta Cuts = 0 >>> >>>This really surprised me and I still cant explain it properly. It searched more >>>nodes overall but to a lesser depth. My feeling is that its to do with beta >>>cutoffs and the Q search was somehow causing more of them, but after counting >>>them I see that the beta cuts within the normal search tree is actually less >>>when Q search is turned on. >>> >>>I'm sure its somehow related with the fact that the Q search seems to return >>>scores of 0.0 all the time (which sounds right as the opening is very stable) >>>and without the Q search, the scores seem to alternate +/- depending on who made >>>the last move. Also without the Q search, the moves seem to be smarter and make >>>use of the piece square tables more. >>> >>>Does it sound like a bug, or is this expected behaviour? >> >>expected behaviour. >> >>without qsearch after 1.e4,h5 the 1 ply search of Qxh5 is winning for white. >>Reason is obvious: white can capture a pawn without black having a chance to >>recapture. you need to 'quiet' out the position to eval. Which happens after >>Rxh5. So trying moves in qsearch to return a balanced score is crucial. >> >>Vincent > >Thanks, I understand. However, why wouldn't the Q search return moves like e4 or >d4 as the piece square tables favour that over something stupid like h3. You didn't explain how your scoring system works. On the other hand, i remember Uri once defending 1.h3 as a reasonable test opening. So why not ask Uri? In general however, bugs in engines explain a lot. Like perhaps you return the positional score for the wrong side. Automatically it will try to pick the worst move then as you are not doing a minimax then but a maximin :) Vincent
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.