Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Design: what would your objects be?

Author: Sven Reichard

Date: 02:53:55 07/04/02

Go up one level in this thread


On July 03, 2002 at 08:41:11, Sune Fischer wrote:

>On July 03, 2002 at 07:57:09, Sven Reichard wrote:
>
>>>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?
>>};
>
>Wow, didn't know it was possible, I wonder if there are any speed issues here, I
>can't have this thing dragging me down :)
>

If you declare the methods as inline, they're just as fast as macros.

>>>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.
>
>No I don't have classes for these, again because I find it a bit silly.
>There is only one Killer object and i don't have any functions working on the
>killer table. The class would just be empty, except for the constructor of
>course :)
>Entirely the same for the history table, though maybe some things would be
>practical to jam into functions (I tend to use macros instead).

Honestly speaking: I don't have killer tables at all, and the history table
isn't an object (the transposition table is). The history table is a member of
the search algorithm, and that class takes care of its initialization.


>Now the hash is intuitively more a class type object IMO and I have declared it
>as a class, but I have two hashes, a pawn- and regular hash and they are not the
>same in regards to member variables. The size of these elements must be as small
>as possible, so I need two hash classes (unless you can teach me a new trick
>here:).

Inheritance?! Put everything that is common to both tables in a base class, and
derive the hash table and the pawn hash table from it. If you want to go to
extremes, write a template class which gets the respective table entries as a
parameter.

template <typename Entry> class HashTable;
class TranspositionTable: public HashTable<TranspositionTableEntry>;
class PawnHashTable: public HashTable<PawnHashTableEntry>;

just an idea...


>The problem for me is, that I need to dynamicly allocate the size of the table,
>and I'm not sure how to make the hash a global object while at the same time
>calling its constructor when doing the dynamic allocation.
>It seems easier to bypass the constructer, and then manually memset the thing
>just after allocation.
>I really need the hash to be global I think, I don't want it inside my Tree
>because I could have more instances of the Tree (in a parallel search for
>instance), but I would never want more than one instance of the hashtable.

The only place where you need the hash table is the search algorithm, isn't it?


>
>>>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.
>
>Hmm, but there is no meaning to the object of an evaluation class.
>What _is_ such an object, other than a collection of functions?
>The evaluation is connected/related to the Board and not much else, so why
>seperate them in two classes?

It also depends on the weights that you give to the different features. The
classical approach is to have a file containing things like

#define DOUBLE_PAWN_PENALTY 42

I put these numbers in the evaluation class; so far as constants, but I plan to
make the proper state variables, so I can experiment with the parameters without
recompiling, or even restarting the program.

Also, the evaluation class is a good place to put the pawn hash table.

I have for example two different evaluation classes; one does purely material
evalution, and one has some rudimentary positional knowledge. I can select which
one to use by changing a single line in the main program.

>>>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.
>
>The static thing is just as bad as the declaring of an object IMO, it is very
>messy to look at, you need to access the functions like RANDOM::gen_rand_64();,
>I will never fall in love with that syntax:)

If you need lots of random numbers in one place, you can always say something
like
using RANDOM::gen_rand_64();


>The namespace thing is just a fancy word for a global object, right?
>

Sort of.

>>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.
>
>I'm not sure how to do that, you see there are holes in my OO-knowledge
>everywhere :)
>
>-S.

class RandomGenerator
{
public:
  RandomGenerator(unsigned int seed = time());
  unsigned int drawNext();
private:
  // ...
};

An implementation is given somewhere in Stroustrup 3rd ed. However, I would
prefer to use the library's random generator, if it's any good - GNU's is, I
think, don't know about MSVC.

Sven.



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.