Author: Dave Gomboc
Date: 13:36:29 08/20/00
Go up one level in this thread
On August 20, 2000 at 06:54:22, Dan Newman wrote: >On August 19, 2000 at 09:39:02, Larry Griffiths wrote: > >>On August 19, 2000 at 05:17:56, Dan Newman wrote: >> >>>On August 18, 2000 at 20:13:23, Dann Corbit wrote: >>> >>>>On August 18, 2000 at 05:07:09, Dan Newman wrote: >>>>[snip] >>>>>OTOH, I have occasionally considered attempting a full blown OPP chess >>>>>program complete with pools of chess pieces with overloaded new so that >>>>>(for instance) on pawn promotion I could delete the pawn and new a queen... >>>> >>>>Dumb as a box o' rocks observation: >>>>Since the absolute "max" of posible chessmen is known, why hot just preallocate >>>>a "box" of chess pieces with enough spares for either side. Captured >>>>pieces/pawns go into the box and promoted pieces are pulled from it. >>>> >>>>At the start of a game, it contains: >>>> >>>>White rooks: 8 >>>>White knights: 8 >>>>White bishops: 8 >>>>White queens: 8 >>>>White pawns: 0 >>>>No White king slot >>>>Black rooks: 8 >>>>Black knights: 8 >>>>Black bishops: 8 >>>>Black queens: 8 >>>>Black pawns: 0 >>>>No Black king slot >>>> >>>>If you wanted to carry the metaphor further, you could have all the starting >>>>chess men in the box to start with and construct the board by pulling pieces and >>>>pawns out of the box. >>>> >>>>Each piece could have a bit that means in use/in box to use for error checking. >>>> >>>>Sounds like bizarre overkill, perhaps. But if your evaluation removes hundreds >>>>of pieces or promotes hundreds of pieces during a search, it might be useful to >>>>do it that way. >>> >>>This is more or less what I had in mind with the pool idea. When, frex, >>>"new WhiteQueen" gets executed, the overloaded new would find an unused >>>white queen and return a pointer to it. This would be a lot faster than >>>going through the memory allocator... >>> >>>A neat thing about this scheme (of making a class for each piece type) is >>>that you can put the move generator code into those classes and then simply >>>iterate through the piece lists calling the virtual move generator functions >>>to generate the moves. OTOH, this is also going to add a lot of function >>>call overhead to the program. >>> >>>If you are doing bitboards though, this isn't really an option. Instead of >>>pieces being relatively heavyweight objects, they are grouped together in >>>bitboards by type... >>> >>>I think it may be a mistake (when deciding what classes are needed to do a >>>chess progam in C++) to identify the physical objects involved in the game >>>and make classes for them. (That's the first thing I thought of when first >>>attempting this a few years back. The first two sorts of object I though of >>>were the pieces and the board. Beyond that what else is there? >>>I quickly decided *that* was a mistake when I didn't see an easy way to turn >>>pawns into queens.) Instead (I think) you really need to look at what >>>"things" are needed to play the game (like search, eval, moves, state info, >>>etc.) and encapsulate those things instead--when it makes sense to do so. >>> >>>In my current chess program I've only haphazardly OOP'ed stuff in a few >>>places where it helped. For instance, my move is a class, and I get at its >>>from and to-square coords via member functions so that I can experiment >>>with move representation without having to do massive changes to the code. >>>But for the most part I just use C++ as a "better" C. >>> >>>-Dan. >> >>Hi Dan, >> >>My programs has a base class Piece and all my pieces are derived from it. The >>move genereate, makemove, and unmake move are also in the piece class along with >>updating my bitboards. I have a piece pool manager to get pieces and assigning >>them to the board. Pawn promotion flags the pawn in the piece list as inactive >>and gets a queen from the piece pool when it gets promoted. >>My program is just as fast as it always was when I did not do it this way. >> >>Larry. > >Hi, > >That's interesting. It sounds like you have a sort of hybrid program, if >you have bitboards *and* separate pieces in piece lists. Actually, I guess >I have pieces too (in a way) since I have a "board" array with byte sized >entries which store the piece type and color--much as Crafty has. But I >don't have piece lists now that I use bitboards... In fact that's the main >reason I like bitboards; I always found piece lists problematical :). > >I've always wondered where make()/unmake() ought to go in an object oriented >program. I think I'd have a move class and that's where they'd go, but then >how do you give the move's member functions access to all the state data >that they need: 1) pass the board and so forth into make(), 2) have the >board (and other state) be static members of the move class, or 3) make the >board, etc., global? Each choice seems to have its drawbacks. 1) makes >the code cost more cycles that it needs to, 2) begs the question as to how >other parts of the code are to get to the board, 3) seems to be contrary >to the OOP paradigm... I think 1) is probably the best choice. Just >pass a pointer to the state data into make(). I guess you end up having >to do something like this anyway if you want to have a parallel search... > >-Dan. Given that make_move applies an action to a state (action x state -> state), it seems to me that having it as a member function of the game's state would make sense in an O-O program. Unmake_move is directly analogous. Dave
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.