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.