Author: Vasik Rajlich
Date: 03:24:17 04/03/04
Go up one level in this thread
On April 02, 2004 at 05:40:53, Tord Romstad wrote:
>On April 02, 2004 at 04:34:45, Vasik Rajlich wrote:
>
>>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)
>
>I do in some cases, but only when a fail high or fail low is almost certain.
>My evaluation function does not only return a score, but also locates hanging
>pieces for both sides. If the static eval is not high enough to cause an
>immediate fail high, but the opponent has a hanging piece of sufficiently
>high value that the capture of it is likely to bring the score *really far*
>above beta, and the side to move has no hanging pieces, I return a fail high
>score. Similarly, if the static eval + biggest hanging piece for the opponent
>is very far below beta, I sometimes return a fail low score without any
>search.
>
>In both cases, I use huge safety margins. I am not even close to eliminating
>the qsearch completely.
>
>Tord
Aha, thanks. With your huge eval scores, I suppose it makes extra sense to
evaluate the actual positions in the q-search.
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.