Author: James Robertson
Date: 06:51:01 10/29/98
Go up one level in this thread
On October 28, 1998 at 15:39:00, Peter Fendrich wrote: >On October 28, 1998 at 13:57:24, Roberto Waldteufel wrote: > >>Hi Peter, >> >>I also test for king in check before recursing. I don't think it adds much >>overhead because of the data structure of the program. I maintain attack from >>and attack to tables for each square (2 arrays of 64 bitboards). I also maintain >>a two-element array king() that tells me the square of each side's king. So my >>king in check test code is as simple as : >> >>generate move >>make move >> >>if atktobits(king(side)) and allmenloc(opnt))=0 then >> >> swap sides >> v=-search(-beta,-alpha,depth-1) >> swap sides >> >>end if >> >>unmake move > >Yeah, I know! I used the same kind of bitboards before, inspired by Chess 4.5... >After reading Bob's posts about rotated bitmaps I converted to that and got >some >increased performance but I had to change two things: >1) The complicated swapoff I used, wasn't doable anymore. I used >2) The KingInCheck became more expensive and I had to be more careful of when >to use it. > >Did I say two? Here is one more. >3) Some of the evaluation code became much much more expensive and I had to >rewrite that to. In fact this is still ongoing and will probably never stop :) Why these problems? When I upgraded to bitmaps, I didn't completely phase out my old board representation, so almost all of my old code was reusable (although I soon decided that bitmaps could do the same thing faster) James > >> >>I think the real problem with testing for king in check comes when you don't >>maintain an atkto array of bitboards. They do take some overhead to maintain, >>but the check test becomes a piece of cake, as does MVV/LVA order capture >>generation. In Crafty I think Bob generates his attack maps on the fly, using >>rotated bitboards for very efficient sliding piece move generation. Of course >>rotated bitboards could also be used to help update the attack tables, but I >>think this would be overkill, as both the extra bitboards and the tables >>represent overhead to do the same job, and as long as you keep both attack from >>*and* attack to tables, it is possible to update them efficiently without the >>help of the rotated bitboards, since each table can be used to help update the >>other. The tables slow down my move making process, but they help in all sorts >>of other ways (like check detection), so it is not clear overall whether they >>are worthwhile or not. I am experimenting with generating moves using rotated >>bitboards, but to make it work well I may have to rethink things like check >>detection, because it becomes more expensive without those tables. >> >>Best wishes, >>Roberto > >I suppose that you have four routines to update your bitboards. Something like >CutAtttacksTo, ExpandAttacksTo, DeleteAttacksFrom and InsertAttacksFrom. If you >used rotated bitboards to get all the bits from a certain square you could OR >that into your atkfr table but you still had to loop through all these bits in >order to update the atkto table. So I agree, it would probably be an overkill... > >//Peter
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.