Author: Robert Hyatt
Date: 10:02:54 06/20/98
Go up one level in this thread
On June 20, 1998 at 11:30:01, Stuart Cracraft wrote: > >> >>1. This shoule *not* be a compute-intensive task. If you aren't yet hashing >>your pawn structure scoring, you should, because whether a pawn is passed or not >>is a static piece of information that is independent of other pieces. If you >>hash this, you will find that you find over 99% of your pawn structure >>evaluations are not needed because after you compute them one time, you will not >>re-compute this again, just use the hashed value. >> > >While what you say is true about the 99%/1%, passed pawns that are >carefully calculated are not hashable. The reason is that a good calculation >of a hashed pawn includes who controls its queening square and >who controls the square directly ahead of it (facillitating its advance) >as well as other attacks along its path as well as blockading enemy pieces >on that path that would impede its progress. These extra items involve >calculations related to non-pawn pieces and therefore may be in >different positions where the passed pawn is on the same square. Hence, >unhashable. If you take the trivial case of just hashing the fact that it is >a passed pawn, then yes, that is hashable. But not the full case which >is what you really need. > But if you read his post *carefully* he was talking specifically about the case of *recognizing* passed pawns, not *evaluating* them. This is only dependent on the positions of enemy pawns, and the effective cost of this is always *zero* with hashing. What you do with that information later is another issue, but not the recognition phase. >>2. finding that a pawn is passed is trivial. You could easily add a 64 bit >>word that contains a 1 for each white pawn, and then do the same for black. If >>you update this after each move, asking "is a pawn on "SQ" passed" takes one >>64 bit operation, anding the opponent's pawns with a mask that shows where he >>must have pawns in order for your pawn on SQ to *not* be passed. > >I used to carry a 64-bit quantity called "passed" in my hash struct. I recorded >all the passed pawns for both sides in it. However, as my passed pawn >handling got more advanced and involved more issues surrounding control >of squares on the passed pawns path, I discarded the passed in my >hash struct and have to calculate the passed pawns on every positional >evaluation. Since the other piece's locations and attacks can change, >I couldn't think of an alternative. > >Anyway, I'm happy to say that my passed pawn handling is pretty good now. >I take the maximum case: a passed pawn that can definitely queen and >take fractions of that for all other cases based on how many detracting >factors are present (eg. enemy king not in square of pawn and enemy >has no pieces, control queening square, control squares on path, >control next square, blockading squares, etc.) All of these, if controlled >and blockaded by the enemy reduce my passed pawn's value substantially. >But if there are very few or none of these present, the bonus goes way up >and can amount to multiple pawns worth of positional bonus. > >--Stuart
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.