Computer Chess Club Archives




Subject: Re: hanging pieces in rebel

Author: Tord Romstad

Date: 02:55:48 01/16/04

Go up one level in this thread

On January 15, 2004 at 14:49:21, Bernward Klocke wrote:

>I recently read Ed Schroeder's comments on move ordering in rebel. What I find
>puzzeling is the way it detects hanging pieces.
>Ed presents the following data structure for square evaluation:
>| BIT0 | BIT1 | BIT2 | BIT3 | BIT4 | BIT5 | BIT6 | BIT7 |
>|      Number of     | PAWN |KNIGHT| ROOK | QUEEN| KING |
>|      ATTACKERS     |      |BISHOP|      |      |      |
>After all white pieces are done square F3 from WB looks as follows:
>+------+------+------+------+------+------+------+------+  B0-B2 : 2 attackers
>| BIT0 | BIT1 | BIT2 | BIT3 | BIT4 | BIT5 | BIT6 | BIT7 |
>+------+------+------+------+------+------+------+------+  B3    : white pawn
>|      Number of     | PAWN |KNIGHT| ROOK | QUEEN| KING |
>|      ATTACKERS     |      |BISHOP|      |      |      |  B4    : white
>|  0   |   1  |  0   |  1   |  1   |  0   |  0   |  0   |
>So evaluation is done for each square for black and for white. His example show
>the square f3 for white attacked by a pawn from f3 and a knight from g1.
>This example is clear but I think gets ambiguous when three pieces attack a
>square and two of them are of the same type eg. two rooks and a knight. How can
>one see that it's not two knights and one rook.

You can't.  In situations like this, where the total number of attackers
is bigger than the number of piece types attacking the square, I always
assume that there are more than one of the least valuable piece type
among the attacker.  In your example, which in decimal notation gives
the number 51, I assume that the square is attacked by one rook and
two minor pieces.

Doing like this, of course, means that you occasionally will get wrong
results.  But the cases where it could go wrong are easily identified.
At places in your search or eval where you absolutely need a more precise
estimate of the expected material gain of a capture, you first check
whether one of the attack vectors involved contain a bigger number of total
attackers than number of piece types.  In these cases, you can revert to
a slower and more accurate SEE function.  You'll probably find that it
happens rarely enough that the slowdown is hardly noticable.

>And the other thing is only going through the movelist isn't the whole story.
>What if doubled rooks are the attackers? Only the first one will appear in the
>Does anybody know how this is solved. What did I miss?

I don't quite understand the question, I'm afraid.  Could you please try
to reformulate it?  How do movelists enter the picture?

>Otherwise the lookup from a precalculated table of STATUS values seems elegant.

I thought so too until recently, and used to have similar precalculated
tables.  Later I have found that the idea isn't that great.  It is not very
economical to have such huge lookup tables where most of the entries are
never used.

Instead of using table lookups, I now calculate the values on the fly
from the attack vectors.  The results of the calculations are stored in a
tiny hash table (2 kB).  Even without this hash table, calculating on the
fly was only marginally slower than using a lookup table.  After adding
the hash table, calculating on the fly is as fast or in some positions very
slightly faster than using a lookup table.


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.