Author: Robert Hyatt
Date: 15:14:00 05/26/02
Go up one level in this thread
On May 26, 2002 at 16:29:31, Vincent Diepeveen wrote: >On May 26, 2002 at 11:33:26, Robert Hyatt wrote: > >>On May 25, 2002 at 09:50:27, Vincent Diepeveen wrote: >> >>>On May 25, 2002 at 09:32:58, Russell Reagan wrote: >>> >>>A few rude things can be done pretty quick with bitboards >>>at 64 bits processors, which is what Bob aimed at a year >>>or 10 ago, >>>but as soon as you want to evaluate things in detail, then >>>please remember what bitboards are: they provide 1 bit of >>>info a bitboard about a square. That's very little info. >> > >May i refer to our discussion a year ago where i took >attacktables and keeping them incremental updated as >example. May I refer to my response? If I want attack tables, I can create and keep attack tables. The basic "bitboard" being discussed is a chess board representation only. I used to keep different sorts of attack tables but got rid of them because I found other ways to do whatever was needed, at a cheaper cost. But as far as the "not much information in a bit" that is well off the mark. IE one bitmap to list all squares attacking a specific square. All squares attacked by the piece on a specific square. All the pieces of a particular type anywhere on the board. Etc. Fairly dense... > >Best regards, >Vincent > >>OK.. you have an array board[64] (or whatever). Exactly how much >>info does board[i] provide? ie assume a white knight is on square >>i. Exactly how much information do you get from board[i]? From >>my "white_knights" bitboard I find the location of _all_ white >>knights. Not just one... >> >>Your example is not so good... >> >> >>> >>>So obviously when you require many details about a certain >>>square, which makes other methods galaxies faster >>>than bitboards. >>> >>>There are even several ways to do it faster. >> >> >>Including faster than the way you are doing things. Bitboards have some >>serious advantages on 64 bit machines, and they make evaluation very nice >>in many cases... Particularly when looking for "patterns"... >> >> >> >> >> >>> >>>>I hear about how great bitboards are because they [insert one of the many >>>>reasons here]. I'm interested in two reasons in particular, because I do not see >>>>how these reasons work. >>>> >>>>The first thing I'm curious about is computing whether or not a square is >>>>attacked by a certain side. This is supposed to cost about a couple of array >>>>lookups and an AND operation, right? Look up the white king bitboard, look up >>>>the black pieces attack bitboards, AND them together, and you can tell if the >>>>king is in check. That's what I've always heard anyway. Clearly this is much >>>>faster than ray tracing the board looking for opposing pieces, but I don't see >>>>how this bitboard method would even work. For example, for this to work, you >>>>have to have a valid "black pieces attack" bitboard. To compute this you could >>>>OR together all of the attack bitboards for each piece. The problem is that you >>>>have pseudo-attacks. So this computation above where bitboards calculate whether >>>>or not a square was attacked really only says "this square MIGHT be attacked", >>>>right? At which point, you would have to do the ray tracing anyway, and it's not >>>>really any faster, right? I'd like some clarification on this. >>>> >>>>The other thing I recall Bob saying was that using bitboards you can calculate >>>>mobility for "free". Again, this seems like you could calculate pseudo-mobility, >>>>but to calculate actual mobility, you'd have to do ray tracing just like you >>>>would with another board representation scheme. I'd appreciate some explaination >>>>of this also. >>>> >>>>Thanks, >>>>Russell
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.