# Computer Chess Club Archives

## Messages

### Subject: Re: Zero-width Window Null Move Search

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
>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

```