Author: Vasik Rajlich
Date: 03:14:03 04/03/04
Go up one level in this thread
On April 02, 2004 at 11:53:17, Anthony Cozzie 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)
>>
>>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
Actually this is still an open issue for me.
Yes, messy -> important.
However, messy shouldn't be the only thing which is important. Imagine, you
search 10 ply, there are many alternatives along the way, and it just so happens
that some tactics are breaking out at the leaf. If you have a big qsearch, you
will give them disproportionate resources. You will also give resources to
tactics, at the cost of positional moves.
Actually, remaining depth is also not a great measure of importance. Not all
positions with the same depth have the same importance. At the very least,
importance should be two-sided - it may be much more important that a position
holds together for one side than for the other. (ie one side can be forced into
that position, the other side has alternatives)
I have attempted to measure this (I call it "commitment") using fail-soft
results from null-move searches. It was a failure the first time, but now that
my fail-soft is better, maybe it's time to try again.
Vas
>
>>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.