Author: Vincent Diepeveen
Date: 15:59:58 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?
>
>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
Hi, some more thoughts on this subject, not taking into account extensions and
not a lot of good other interesting things :)
Something like this, of course using fail soft alfabeta and principal
variationsearch.
int qsearch(int alfa,int beta,int side) {
int eval;
eval = evaluate(); // evaluate returns score from white side
if( side )
eval = -eval;
if( eval >= beta ) return eval;
generateinterestingmoves(side);
for( all interesting moves ) {
score = -qsearch(-beta,-alfa,side^1);
if( score > eval ) {
eval = score;
if( score >= beta ) break;
}
}
return eval;
}
int pvs(int side,int alfa,int beta,int depthleft) {
int bestscore;
if( depth <= 0 )
return(qsearch(alfa,beta,side));
pick( first move );
bestscore = -pvs(side^1,-beta,-alfa,depthleft-1);
if( bestscore >= beta ) return bestscore;
for( all moves ) {
int tempscore = -pvs(side^1,-alfa-1,-alfa,depthleft-1);
if( tempscore > alfa && tempscore < beta )
tempscore = -pvs(side^1,-beta,-alfa,depthleft-1);
if( tempscore > alfa ) {
bestscore = tempscore;
if( tempscore >= beta ) break;
alfa = tempscore;
!!!!! // here you should update your mainline in a correct manner !!!
}
}
return bestscore;
}
Please try to use good programming habits, for example some strong commercial
programmers really have very bad habits here which you should not take over.
Like i use clearly a local side to move. That's a better programming habit than
for example Rybka from which i am guessing it is using a global side to move
variable.
That is very ugly way to program an engine and should be avoided!
It might prevent some bugs in your program which we all had :)
Also try to avoid the 'goto' command and such.
Vincent
p.s. apologies for using the name rybka in this thread, but as it seems to be
the accepted standard here i thought i should follow this fashion; just like in
the CSS forum i always use the name Fritz in every posting i write there.
Of course the CSS has not my support because it is a commercial forum. If CCC
follows that fashion as suggested by a certain US Citizen who already posted
some time ago he left this forum, then obviously this forum no longer has my
support either.
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.