Author: Dann Corbit
Date: 13:34:36 03/06/06
Go up one level in this thread
On March 05, 2006 at 05:02:39, Gerd Isenberg wrote:
>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?
It's probably better than my idea. I just call the same function with different
parameters, with masks that have been modified by previous calls.
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.