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 >>knight/bishop >>+------+------+------+------+------+------+------+------+ >>| 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 >>movelist. >>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. > >Tord 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? Uri
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.