Author: Dann Corbit
Date: 10:19:21 04/08/04
Go up one level in this thread
On April 08, 2004 at 13:17:39, Dann Corbit wrote:
>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.
Not sure what happened with my previous attempt at reply. I clicked the follow
up button and it went straight to that "go to your message" "go to the board"
thing without allowing me to edit anything.
Anyway, you pretty much understand it now.
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.