Author: rasjid chan
Date: 00:36:04 05/02/04
Go up one level in this thread
On May 01, 2004 at 18:26:27, Russell Reagan wrote: >On April 30, 2004 at 19:27:56, Steve Maughan wrote: > >>Russell, >> >>>With rotated bitboards you can get mobility information from a lookup table >>>(the same way you get attacks from a lookup table). >> >>Thats a good point. But AFAIK Ruffian and Patriot are not rotated bitboard >>engines. So the puzzle continues... >> >>Steve > >I think I recall reading about some people using bitrays (for lack of a better >term). For instance, instead of a 64-bit bitboard, you might be able to use >8-bit values (bitrays) to represent ranks/files/diagonals, and enter those into >a lookup table. It may be a little cheaper (especially on 32-bit hardware) to >incrementally update a set of bitrays as opposed to full blown rotated >bitboards. > >Even if you wanted to use the mobility tables that require full rotated >bitboards, it wouldn't be difficult to incrementally update rotated bitboards >using an 0x88 based board, and then you could have the best of both worlds. >Computing the neccessary rotated bitboards on the fly may even be quicker than >looping all over the board to compute mobility. > >I am not completely sure what Rasjid meant, but his post got me thinking. When >using an 0x88 board (or anytime you maintain a piece list), it is sometimes >quicker to loop through the piece list instead of looping over the board. For >instance, when generating captures, it may be quicker to loop over the >opponent's piece list and see if you can capture any of them instead of looping >over all the attacked squares on the board (depending upon the phase of the >game). You could calculate mobility by looping over the board, or looping over >the piece lists. I think looping over the piece lists may be faster in this >case. If you use 0x88, you can use the unique square relationship lookup table >trick to avoid any scanning of the board, I think. I'll have to think about this >one some more. > >My last guess is that you might be able to update mobility tables in the same >way that people update attack tables incrementally. If you can get mobility the >same way you can get attacks when using rotated bitboards, then maybe you can >get mobility the same way you get attacks using 0x88? I must first apologize that I don't have the slightest hint about precalculated mobility. Only a slight idea of using bitrays(char) as index to tables. I think someone did post almost the same topic in the past but there was no follow-up. The reason could be there may not be such a thing or even if it could be done, may not be in a usefull form. Like nullmove, ETC,etc they are reasonable and therefore have easy acceptance. When we say simply "precalculated" we normally mean the accepted usage. int knight_attack[64][64] is the simplest representation, but true attack in this way cannot be done for the sliding pieces and I don't think any say often "precalculated bishop attack tables". I think Steve simply meant this and about how, with the blocks to sliding paths, could there be precalculated mobility in the expected interpreation. So this could be why few join this post. I am not sure your bitrays meant "simple lookup" that is not hindered by other blocking pieces... the moment's reflection now - on the fly/ incrementally update the bitrays representing the free paths... I'm not sure, but sure seems not yet popular. I was raking my head just as Steve when it was (first) mentioned. Rasjid
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.