Author: Gerd Isenberg
Date: 09:52:07 09/17/04
Go up one level in this thread
On September 17, 2004 at 10:57:24, Uri Blass wrote:
>On September 17, 2004 at 03:59:30, Gerd Isenberg wrote:
>
>>On September 16, 2004 at 21:20:50, Uri Blass wrote:
>>
>>>What is faster doing a loop on the 1's of a bitboard or doing a loop on array of
>>>integers
>>
>>Guessing you want square indicies, clearly traversing an array of integer is
>>faster, because you don't need the rather expensive bitscans or log2(singlebit).
>
>I thought that array 64*8 is relatively big array and looking at the
>right place in the array may be expensive(this is one of the reason that I
>considered to do it for knights).
If you use packed byte-strings, it is about same space as bitboards.
64 bitboards for each knight square or 64 times 8 or 10(if + terminator) byte
strings with appropriate target squares.
If your string size is one or two greater you may but a terminator (64..255)
behind to save the additional < 8 condition.
Not that i am against bitboards ;-)
I simply don't like flipping between both metrics too much.
But maybe a hybrid approach has some merits - at least didactical.
>
>I did not think to get rid of the knight list that is a cheap way to find knight
>squares and I also thought that maybe I can have cheaper way to find
>the squares that the knight can go.
>
>Another reason that I considered to have bitboards for knight attacks it for
>knights is that I think about marking checks in my move generator like smirf(I
>have ideas how to use the information but I am not sure if they can compensate
>for the cost).
The problem is if you mix square list and bitboard approach.
You may use knight bitboards as a boolean precondition to traverse the list,
looking for captures and/or checks. Or you may bitscan the the intersections and
tag the entries as done inside the list - i don't like that.
>
>I already have function to calculate if moves are check moves in the qsearch and
>the first thing that I do before generating moves is marking checking squares
>
>I have the following loop
>for (j=0;j<knightnumber[enemyking];j++)
> squareattackking[knightmove[enemyking][j]]=KNIGHT;
Ok, with bitboards it's one "and" to look for knight check target:
checkTargets = knightAttacks[knightSquare] & knightAttacks[enemyKingSquare];
One further "and" to look for captures and one "and" quite checks.
>
>I thought to save this calculation by having bitboard of knight attacks but the
>problem is that in that case using the bitboard seem to be more expensive.
>
>I think now that a better solution is simply to avoid this calculation in most
>cases and simply loop on the knight list that may be empty and only if I find
>some knight at distance 2 from the king to do that calculation.
>
>The question now is how to find if knight is at distance 2 from the king square.
Is there no 0x88 diff-trick to check whether two squares have knight-distance?
>
>It is possible to have 64*64 array for knight distances but I doubt if it is the
>best solution because I am afraid that 64*64 array is expensive.
Yes, but you can pack some distance, taxi-distance or other geomatrical
relationships, like UDR-values in it.
>
>In most cases it is possible to detect easily that 2 squares are not at knight
>distance 2 only by the file distance and the rank distance and I suspect that
>using small array first to detect it and using the big array only in rare
>cases(a1 b2) may be cheaper.
>
If you already have absDeltaFile and abdDeltaRank,
why not:
if (
( absDeltaFile == 1 && abdDeltaRank == 2 )
||
( absDeltaFile == 2 && abdDeltaRank == 1 )
)
// knight distance
>
>>
>>>
>>>I simply consider to change my knight move generator to bitboards
>>>
>>
>>Probably a bad idea to do it only for knights.
>>Do it for all pieces or not.
>
>I already have bitboards for pawn structure that include bitboard for pawns
>and I do not plan to change it but I have no bitboards for other pieces and I
>also do not loop on the bitboard of pawns to look at the piece list.
>
>I guess that it is a bad idea to get rid of the piece list for pawns because if
>finding the next 1 is slow finding the next 1 for many pawns is even slower
>and saving the time of incremental update of the pawn list is not worth it.
>
>Uri
No idea how you hybrid pawn bitboard pieceliest approach works ;-)
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.