Author: Chuck
Date: 10:26:14 06/17/99
Go up one level in this thread
I agree in with KarinsDad's approach to this as probably best in the long-term, to really handle this correctly you need to know whether the backward state is a potential problem. However, if you want to just implement it now, you could simply create an array of 8 int's and store the rank on which each pawn resides. Then for each element, you check the adjacent array elements to see if the rank value is higher. If it is in both cases, then you have a backward pawn, and from there you could investigate the amount of actual "backwardness". In particular though, I think the idea of hashing the pawn structures is one of the best. Chuck On June 17, 1999 at 12:32:56, KarinsDad wrote: >On June 17, 1999 at 10:43:01, James Robertson wrote: > >[snip] >>> >>>Recommendation #1: Calculate square control for each square. This will also help >>>you in other portions of your evaluation such as king safety. >> >>I might, although this will be expensive.... > >If you have bitboards, this is relatively cheap (nothing is free) and you gain a >lot of other evaluation benefits, assuming that you want to do a detailed >evaluation as opposed to a simple/fast evaluation. > >This will take a little time but a lot of space. My PieceAttack structure is 256 >bytes (64 squares x 32 pieces). I often calculate it based off of the >PieceAttack structure of it's parent and the move made, so it is not real slow >(but again, nothing is free). The delta calculation involves adding in any >additional squares due to long range pieces attacking the source square, >removing squares due to the piece moving, removing squares due to a piece being >captured (if necessary), removing squares due to long range pieces attacking the >destination square (if no piece was captured), and adding in squares due to the >piece moving to the destination squares. I do all of this with bitboards. There >is also a little extra there for promotions and en passant (i.e. ep has 3 >squares involved, not 2). > >So, yes, there is work here, but the main downside is that I need another 256 >bytes per position (although I often re-use these structures). On the other >hand, it has other bonuses such as backwards pawns, king safety, kingside >attack, queenside attack, control of the center, space; most any generic set of >ideas that you are concerned about in your evaluation can be handled via square >control. I cannot recommend it strongly enough if you are concerned with a >detailed evaluation. > >And, in fact, I even have an xraying PieceAttack structure (another 256 bytes) >to handle batteries. However, I calculate this on the fly each time from the >normal PieceAttack structure, so I do not save it (from the parent for example). > >> >>> >>>Recommendation #2: With square control, you do not need to calculate whether >>>there is a protecting pawn on the adjacent file. Either the one (or two) squares >>>in front of the pawn you are checking are controlled by white or by black. >>> >>>Recommendation #3: Set up a pawn structure hash table. Since pawns rarely move >>>in the game (and in the search <40% on average), it is probably better to >>>calculate pawn advantages and deficiencies once per given pawn structure as >>>opposed to calculating it every time in your evaluation. >> >>I already have pawn hashing, but it just seems creepy to have so many arrays to >>find out one simple little thing like backward pawns. > >Well, the pawn hashing may not always help out with backwards pawns. Why? >Because if you have a situation of black pawns on d7 and e5 and no black c pawn >with a white pawn on e4, then the d pawn is backwards. If the white pawn does >not exist on e4 (or c4 for example), then the black pawn is only backwards if >white controls the d5 square with a piece. If black controls the d5 square, then >you cannot really consider the pawn to be backwards (yet). > >Since square control can be a factor with no pawns, the pawn hashing structure >does not guarantee information on backwards pawns. It just helps in a lot of >other things like doubled pawns, open files, and isolated pawns. > >Now, you could just use a generic pawn hash table to say, "Hey, I got a black >pawn on d7 and e5 with no black c pawn, so by default I will say that it is >slightly backwards.". However, this does not make a lot of sense since the pawn >could be perfectly fine and can be pushed at any time (since the square(s) in >front of it are not controlled by the opposing side), so adding in a small >evaluation penalty to the pawn hash table seems incorrect. You could, though, >add some information into your pawn hashing to indicate which pawn is backwards >and have your main evaluation routine determine the bonus/penalty based on who >controls the square(s) in front of that pawn. > >KarinsDad :)
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.