Author: Robert Hyatt
Date: 09:10:00 09/22/03
Go up one level in this thread
On September 22, 2003 at 09:10:55, Vincent Diepeveen wrote: >On September 21, 2003 at 21:09:23, Robert Hyatt wrote: > >>On September 21, 2003 at 03:59:04, Ricardo Gibert wrote: >> >>>On September 20, 2003 at 22:12:51, Edward Seid wrote: >>> >>>>Trying to understand a little bit about bitboards. I have a few questions. >>>> >>>>Here is a 64-bit number in binary: >>>>10000000 00000000 00000000 00000000 ... (32 more zeros) >>>>What square is represented by the one... a1, a8, h1 or h8? >>>> >>>>Another, 64-bit number: >>>>(32 zeros) ... 00000000 00000000 00000000 00000001 >>>>Again, what square is represented by the one? >>>> >>>>Is there a generally accepted standard way of mapping squares on the chessboard >>>>to bits in a bit board? >>>> >>>>VB.NET doesn't have a primitive data type for UInt64. It does have a Long data >>>>type, which is Int64. Is it possible to use Int64 to represent a bitboard, and >>>>the bitwise operators And, Or, Xor and Not? >>>> >>>>There also aren't any built-in operators for bitshifting, so a user-defined >>>>function would have to be used. Do you see any problems in doing bitshifting >>>>using Int64? Does the presence of a sign bit cause any problems? >>>> >>>>Thanks in advance. >>> >>> >>>You have just run up against one of the reasons I have for disliking the BB >>>approach. You can't depend on either computer languages or computer >>>architectures to accept the approach in an elegant or efficient manner. >>> >>>For example, most bitboarders use some assembly language to be efficient even >>>when programming in C. >>> >>> >>>It seems to me that you could still use the BB approach in VB, but you just have >>>to create a routine to handle the right shift so that it does not sign extend. >>>Your VB program could call a C routine that converts to unsigned, then shifts >>>right however many bits, then converts back to signed, then returns the result >>>for VB to use. >>> >>>Another possibility is to do the signed right shift in VB and mask off the MSB's >>>that are supposed to be zero. It is just barely possible the VB compiler will >>>recognize this as an *unsigned* right shift on the operand and do the >>>appropriate optimization. A little testing would be required to see if it does >>>this. You would compare the performance of the "corrected" right shifting with >>>left shifting. >>> >>> >>>Another reason I don't like BB's is it is just an accident that it is a good fit >>>with western chess e.g. when you complete your BB program, try converting it to >>>play Shogi (9x9 board) or Chinese chess (9x10 board). BTW, I know other >>>approaches have the same problem too, so I also have the same concern about >>>them. >>> >>>Good luck! >> >> >>I would remind you that the first "bitboard program" ran on a 60 bit >>computer, _not_ a 64 bit machine. It _still_ worked just fine. Just >>like 64 bit programs work fine on 32 bit hardware... > >And 2.2 times slower even with inline assembly. > >Not to mention what happens when you don't have assembly available. > >For everyone who does *not* like to have inline assembly, do *not* use >bitboards. It's not 2.2 times slower. You just (as usual) don't know what to measure. Move generation is _not_ the main part of a chess engine, contrary to what you believe/state all the time.
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.