Author: Dann Corbit
Date: 10:17:39 04/08/04
Go up one level in this thread
On April 08, 2004 at 06:30:13, Gerd Isenberg wrote:
>On April 07, 2004 at 18:16:47, Dann Corbit wrote:
>
><snip>
>>>>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.
>
>Thanks, i guess i have it now. Non capture moves are fine, i thought about
>similar with rotated lookup with 6-inner occupied states.
>
>So you have something like this for this e-file with and rook on e4:
>
>// get the full occupied state from the 90 defree rotated occupied board
>state = getOccupiedStateOnFile(File(e4));
>state = packStateByHidingSourceSquare(state, Rank(e4));
>square = e4;
>
>SomeStruct*
>ptr = topDownLookupArray[state][square];
>
>ptr->quiteMoves => {e4e3, e4e5, e4e6, NULL}; // max 7
>ptr->attackedOccupied => {e2, e7}; // max 2
>ptr->xRayAttacks => {e8, -1}; // max 2
>ptr->potPins => {e7, -1}; // max 2
>
>The idea is similar to rotated attack lookup, but you have already all targets
>squares converted to lists of square metrics instead of bitmaps, so no target
>bitscan is required.
>
>For capture generation you have to check all target squares.
>Detecting pins or remove checker requiers additional ifs.
>
>It is fine, but what i don't like so much is an IMHO too early serialization
>from bitboard metrics to square metrics, looking further on for single square
>properties, e.g. whether targets are capture targets, checking targets, or
>whether move targets are safe...
>
>Anyway, an interesting approach.
>
>Cheers,
>Gerd
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.