Author: Dann Corbit
Date: 09:53:28 08/21/00
Go up one level in this thread
On August 20, 2000 at 06:54:22, Dan Newman wrote: [snip] >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... How's this for a weird idea: Use several different move generators within one program. For any particular stage of the game or any particular board position, use the internal format which (according to heuristic measurements) will be fastest.
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.