Author: Tim Foden
Date: 14:41:14 07/14/03
Go up one level in this thread
On July 14, 2003 at 17:15:50, Bas Hamstra wrote: >Hi Gerd, > >A while ago, in Leiden, Frans mentioned you had a trick to reduce the rotated bb >lookup tables by a factor 2, without further disadvantages. It had something to >do with the edges of the board, some "ray-states" you can ignore. I didn't >understand his short explanation back then. Could you explain? > >Best regards, >Bas. I'll give it a try. to work out the possible horizontal squares a rook can go to, we need a bitmap of the row on the board that the rook is on. Say: 01100101, with the rook in file F. For the lookup you have an array like this: UINT64 horzBitmap[256][8]; and you get the bitmap for the potential rook moves... UINT64 rookHorzBitmap = horzBitmap[01100101b][6] You then restrict the moves that could be made by and-ing with the inverse of the pieces board of your own colour (as the rook can't take it's own pieces). This is fine. But if you think about it carefully, you realise that the bits at either end of the pattern, 01100101b, make no difference to the value that would be stored in the lookup table. I.E. the 0------1 bits in the pattern we are using as an example. Whatever their values are, the pattern we would get for the rook's moves would be the same... so we don't need to use them to perform the lookup. We can thus use an array... UINT64 horzBitmap[64][8]; and do the lookup like this... UINT64 rookHorzBitmap = horzBitmap[(01100101b >> 1) & 63][6]; As we have dropped 2 bits, we only use a quarter of the storage, so in general this is 128KB instead of 512KB for the lookup tables. Hope this helps! Tim.
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.