Author: Don Dailey
Date: 12:54:41 12/03/97
Go up one level in this thread
On December 03, 1997 at 14:04:57, Robert Hyatt wrote: >On December 03, 1997 at 10:16:00, Don Dailey wrote: > >>Hi Bob, >> >>Thanks for the encouragement. I haven't tried rotated bitboards but >>they sound like a good thing. How are you using them? In move >>generation >>evaluation or both? > >both. Move generation for sliding pieces becomes simple table >lookups. Mobility calculations for evaluation becomes a table >lookup as well... and there's no need to incrementally update >attack tables any longer, because you can look them up just as >fast as you can load the old incremental ones... and save all >the work in make/unmake... > > >> I have a feeling that it may take some time before >>bitboard stuff is completely understood. I think it took a while >>before >>offset programs developed to the point they are today. There will be >>some tricks and techniques that we haven't even thought of and our >>techniques >>will improve. Rotated bitboards may be a typical example of this kind >>of thing. I only heard about them a couple of months ago but have yet >>to experiment with them. I assume you keep all copies of rotated >>boards >>up to date during move making? > >yes... but there are only 3 extra ones, the normal occupied squares >bitmap, and three rotations to make the files and two diagonals appear >in adjacent bits... > > >> >>Keep up the good work. I will share any new things I pick up with the >>whole group. >> >>Don > >be looking forward to it. :) > >Bob I've done mobility as a table lookup in Socrates. Socrates was an offset program but I incrementally updated the pawn vectors for diagonals, ranks and files. The only possible problem with Cilkchess is the extra state I will have to carry around. We basically encapsulate the position and supporting data structures for searching, in a structure we can neatly pass up the search tree and across processors. This turned out to be much more efficient than I thought it would be and is quite workable even for a serial program. We never unmake() a move and do not have a "master" board. We do try to minimize the total amount of state, the rotated bit boards will add somewhat to this state but it may be worth it. I'm not completely happy with bishop mobility in our program. We are using a simple approximation which is counting our access points to the 6th rank (where only pawns can block) This gives us 0 1 or 2 mobility, which we index into a table I think. We also have a bunch of other stuff that tells us how good our bishops are, mainly to do with which pawns of which color are on white or black squares. I'm not toally happy with simple square counting either though. No matter what you do, you will find positions where it shines and others where it's not quite the right formula! I guess that is true of all evaluation. There was a game in the Dutch championship where our bishop got trapped in an endgame, BEHIND the opponents pawn structure. We had great acccess to the 6th rank and Cilkchess was quite happy! But we were forced to sacrafice that thing for 2 pawns and had a much more difficult time winning the game. One possibility now that we have the superior bitmap data structure is to measure mobility by counting squares not attacked by certain pieces, probably just pawns. This would be cheap and easy to compute with rotated boards and might work quite well. I advocate giving attacked squares partial mobility credit which might require 2 lookups. Cilkchess 1.0 counts squares for bishop mobility but we use the count to index a table. The idea is that once you have a certain amount of mobility, don't fight too hard for more. This will let the program focus on more important things once we have found pretty good squares for the bishops. For instance if you have a bishop with 10 squares of mobility and one with zero mobility, the program should prefer to develop the less mobile bishop if the total square count is the same. This seems to be a useful thing to do. Don
This page took 0.01 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.