Author: Jonathan Goldstein
Date: 10:13:02 03/17/99
Go up one level in this thread
On March 17, 1999 at 08:50:20, Peter Kasinski wrote: >On March 17, 1999 at 04:31:02, Cristian Zaslo wrote: > >>On March 16, 1999 at 22:55:09, Robert Hyatt wrote: >> >>>On March 16, 1999 at 18:36:08, Peter Kasinski wrote: >>> >>>>On March 16, 1999 at 16:58:09, Robert Hyatt wrote: >>>> >>>>>On March 16, 1999 at 12:04:51, Dann Corbit wrote: >>>>> >>>>>>On March 16, 1999 at 02:50:20, Cristian Zaslo wrote: >>>>>> >>>>>>>Hi everybody ! >>>>>>>Will anyone be so kind and briefly explain me what sort of >>>>>>>advantages would (not) have a chess programmer to implement >>>>>>>a SEE in his code. >>>>>>>Much obliged to you, >>>>>>>Cristian >>>>>>Er.... >>>>>>What's a SEE? I've been programming 33 years and I have never heard of one. >>>>> >>>>> >>>>>Stands for "Static Exchange Evaluator". It is a procedure that analyzes all >>>>>captures on a single square and returns a value indicating who comes out >>>>>ahead. >>>>> >>>> >>>>>It can be used to order captures so that you try QxP where the pawn is free, >>>>>before you try QxR where the R is defended. It can also be used to discard >>>>>some captures in the q-search such as QxR where the R is defended and you are >>>>>guaranteed to lose material. >>>>> >>>>>Used correctly it is possible to cut the size of the tree being searched by >>>>>50% or more. >>>> >>>> >>>>Bob, I looked at Swap() in Crafty where this is implemented. >>>>Not using bitmaps I don't have a cheap way to determine what pieces attack a >>>>given square. Would it still be profitable for me to compute these attacks in >>>>order to use SEE? >>>> >>>>thank you, >>>>PK >>> >>>There are far more non-bitboard programs than bitboard programs. And SEE >>>works just fine. It will cost a little more probably, because there are >>>loops that don't exist in bitmaps, but I had such a function in Cray Blitz. >>> >>>The idea is to take the target square, and first find out what pawns are >>>attacking the square, then bishops, knights, rooks, queens and finally >>>kings. Then the 'minimax' code at the bottom of my Swap() can be taken >>>directly... >> >>So, am I right saying that SEE may be used to improve move ordering in the >>Q-Search but it cannot be used as a single way to determine whether a leaf >>node is or not a quiet one ? >> >>Thanks! > > > >But it leads to discarding some captures altogether. >To me this means that SEE is used to: > >a) improve move ordering >b) determine when you don't care if a leaf node is quiet or not because you >discard the variation as futile. > >yes? > >PK a) seems reasonable. But as far as b) goes, it is hard to discard a capture based on static evaluation because (as somebody mentioned) a key capture in the sequence could be a self-check (or self discovered queen attack ...). If you account for such discovered attacks, you start to spend more time and you stil havent considered tactical aspects like by moving one of the capturing pieces, what if you have cleared a path for a piece to fork (or checkmate!). For me, writing the quiescense search is the hardest part of writing a chess program, I tried using a SEE, but it failed miserably.
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.