Author: Russell Reagan
Date: 16:15:43 08/30/03
Go up one level in this thread
On August 30, 2003 at 14:37:44, Tord Romstad wrote: Hi Tord, >1. One of the things I dislike about bitboards (at least the modern >approach with rotated bitboards) is that even very simple operations >like generating moves seem to require either using huge lookup tables >(like in Crafty without -DCOMPACT_ATTACKS) or writing some extremely >complicated and unreadable code (like Crafty _with_ -DCOMPACT_ATTACKS). >Is there a way to use rotated bitboards without having big tables, >and still keeping the code short, clean and readable? Yes, there is a very nice way to do this IMO. Tim Foden uses tables that are only a few KB (even smaller than Crafty's compact attacks I believe), and his code is very readable IMO. Read his posts in this thread: http://www.chess-archive.com/ccc.php?find_thread=306667 >2. Another problem with bitboards is that there is no obvious way to >compute "weighted mobility". While it is trivial to compute the number >of pseudo-legal moves for a piece with bitboards, this number is usually >not very interesting (at least not in my program). In most cases, some >squares are much more valuable to attack than others. Given a 64-byte >array of weights, and a bitboard of squares attacked by a piece, is there >a fast way to compute the "dot product"? I have browsed the archive >and noticed that this question has been discussed numerous times before, >but I have never seen a good answer (Bob has explained a lot of times >how to do this on a Cray, which is not very useful to me). Some of what you say indicates that you're not thinking in terms of bitboards. More about this in response to #3. First, consider the real overall affect weighted mobility has on your program. I don't think any single evaluation parameter (maybe material, but that will never be costly to compute) is worth choosing or rejecting a board representation over another. As for how you might compute it, here are a few ideas. If your lookup table is symetric (for instance, in a knight piece square table the corners will likely have the same value, as well as the center squares, etc.), or if a lot of squares simply have the same value, then you should be able to compute your mobility bitboard, AND with each corner square, do a population count of the resulting bitboard, and multiply that value by the value for "knight in the corner" (or whatever you're measuring). I imagine in a lot of tables, many of the values are the same. If this is the case, you could create masks to isolate those squares and then do popcount/multiply to compute weighted mobility. I suspect this might even be faster than scanning all over the board. A further advantage of this approach is that you're not limited to creating static masks for isolating particular squares. You might decide later to compute a bitboard of "really important squares" on the fly, and then you could compute your weighted mobility based upon dynamic factors rather than having static squares values that never change. >3. I also dislike the fact that bitboards are much too big to be used >as indexes to lookup tables, and that extracting information from them >is often difficult to do without looping through all the 1 bits. It is >easy to compute a bitboard of all pieces which attack a given square, >but in my evaluation I want to extract information about the number and >types of attackers in a small and compact bitfield (which can be used >as an index to a lookup table), while throwing away information about >the locations of all the attackers. How do I achieve this with bitboards? You said something here that raised a red flag: "I want to extract information about the number and types of attackers in a small and compact bitfield (which can be used as an index to a lookup table)..." When working with bitboards, and you catch yourself thinking "this is how I want to accomplish X", stop right there! :) How you do things in your non-bitboard program will probably be very different from how you do things in a bitboard program. Rather than thinking, "how can I compute a value for my lookup table?" ask yourself what you're wanting to compute, then think about how you can use the set of tools that bitboards offer to compute that. The sooner you learn the set of tools that bitboards offer, the sooner you're be able to combine them and "think 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.