Author: Richard Pijl
Date: 04:20:43 10/18/04
Go up one level in this thread
On October 18, 2004 at 07:01:50, GeoffW wrote:
>Hi
>
>I have been experimenting with the SEE code in my program. I had not had great
>results with it previously so thought I should revisit it. I was fairly sure
>that it was bug free as it seemed to noticeably reduce my node count but the
>extra time it took to calculate seemed to about break even.
>
>Anyway looking at it again, I am using it now in 3 ways, I thought what I am
>currently doing is fairly standard practice ?
Depends on the type of quiescense search you have: Lean and mean (like Crafty),
or more extensive (like many others). The more precise the score returned from
your quiescense search, the more errors in it will be bothering you (as you will
not have the additional plies of regular search).
>
>1)
>I am using SEE to order the capture moves in my Q search.
>Move ordering in the normal search is still MVVLVA as my SEE is quite slow
>
>2)
>I am using the SEE score for a capture to prune moves at generation time
>Bit of pseudoCode
>
>addMoveToMoveList()
>{
>#ifdef USE_SEE
> if (scoreBasedOnSee(sideToMove,from,to) < 0)
> return;
>#endif
>etc..........
>
>
>3) In my quiesce() routine I have
>
>
>/* material balance is always positive for side to move if that side is up in
>material */
> materialBalance = evalMaterialOnly();
>
> for (i = firstMove[ply]; i < firstMove[ply + 1]; ++i)
> {
>
>/* if we are down on material then we can prune off these quiescent moves fairly
>safely as the SEE score plus material is still worse than a previous move
>denoted by alpha */
>
> if ((S32)gen_dat[i].seeScore + materialBalance < alpha )
> continue;
> }
>
>etc...... makemove() then quiesce() recurse again
This looks wrong to me, even with a small qsearch. I assume you have the eval
score anyway, so better to me looks something like
evalscore+seescore+margin<alpha
Margin is needed to compensate for the changes of the evaluation by performing
the move.
I'm not doing this in the Baron though.
Richard.
>
>
>The results I have got so far with these 3 sections of code seemed promising as
>I was managing to search deeper, but my results in games appears to be
>noticeably worse. I suspect the 3rd code snippet is what is making my program
>worse although I am not really sure.
>
>Is that < alpha pruning just plain wrong or maybe just too severe, should I have
>a constant additional safety margin added on top ?
>
>Any thoughts appreciated, thanks
>
> Regards Geoff
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.