Author: Frank Phillips
Date: 03:39:50 12/31/03
Go up one level in this thread
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.
> 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.