Author: Pauli Misikangas
Date: 01:52:01 03/17/99
Go up one level in this thread
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... I use a kind of SEE also for static evaluation to calculate attack values, board control, and number of safe squares into which pieces can move. Sounds terribly slow? Actually, it isn't because I have pre-calculated (approximative) SEE values into a big array. I use pointer-based data structure (no bitboards) in which all pieces have pointers to squares onto which they can move and vice versa. When updating these pointers (during every move) I also update counters in squares that tell how many pieces of each type threatens that square. From these counters I make a single integer (few bits per piece type) that I use as an index to the SEE value array. However, this gives only approximative SEE values, because it does not take into account that some pieces might not be able to move (e.g. causing a check to own king). Also, to keep the SEE array small, I don't distinquish piece types that have about the same value. So, in my shogi program, I handle lances and knights as a one type because they have roughly the same value, and same thing with silver & gold, and bishop & rook. Thus, pre-calculated SEE values won't tell me whether I'm going to lose a bit in material because exchanging a silver to a gold, but they tell me if I'm going to lose a knight for a nothing, and so on. Pauli Misikangas
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.