Author: Tim Foden
Date: 02:23:50 10/06/01
Go up one level in this thread
On October 06, 2001 at 00:14:08, Robert Hyatt wrote: >On October 05, 2001 at 21:06:06, Paul wrote: > >>On October 05, 2001 at 20:42:21, Robert Hyatt wrote: >> >>>On October 05, 2001 at 19:15:19, Paul wrote: >>> >>>>On October 05, 2001 at 14:59:28, Robert Hyatt wrote: >>>> >>>>>On October 05, 2001 at 12:33:06, José Carlos wrote: >>>>> >>>>>> Due to recent posts about SEE, I've decided to implement it. I have a doubt. >>>>>>In this position: >>>>>> >>>>>>[D]6rk/3n4/6p1/8/8/3B4/P2R4/7K w - - 0 1 >>>>>> >>>>>> white has only a capture: Bxg6. If I understood right, SEE looks only for >>>>>>captures in one square, so it will try: Bxg6 Rxg6 and I'm losing a bishop for a >>>>>>pawn. So SEE will tell me Bxg6 loses, and I'll discard a move that actually >>>>>>gives me a pawn for free. Is this correct? >>>>>> >>>>>> José C. >>>>> >>>>> >>>>>That is correct. But notice this is only "discarded" somewhere in the >>>>>q-search (in my case.) I _never_ throw moves out in the normal search. >>>>>This will be searched near the end, because it looks like it loses a >>>>>piece for a pawn. But it _will_ be searched. The q-search will be wrong. >>>>>But then it is possible that your RxN can't be played either because your >>>>>rook might be pinned. That gets too complicated for this kind of simple/static >>>>>analysis... >>>>> >>>>>The q-search is _full_ of errors, because it is by definition not exhaustive >>>>>at all. Which means it overlooks pins. forks, skewers, etc already. What's >>>>>one more small error tree in that forest? :) >>>> >>>>Bob, could you explain what you mean by 'it overlooks pins'? >>>> >>>>Groetjes, >>>>Paul >>> >>> >>>Sure... the typical SEE code (at least that implemented in Crafty, and what I >>>did in Cray Blitz) looks at one specific target square for exchanges. It >>>doesn't pay any attention to absolute or regular pins (ie if a piece is >>>pinned on my king by your rook, I can _still_ use that piece in the sequence >>>of captures. It is less accurate, but the errors in the q-search are so >>>large, this is "noise" basically. >>> >>>In the example given at the start of this thread, we have a discovered attack >>>that SEE misses as well. BxP, and when the opponent plays something takes >>>bishop, he has a piece hanging to the discovered attack exposed when we moved >>>the bishop to take the pawn. >>> >>>Other things include overloaded pieces. The point is that _all_ that is >>>considered is "which pieces bear on the target square, whether they are >>>pinned, overloaded, or anything else?" >> >>Ahh ... I read your statement above like this: A qsearch even without a SEE >>overlooks pins, etc. But that can't be, or can it? >> >>So a qsearch without a SEE seems to be a heck of a lot more accurate than one >>with? Reading what you say above, and thinking about it for the first time in my >>chess programming life, I don't understand it works at all ... yet everybody's >>using it! Hmmm ... :) >> >>Paul > > >OK... your first conclusion is right: "A q-search without SEE is more >accurate." But you have to add "it is also 2x-3x _slower_ because you will >look at so many ridiculous captures, you will search a ply less deep. > >That is the reason we are doing this. To cut the size of the tree by tossing >those lemon captures. This is why I wondered whether it would be possible to add enough intelligence the SEE to detect (most?) situations where it could be wrong. Or to put it another way... to understand when the situation is too complex. In these cases it could tell the q-search that it's value is suspect. Then the q-search could ignore the SEE in these situation, and would still be acurrate, but also still fast. I still need to think about this :) Cheers, Tim.
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.