Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Help, please: best description of a modern chess program

Author: Tord Romstad

Date: 23:11:48 04/01/04

Go up one level in this thread


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



This page took 0.01 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.