Author: Vasik Rajlich
Date: 01:34:45 04/02/04
Go up one level in this thread
On April 02, 2004 at 02:11:48, Tord Romstad wrote:
>On April 02, 2004 at 00:41:48, Dann Corbit wrote:
>
>>On April 02, 2004 at 00:37:22, Artem Pyatakov wrote:
>>
>>>Dann,
>>>
>>>That was a very nice reply - I will incorporate the feedback.
>>>
>>>>If you keep a table of the counts of attack by piece type for each square, you
>>>>don't have to bother with quiescence. The question in that case is whether it
>>>>is better to do the work of updating the tables or to do the work of >quiescence.
>>>
>>>Is this really true? Can you explain how? Because I do have attack tables in my
>>>program and I don't understand how this can help me avoid qsearch. Thanks!
>>
>>You need more than the attack tables. You need counts of attacks by piece type
>>for every square.
>>
>>The strongest attack is a pawn attack. If you have 2 white pawn attacks and one
>>black pawn attack, the square is won by white no matter what other pieces attack
>>it (of course if you move one of the pawns to the square then the pawn attacks
>>decreases by one).
>>
>>So do this for every square under attack:
>>(white pawn attacks) - (black pawn attacks) {if zero, you are concerned about}
>>(white piece attacks) - (black piece attacks) {knights and bishops}
>>(white rook attacks) - (black rook attacks)
>>(white queen attacks) - (black queen attacks)
>>(white king attacks) - (black king attacks)
>>
>>And the same for pins (you will want to track the pinned pieces and xrays)
>>
>>If you track it for not only the attacked pieces but also the attacked squares,
>>then you can know if an empty square is safe to step on for a given piece type.
>
>The problem with substituting a qsearch with something like this is that
>you only consider the purely material consequences of captures and exchanges.
>It is not at all unusual that an exchange dramatically changes some of the
>positional components of the evaluation function. Such changes are hard
>to estimate without actually making the captures and evaluating the resulting
>positions.
>
>In the past, some engines tried to save processor time by not calling the
>full evaluation function in the qsearch. Instead, they just counted the
>change in material and added this to the eval at the horizon depth. Most
>authors have abandoned this approach today, because the loss in positional
>understanding was too big. Substituting the whole qsearch with a very
>sophisticated SEE would have similar bad consequences, I think.
>
>Tord
Tord,
I thought you do this yourself (ie SEE rather than qsearch) when the position at
the start of qsearch meets certain criteria. (ie is quiet enough)
Qsearch is an ugly method.
One point is that it throws the balance of the search out of whack. At every
node, the remaining depth is search's way of specifying the importance of that
node, and the resources which it deserves. Depth == 0 means the node deserves no
resources and is not important - yet qsearch may then step in and decide to give
it more resources, not because it's important, but because it's messy.
I haven't been able to get rid of it, but I suspect the key issue is move
ordering - with qsearch your hash table moves are much better. In MTD (f) this
is really important, because better move ordering gives you better fail soft -
if you fail high with a bad move, there's a good chance you'll eventually need
to re-search.
It may be that qsearch vs SEE should be chosen according also to how important
the node is for future move ordering.
Vas
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.