Author: Gerd Isenberg
Date: 02:02:39 03/05/06
Go up one level in this thread
On March 04, 2006 at 13:55:12, Dann Corbit wrote:
>On March 04, 2006 at 13:50:14, Dann Corbit wrote:
>
>>On March 04, 2006 at 13:47:50, Dann Corbit wrote:
>>
>>>On March 04, 2006 at 02:46:22, Gerd Isenberg wrote:
>>>
>>>>>OK. So you make an array of 128 function pointers then, and do this:
>>>>>
>>>>>status = method[hashval(BB)]();
>>>>
>>>>Yes, if you like, you can do either switch with a contiguous range as well.
>>>>But to get pure attacksets, there are no function pointers at all, but pointers
>>>>to bitboards.
>>>>
>>>>>
>>>>>PGO seems to take a lot of the sting out of missed branch predictions, but of
>>>>>course there will always be some.
>>>>
>>>>It would be interesting to see some pseudocode what your /* Do Stuff */ in the
>>>>cases does, to implement a kind of "ray-base" e.g. with the position you
>>>>mentioned recently. If you are interested in a1-h8 related properties of let say
>>>>square g7.
>>>>
>>>>[D]7k/3n2q1/5p2/8/6N1/2Q5/1B6/Q1K5 w - -
>>>
>>>There is probably a lot less magic in my stuff than you might imagine.
>>>
>>>First of all, I have direct attack bitmaps, shadow bitmaps, and half-pin bitmaps
>>>(I tried quarter-pin, but so far they seem to be too expensive for the payback,
>>>but half pin are clearly worthwhile). For this position, half pin is enough.
>>>Quarter pin positions are very rare.
>>>
>>>Anyway, the interesting guy is the pawn at f6. When I go to my switch, I will
>>>have precalcuated stuff against the full bitmap and also white and black, as
>>>well as piece.
That is all very interesting. I still have only a vague idea how you intend to
implement your occupied cases. How to index your precalculated stuff?
Cascading switches with subsets of occupied, like own-opposite pieces and/or
concrete piece types? I understand if you have that 128-state occupied switches,
you have all information where man reside on that ray. Also you are able to
distinguish occupied squares from both sides of the square in question.
So for instance one could do something like this, calling functions for each
occupied case, passing two lists of occupied squares for both directions, while
the occupied squares and number of occupied squares are compile time constants
for each case:
switch ( occupiedBB & mask[sq][sw_ne])
{
...
case A1_B2_C3_F6_H8: // from square g7
return getRayBase41_dia1(g7, {f6,c3,b2,a1}, {h8});
...
case A1_B2_C3_G7_H8: // from square f6
return getRayBase32_dia1(f6, {c3,b2,a1}, {g7,h8});
...
}
// 41 1111x1
SRayBase* getRayBase41_dia1(SqType sq, SqType four[], SqType one[])
{ // "switch" on the pieces on the board of sq and square lists
...
// look for pins/halfpins
if ( isOwnKing(one[0]) ) {
if ( isOppositeDiagonalSlider(four[0]) ) {
// sq is pinned
...
} else if ( ownPiece(four[0]) ) {
if ( isOppositeDiagonalSlider(four[1]) ) {
// board[sq] is "half" pinned
if ( isOppositeDiagonalSlider(four[2]) ) {
// board[sq] is "half" pinned by at least a double battery
if ( isOppositeDiagonalSlider(four[3]) ) {
// board[sq] is "half" pinned by a triple battery
} ...
} ...
} ...
} ...
} else if ( isOwnKing(four[0]) ) {
...
} ...
...
}
If those generated functions are inlined with compile time parameters, all
precomputed "knowledge" is inside generated code, rather than in indexed tables.
Is this the right track?
Thanks,
Gerd
>>>
>>>The upshot is that I have for every square on the board a list of attackers by
>>>type and by type of attack (direct, x-ray, half-pin). So let's consider the
>>>pawn. He has:
>>>
>>>white attackers black attackers(defenders)
>>>pawn direct(0) pawn direct(0) {no such thing as indirect for P}
>>>knight direct(1) knight direct(1) {no such thing as indirect for N}
>>>bishop direct(0) bishop direct(0)
>>>bishop x-ray(1) bishop x-ray(0)
>>>bishop half(0) bishop half(0)
>>>rook direct(0) rook direct(0)
>>>rook x-ray(0) rook x-ray(0)
>>>rook half(0) rook half(0)
>>>queen direct(1) queen direct(1)
>>>queen x-ray(0) queen x-ray(0)
>>>queen half(1) queen half(0)
>>
>>Forgot to list the king attacks (both 0).
>>I consider a pawn attack to be the strongest attack and a king attack is the
>>weakest.
>>
>>>In addition, we know that black is upside down on the pin, that the pinned piece
>>>is a queen and that the shadow pinned piece is a king (type of piece that is
>>>BEHIND the pinned piece is crucial and actually changes my pin type).
>>>
>>>My makemove actually updates these counts* (so movegen suffers a bit and will
>>>never compete with the fastest). As a side point, it makes a legal only move
>>>generator a snap.
>>>
>>>[*] The function pointers I was referring to are the things that:
>>>1. Remove the influence of the piece from the board (imagine picking it up)
>>>2. Add the new influence of the piece to the board (imagine putting it down)
>>>
>>>Besides helping out the evaluation a great deal, it is also stupendously helpful
>>>for move ordering. You can tell at a glance from the information presented that
>>>the queen's pawn capture is winning (makemove alone does not know it, but
>>>evaluation does without search).
>
>After the makemove, every square on the board is tagged as white kingsafe, white
>queensafe, white rooksafe ... black queensafe, black kingsafe.
>
>Now, these safety evaluations are only approximate (sort of a free SEE helper)
>but putting a king on a square that is not kingsafe for the color will not be
>attempted (illegal move) and putting a queen on a square that is not queensafe
>will be the last move searched.
This page took 0.01 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.