Computer Chess Club Archives




Subject: Re: hanging pieces in rebel

Author: Uri Blass

Date: 03:44:54 01/16/04

Go up one level in this thread

On January 16, 2004 at 05:55:48, Tord Romstad wrote:

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

Do you calculate things like number of pawn attackers,knight attackers,rook
attackers including indirect attacks when the rook support another rook
incrementally after every move?

Do you have this in a small table for the 64 squares of the board?


This page took 0.01 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.