Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Unexpected problem with futility pruning ? Anymore opinions ?

Author: José Carlos

Date: 04:22:41 12/31/03

Go up one level in this thread


On December 31, 2003 at 06:39:50, Frank Phillips wrote:

>On December 31, 2003 at 03:41:40, José Carlos wrote:
>
>>On December 30, 2003 at 10:57:22, Frank Phillips wrote:
>>
>>>On December 30, 2003 at 05:26:42, Geoff wrote:
>>>
>>>>Hi Scott
>>>>
>>>>>yeh, I think you have a bug.
>>>>>
>>>>>firstly most people implement futility pruning _before_ makemove - you are
>>>>>basically trying to save the effort of make/unmake. You have to fiddle the score
>>>>>for captures a little, if you have SEE that is easy.
>>>>
>>>>Thanks for the help. I put the futility code in after the makemove to eliminate
>>>>the illegal moves that are filtered out by makemove(). It would be a problem if
>>>>I moved it earlier I think ?
>>>>
>>>>> secondly, you are pruning the wrong moves, given you have done makeMove,
>>>>> sideToMove has reversed, and you need to reverse a/b (-beta,-alpha), so you
>>>>> need to compare to -beta _not_ alpha, if you move the code to before
>>>>> makeMove you compare to alpha. I think you are throwing away beta nodes and > not alpha nodes.
>>>>
>>>>I was fairly convinced I was correct with using Alpha here but you might be
>>>>correct. I was thinking that alpha and beta swap when you call the search
>>>>function but not for just switching sidetomove in makemove().
>>>>
>>>>I had a quick look at razoring in Beowolf, from what I can see it prunes after
>>>>makemove() but uses alpha like I did ? That would seem to suggest I was correct
>>>>initially ? I need to have a longer think about this one it is getting confusing
>>>>now ;-)
>>>>
>>>>Anyone with a casting vote ? Should it check alpha or beta here ?
>>>>
>>>>        Regards Geoff
>>>
>>>
>>>Presumably you are trying to guess whether the score you are likely to get from
>>>searching the sub tree (of the  move you just made) will greater than alpha.
>>>
>>>ie
>>>
>>>if (your_score + margin <= alpha) then prune.
>>>
>>>Just make sure you test against your_score, which since you have moved will be
>>>-Evaluate()  if Evaluate returns the score for the side to move.
>>>
>>>I periodically try pruning, but never stay with it for long.  Here is some code
>>>I added to experiment quickly with pruning. MatBalanceXstm is a macro for the
>>>material balance from the perspective of the side _not_ on the move.  So if
>>>white just moved and I am deciding whether to search, then I am calculating
>>>(WHITE-BLACK).  Like you I made the move first before deciding whether to search
>>>the sub-tree, because I update some evaluation terms in makemove.
>>>
>>>(This saved nodes but not time, for me.).
>>>
>>>
>>>		//int cut_flag=FALSE;
>>>		next_depth=depth+dec;
>>>		if (next_depth<3 &&
>>>			!pboard->in_check[ply] && !pboard->in_check[ply+1] &&
>>>			MatBalanceXstm+razor[next_depth]<=alpha)
>>>		{
>>>			UnMakeMove(pboard,pmove,&pboard->node[ply]);
>>>			stat.cuts++;
>>>			continue;
>>>			//cut_flag=TRUE;
>>>		}
>>
>>  I assume !pboard->in_check[ply] means in check before making the move. Why
>>this? I mean, I'm trying to prune against alpha, meaning that my position is so
>>bad that I'm sure I don't have a chance to get back into the search window with
>>this move. In this case, being in check before making the move can't make my
>>position better, it makes it worse actually, so why care?
>
>Yes: I can see no reason to believe that the moves out of check are any more
>likely than other moves to be >alpha when they initially look bad.  If you
>already know (by the time you get here) that you have one or more legal moves
>out of check then you would not return a false mate score if you pruned all the
>moves.


  As suggested in other post, you can simply return alpha then. I do it
differently, I always try the first move (according to my move ordering), and
allow pruning all the others.

  José C.


>>  Note that I also make the move first because I don't want to prune moves that
>>put opponent king in check, which might actually be a good try to raise my score
>>above alpha (assuming you can't stand pat in qsearch when incheck, of course).
>>
>>  José C.



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.