Author: martin fierz
Date: 04:57:15 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
surprising, since the closer to the root of the tree you are, the less important
it gets to be fast vs intelligent. i.e. if you can order moves better and slower
vs worse vs. fast, then you should do the better and slower close to the root,
the worse and fast closer to the leaf nodes.
>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..........
this looks HORRIBLE! if you are doing this in the qsearch, fine, but you don't
state that. if you really do this, you will reject moves in your normal search
based on SEE alone, which is something you surely don't want to do !?
>
>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.
>
>Is that < alpha pruning just plain wrong or maybe just too severe, should I have
>a constant additional safety margin added on top ?
i use
if(current_eval + see(move) + safetymargin < alpha)
continue;
so i use the real evaluation, not the material eval, and i add a safety margin,
which at the moment is 1.5 pawns for muse. i haven't tested this extensively
though. i did some tests with 1.0 1.5 and 2.0 pawns, and they were rather
inconclusive.
cheers
martin
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.