Author: Gerd Isenberg
Date: 15:30:17 03/25/04
Go up one level in this thread
On March 25, 2004 at 08:36:18, Vasik Rajlich wrote:
>On March 24, 2004 at 18:59:02, Gerd Isenberg wrote:
>
>>Some minor changes because inOne == inThree is not general enough.
>>Better to look for no further growing:
>>if ( (inThree & ~(fromBB|inOne|inTwo)) == 0 && ...
>>
>>
>>// fixed is subset of tabu (may be equal), the set of all own blocked
>>// and backward pawns.
>>// tabu may contain enemy pawn attacks which don't terminate the attack ray
>>
>>BitBoard getTrappedBishopSquares(BitBoard fixed, BitBoard tabu, int n)
>>{
>> BitBoard trappedBishopSquares = 0;
>> BitBoard potb = ~tabu;
>> while ( potb ) {
>> BitBoard fromBB = potb & -potb;
>> BitBoard inOne = fillBishopAttacks(fromBB, ~fixed) & ~tabu;
>> BitBoard inTwo = fillBishopAttacks(inOne, ~fixed) & ~tabu;
>> BitBoard inThree = fillBishopAttacks(inTwo, ~fixed) & ~tabu;
>> // tag all reachable in up to three moves as done
>> potb &= ~(fromBB|inOne|inTwo|inThree);
>> inThree &= ~(fromBB|inOne|inTwo); // growing?
>> if ( inThree == 0 && popCount(inOne|inTwo) < n )
>> trappedBishopSquares |= (fromBB|inOne|inTwo);
>> }
>> return trappedBishopSquares;
>>}
>>
>>popCount > n considers the whole fill area reachable in two moves.
>
>Gerd,
>
>thanks, I'll try it in Rybka.
I'll too in IsiChessXMM ;-)
As Sune already mentioned,
fillBishopOccluded(fromBB, ~tabu)
is a bit faster (one 64-bit shift,two ands less for each of four directions)
than
fillBishopAttacks(fromBB, ~tabu) & ~tabu;
But the latter has the option, to distinguish between mechanical own fixed pawns
(or defended enemy pawns) and additional enemy pawn controls ...
fillBishopAttacks(fromBB, ~fixed) & ~tabu;
Where fixed is subset of taboo.
Sorry Anthony, i often mix english and german indentifiers ;-)
Sune's approach is faster and loopless.
I guess it's accurate enough and may even applied with
fillBishopAttacks(fromBB, ~fixed) & ~tabu;
where terminating fixed is finally filled, and has to be masked out by tabu.
>
>As you mentioned earlier, it would be very interesting to play with "fixed", ie
>absolutely fixed (for totally trapped bishops), semi-fixed (more common, for bad
>bishop scoring), etc. It's not so easy to come up with a good algorithm for
>semi-blocked pawns, even if the hash table gives you room to waste some cycles.
>
Yes, difficult, some brainstrorming on the fly...
The base of pawn bitboard pattern stuff are the stopp squares and disjoint and
combined left/right attack squares and fill up/down all white/black pawns and
disjoint and combined left/right attacks. Even left/right fill of both pawns, to
get luv/lee pattern e.g. for rook endings is interesting.
All kinds of "Kmoch-like" pawn patterns are easily to detect in some passes with
pure bitwise operations.
In the first pass one may detect open pawns, passers, candidates, isolanis,
levers (pawns attacked by pawns), pawns not attackable, pawns not defended,
pawns not defendable, duos, simple rams, double and triple pawns, pawns with
weak stopp squares, (duo) pawns with lever stopp squares ...
In a second pass those patterns may be combined.
Eg. for several degrees of backwardness of none lever, from very backward to
advanced backward candidates, and for the "fixed"-purpose e.g.:
Backward and Rams
Pawns on the 2. and 3. rank with weak stopp square on the own side of the board
(no duo support and empty stopp controlled by enemy pawn) and not defended, even
if they are isolated or not open (getarnter Hinker).
One may even try very weak stopp squares, controlled by two enemy pawns.
Rams are simple Rams (stopps occupied by enemy pawn) but no lever or duo.
Now we have a first idea of "none" movable pawns and their complement set of
"movable" pawns so far (we didn't consider double and triple pawns yet).
All "movable" pawns blocked mechanically by own "none movable" became exclusive
member of the latter the "none movable". That is done at least two times to get
triple pawns too.
One up/down-occluded fill (propagator all pawns and dominated by enemy attacks)
of "movable" sets to see, whether it is possible to build a safe duo lever.
And to get a set of "semi movable" pawns, e.g. pawns became backward or rammed
after a push.
So finally we can define the "fixed"-set by all rams, where no neighboured
"movable" pawn may force a duo lever, united with the (very) backward pawns. And
as Sune suggested, as a kind of mechanical barrier too, defended enemy pawns,
but no levers.
Due to piece interactions i thought about throwing out pawn hashing completely
(in the next amd64-version of my program), but hashing several expensive to
compute bitboards as a kind of boolean piece square table probably makes sense.
One or two KByte pawn hash entries? Why not...
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.