Author: Dann Corbit
Date: 15:16:47 04/07/04
Go up one level in this thread
On April 07, 2004 at 17:15:29, Gerd Isenberg wrote:
>On April 07, 2004 at 15:05:27, Dann Corbit wrote:
>
>>On April 07, 2004 at 08:48:41, Gerd Isenberg wrote:
>>
>>>On April 07, 2004 at 06:56:35, Tord Romstad wrote:
>>>
>>>>On April 07, 2004 at 05:06:13, Gerd Isenberg wrote:
>>>>
>>>>>But caching/precalculation of rotated lookup that way only pays off, if you
>>>>>really need it very, very oftern per node for a lot of squares. And most of the
>>>>>time you really dont't need attacks from all squares...
>>>>
>>>>I apologize for asking a stupid newbie question (I started experimenting
>>>>with bitboards less than a week ago): How can you avoid computing all
>>>>attacks from all squares when evaluating a position?
>>>
>>>
>>>Hi Tord,
>>>
>>>there are no stupid questions ;-)
>>>
>>>You need only to consider those squares occupied by appropriate pieces. Pawn
>>>attacks setwise by some shifting with masking board wraps. Sliding pieces by
>>>bitscan and rotated lookups or setwise by Kogge Stone fill. Knights and Kings by
>>>bitscan and lookup or setwise by some appropriate fill routine...
>>>
>>>In crafty like rotated bitboard approaches you will find two kinds of attack
>>>getters, one to get (rook/bishop) attacks from a square (the rotated lookups)
>>>and another kind like getAttackedBy(int sq) to get a set of all pieces attacking
>>>this square:
>>>
>>>BitBoard getAttackedBy(int sq)
>>>{
>>> return ( getRookAttackesFrom(sq) & (queens|rooks) )
>>> | ( getBishopAttacksFrom(sq) & (queens|rooks) )
>>> | ( getKnightAttacksFrom(sq) & knights )
>>> | ( getKingAttacksFrom(sq) & kings )
>>> | ( getWPawnAttacksFrom(sq) & blackPawns )
>>> | ( getBPawnAttacksFrom(sq) & whitePawns );
>>>}
>>>
>>>If you need this getAttackedBy(int sq) often for a lot of squares, it may become
>>>ineffiecient. Therefore if this is really the case it may be faster to compute
>>>all attacks from all white/black pieces (what you have to do anyway for eval and
>>>movegen), and to compute some taboo sets based on that piece attack sets with
>>>simple bitwise operations...
>>>
>>>But most often getAttackedBy(int sq) is used only for surrounding king squares
>>>and some other critical squares e.g. to compute some SEE-values, but not for all
>>>64 squares per se.
>>>
>>>Depending on your program design, if you have lazy eval, legale or pseudo legal
>>>move generation etc., you simply don't need that information at all for a lot of
>>>(leaf)nodes.
>>
>>Another way to do it is to carry the attack bitmaps for each piece (also summed
>>together as white attacks, black attacks, (and more subdivisions if you want
>>them like piece attacks and pawn attacks).
>
>Yes, i guess that's what i actually do, very heavily.
>Piece kind wise, direction wise, for each color, considering pins and xray
>attacks and defends to finally get several taboo sets and pieces hanging or en
>prise.
>
>A lot of unconditonal stuff, or, and, nand, SIMD-instructions...
>
>>
>>Your move generator can return the attacks given the board and the position in a
>>lookup if you have precomputed the 127 different states for any segment (the bit
>>for the position the attacking piece occupies can be eliminated).
>
>Sorry Dann, i don't get that.
>May you post some (pseudo) code to explain your idea?
>Do you mean a kind of rotated lookup to get disjoint direction attacks?
For now, we consider only the column, but the row works the same (and also
diagonals for bishops). Consider the rook in this position:
[d]1k2b3/4p3/8/8/4R3/8/4n3/1K6 w - -
He attacks the pawn and the knight and he x-rays the bishop.
To extract his attacks, we need an and with the 8 bits for the e-file.
Now, represent it as a byte. We can shift out the bit that the rook sits on,
because he neither attacks nor defends it. When calculating his attacks it is
irrelevant and would make the tables twice as big.
we end up with 0100011 (numbering from bottom to top, but do it however you
like)
For this bit pattern with a rook on E4, there are always exactly two pieces
attacked (or defended if they are his color): E2 and E7. If those pieces are
enemy pieces (in this case they are) then those are captures. E3, E5, E6 are
non-captures. And E8 is x-rayed (useful both if it is white and if it is black
because if it is white then you can analyze for support and if black for attack.
Especially important if E8 is a big piece like a rook, queen or king.
As you can see, knowing the bits where white chessmen set, the bits where black
chessmen sit and where the slider you want to generate moves for is all you need
to know.
All of the attacks, non-attack moves, and x-rays/pins can be precalculated and
simply returned.
It seems such an obvious idea I imagine lots of people do it.
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.