Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: New engine woes - Q search

Author: Nathan Thom

Date: 15:32:11 02/15/06

Go up one level in this thread


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.



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.