Author: Uri Blass
Date: 18:30:48 02/15/06
Go up one level in this thread
On February 15, 2006 at 18:39:55, Vincent Diepeveen wrote: >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? This is distortion of what I said. I said that strong engine can win even with 1.h3 to get the opponent out of book. I did not say that it is reasonable for engine to choose 1.h3 in the opening position. It is clear that choosing 1.h3 in the opening is probably result of a bug. Uri
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.