Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: quiesce node explosion

Author: Tord Romstad

Date: 10:14:10 01/26/04

Go up one level in this thread


On January 26, 2004 at 12:00:27, José Carlos wrote:

>On January 26, 2004 at 11:10:55, Tord Romstad wrote:
>
>>On January 26, 2004 at 02:53:37, José Carlos wrote:
>>
>>>On January 24, 2004 at 17:12:45, Tord Romstad wrote:
>>>
>>>>On January 24, 2004 at 15:57:50, Mike Siler wrote:
>>>>
>>>>>In an average middlegame position, around 80-85% of the nodes my program
>>>>>searches are quiesce nodes. I have a static exchange evaluator and I only search
>>>>>captures with SEE value > 0. It seems like other engines are always under 25%
>>>>>qnodes. What else should I be doing to reduce these numbers?
>>>>
>>>>Use the SEE more aggressively.  When the static eval is below beta, but
>>>>static_eval+(value of capturing biggest hanging enemy piece) > beta+margin,
>>>>return beta.  This is too risky unless your SEE is very sophisticated.
>>>
>>>  This doesn't make sense unless you do a real qsearch in your SEE, which is
>>>ridiculous of course.
>>
>>Yes.  That is why I don't do this at all nodes, but only when the evaluation
>>function reports that the current position is "sufficiently close to
>>quiescent" that it is safe to rely on the relatively simple SEE.
>>
>>Consider the simplest possible example:
>>
>>Assume that the side to move has no hanging, pinned or overloaded pieces,
>>and that the opponent has an undefended hanging piece.  If the static
>>eval plus the value of the hanging piece is considerably bigger than
>>beta, it is reasonably safe to return beta.  This works even with
>>a very simple SEE.
>>
>>>Otherwise, you simply assume the opponent doesn't have a
>>>capture anywhere else on the board that can bring his score above alpha
>>>again. I do not understand why you assume that.
>>
>>You are right, the presence of hanging pieces for the side to move elsewhere
>>on the board is one of the conditions you should look out for when deciding
>>whether you should search the captures or just return the SEE value of the
>>biggest capture.
>>
>>Tord
>
>  Thanks for the explanation. I was confused.
>  I do something similar in Anubis, but instead of adding complexity to SEE, I
>check it at the top of qsearch. If material is way below alpha and the opponent
>can't make a capture that makes it near alpha, then I fail low. I can detect
>attacks with a simple bitboard lookup so that's pretty cheap anyway. I guess
>your gain comes from not needing to make() the move, but it wouldn't work for me
>anyway because I won't know about attacks until I make the move and update my
>bitmaps.

No, avoiding the call to make_move() is just a tiny part of the gain.
I avoid having to generate moves, make the first move, call qsearch(),
evaluate the resulting position, and note that there is no capture
that can bring the score close to alpha.

I save one call to generate_moves(), one call to make_move(), one call to
qsearch(), and one call to evaluate().

Tord



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.