Author: Robert Hyatt
Date: 07:58:23 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 ?
>
>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
This is backward thinking. Look at how many qsearch nodes there are vs the
non-qsearch nodes. Yet you are using your "slow SEE" where you use it far more
often than if you used in in non-qsearch only. :)
The vert first "layer" of q-search nodes is as big as all the non-qsearch nodes
added together. Yet you have more than one layer of 'em to deal with.
>
>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..........
That is OK. There is a better test, in that if the current alpha value is 0.0,
the current material balance is -5.0 (down a rook) then capturing a pawn is
futile even if it is a safe capture because -5 +1 is still below 0.0 and the
capture will fail low and waste the time spent.
Also are you doing this for _all_ moves or just captures???
>
>
>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
>
>
>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.
I add in one more component, a "worst-case positional score". IE if you can
produce a positional score of +3.0 (no material factored in) then you need to
adjust your window above to account for that.
I do all of this and do not see any problems in test sets or playing games
myself...
>
>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.