Author: Robert Hyatt
Date: 07:03:21 05/30/98
Go up one level in this thread
On May 30, 1998 at 00:12:02, Roberto Waldteufel wrote: > > > > >On May 29, 1998 at 17:34:22, Stuart Cracraft wrote: > >>On May 28, 1998 at 18:42:10, Roberto Waldteufel wrote: >> >>> >>>My chess program currently has only a crude understanding of king >>>safety, but I would like to try to improve this. It is quite good at >>>finding a forced mate, especially if all of the moves by the mating side >>>are checks, but seems to lack the skill to build up sufficiently >>>aggressive positions to make full use of this ability. I know that most >>>programs measure king safety in some more or less complex way, but I am >>>not sure what is the best thing to measure in terms of information >>>usefulness per time spent. Maybe a very complex king safety function >>>with a hash table to cut down the overhead is the way to go, or pehaps a >>>fairly crude but fast scheme without hashing might be efective. At >>>present my program uses a count of attackers and defenders to guage king >>>safety, where I define (somewhat inaccurately) an attacker/defender to >>>be any piece or pawn that attacks a square adjacent to the king. Does >>>anyone have any better suggestions as to how to build into the >>>evaluation function the tendancy to move its pieces to the most >>>aggressive squares possible? >>> >>>Roberto >> >>Besides open lines near the king, "swiss-cheese" pawn structure, and >>enemy pieces nearby, I'd suggest simply square-control. Weight the >>squares nearest a) the center of the board b) the enemy's half of >>the board and c) the enemy king location in the order c>b>a. Then >>each attack of each side's pieces on all the squares it attacks >>is summed based on the square's control value. Combine 'em all up >>and subtrace white from black or enemy from friendly and add it to >>the total score for the position. >> >>This kind of thing, though slower, is far better than simple piece >>placement/location since that does not take into account mobility, >>only location. And square-control takes into account centrality, >>attack, and mobility all in one. >> >>--Stuart > > >Thanks for your reply. I have considered this type of approach in the >past, and rejected it because my attempts to overcome certain problems >inherant in the scheme all proved to be too costly in terms of speed. >The main difficulty I found were: > >1) The squares controlled by a particular piece may be of virtually no >value because of any of several chess specific reasons, eg the piece >would be lost if it moved to the square, viz a queen may cover a lot of >squares from a central location, but if these squares are all guarded by >pawns and minor pieces then the queen has low mobility in spite of the >large number of squares covered, > >2) The most important squares to cover may have nothing to do with the >enemy king, the centre or the enemy's side of the board. This is usually >the case when passed pawns are involved (not necessarily in the >endgame). The diversity of different types of positions makes it very >difficult to construct a general set of values for squares to control. > >3) The different pieces exercise differing amounts of control. The >degree of control exercised by a piece or pawn is inversely proportional >to the value of the controller, ie a pawn exercises more control than a >queen. This is easily handled, but all adds to the overhead. > >4) I use a bit-board datatbase of attacks from and to all the squares, >which is fine for generating moves quickly, but does not properly >reflect the control a piece is exerting, eg if White has doubled rooks >on h1 and h2 attacking a Black pawn on h7, the attack database will only >recognize the rook on h2 as attacking h7 (since the rook on h1 cannot >move to h7 in a single move. Similarly bishop and queen batteries are >not handled properly, nor bishop control through a pawn, eg Black Bishop >b7 and Black pawn on d5 implies Black controls e4 twice, but only one >attack (the pawn on d5) is reflected in the database. Thus a substantial >amount of processing would be required to properly identify the actual >control exercised by the long range pieces. I could change the structure >of the database to count all these anomalies, but then the time overhead >for incrementally updating the database starts to become excessive due >to the extra complexity of the consequences of making/unmaking a given >move. Also the move generation would then slow down, because each move >generated would need to be tested more thouroughly for legality (is that >bishop capturing throgh a pwn or a queen of its own colour?) > >I like the idea of a general positional score based on mobility, but I >think that to implemeny it properly would probably require a selective >search approach rather than brute force, but that's a different >ball-game altogether! > >Roberto I'm not a big believer in mobility, based on years of experimentation with it. It is not clear to me whether mobility is a *cause* of winning a game or a *result* of winning. You do *not* want to evaluate "result" terms, or else you'd see something like "in the last 10 games where Brett Favre was hurt in the 4th quarter of an NFL game, Green Bay *won*." We need to win this game badly, so you linemen don't block and let's get Brett hurt so we can win. Logic is wrong of course... one easy example in chess is moves like a4-a5 or h4-h5, which increase the mobility of the rook, but which also disrupt or weaken the pawn that moved,plus the squares that it helps defend... I think that you have to rely on search for some of this, and on evaluation for the parts that you can clearly evaluate...
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.