Computer Chess Club Archives


Search

Terms

Messages

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

Author: Anthony Cozzie

Date: 08:53:17 04/02/04

Go up one level in this thread


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)
>
>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.

Doesn't messy -> important?

anthony

>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.