Author: Sven Reichard
Date: 04:57:09 07/03/02
Go up one level in this thread
On July 03, 2002 at 06:46:40, Sune Fischer wrote:
>
>There are a few things though, I'd like to hear how you've solved them.
>
>TimeControl() - do you have a special class for that, if so why, what should I
>do with a time object when I just need to pick the time?
Time control is experimental, and right now done right in the main() function.
>FirstOne() - to read the first bit off a bitboard, where should I put this when
>I don't have a BitBoard class (and I don't see how to make one)?
I don't have bitboards, but where is the problem?
class BitBoard // :public std::bitset<64> ??
{
public:
Bitboard(unsigned long long);
void set(int);
void clear(int);
bool isSet(int) const;
Bitboard& operator &=(const Bitboard&) const;
// ..etc.
int firstOne() const;
operator bool() const; // any bit set?
};
>SetupMisc() - things like hash, killer and history tables, flags for
>communication and all kinds of things. It doesn't really belong anywhere IMO.
In the constructors of the hash, killer, and history tables. Also, a method
Algorithm::setUpSearch() could be useful.
>isDraw() - checks for repetition (needs the Tree) and checks for material (needs
>the Board). Should I make a special evaluation class, seems it would always and
>only depend on the Board.
It depends also on the tree (as you said). I deal with repetitions in an extra
class, and have that called in the evaluation class.
>ProbeHash() - should the hash be an object, it needs a Board.
>
I have a hash table object.
>Moves... - been discussed, its also a hard one, lots of move type functions, but
>MakeMove is really more of a Board type function IMO, although it is also one of
>the things that will get stuck between two classes.
>
>Then there are things such as reading from the book which requires knowledge of
>the Board or Tree, but shouldn't it have a class of its own when the book is a
>true object, albeit just a FILE pointer?
Didn't deal with that yet.
>One of the things I always get stuck with in this OOP is that some things feel
>like they should be put into their own class, but there is never any use for an
>object of the class, other than to call those functions. For instance I have
>functions to make random numbers, to convert ASCII characters, that sort of
>simple things. I wouldn't know what to do with a 'random' object, I just need
>the random number, not the object. It means I first must declare a random object
>to get a random number, pretty silly IMO.
Three possibilities:
a) Put the random number function in a namespace by itself, or equivalently,
make it a static method of a Random class. That way you can be sure nobody
messes with your state.
b) Make a random number generator an object, then you have to create it first in
order to get random numbers. If you're interested in that, you get thread safety
that way.
c) Just call the library function rand() directly.
>There are of course more, but all that I can't find a good answer to I make
>global, it's mixing C with C++, but whatever is the most intuitive to me I use.
That's a good strategy to follow.
S. :)
>-S.
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.