Author: Sune Fischer
Date: 01:53:26 05/28/02
Go up one level in this thread
On May 27, 2002 at 18:00:25, Vincent Diepeveen wrote: > >May i refer to the proof then why it is so much slower for DIEP, >because i need that information into my evaluation everywhere and >in crafty you need to combine all the bitboards in order to get >the info out. For example to get the number of attackers which i >use a lot, you need to perform all kind of slow adds, which i have >already incremental available with a single AND to the array. > >The reason for this is that you have only 1 bit of information i >can use in each bitboard. Whereas i have the info already combined into >an array which gets incremental updated for each square! > >So i am NOT off the mark. It is the 'little information a square' >versus 'all information a square' lemma. A classical difference >between bitboards and 'gnuchess 4.0' representation, whatever name >you want to give it. Mailbox or 0x88 or whatever. > >Using incremental datastructure i do: > attackers = (a1&15); Does this mean you have a table[64] where the first 4 bits in each element tells you the number of attackers of that square? I don't see how you can generate that as part of the ordinary move generation. It looks like special knowledge you incrementally update, Crafty could implement such a table no problem, has not got anything to do with move generation as far as I can tell. I thought the idea was to make a larger attack table, an "int attackers[64]" where each bit-layer represented a piece, so that attackers[d4] would give you the bits: 110011010.... meaning pieces one and two and five and six and eight are attacking the square d4. This can be used in move gen of course, but you don't get *the number of attackers* by simply &15 (you need to popcount or table lookup), so I guess I don't know how you do it or what it is you suggest is better. Any special knowledge you want for eval is easy to add incrementally, I guess the cool thing would be to reuse it for move gen, sort of two birds one stone principle. Bitboards does this to a large degree, a lot of the information can be reused for eval. It doesn't mean you can't add more to it, it just won't be part of the move gen process. >Bitboard equivalent is something primitive such as: > attackers = 0; > for pieces = 0 to 16 // all pieces > if( !thispiece && bitboard[piece]&squaremask ) > attackers++; Well the pawns are on a seperate bitboard, left and right attacks would only give you one bit even if both attacks, so is the knights on just one bitboard and the queens and rooks. This particular information is not easy to generate in Crafty, I guess. -S. >Of course i realize you can do it without branches by adding >some more instructions. But we talk about 15 bitboards you need >to combine or so. Not very nice thing to do! > >Your response was: "i don't need the number of attackers". > >I give this example, but there are many other things with regards >to evaluation i would love to show, but i dare not show out of paranoia >that others might consider using it in their evaluation, where i >didn't found an easy solution for with bitboards.
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.