Author: Sune Fischer
Date: 03:45:40 07/04/02
Go up one level in this thread
>>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.
So would it be possible to do:
0x001000000000.print(); ?
It looks really odd to me, usually you can't pass raw numbers as references,
minor issue perhaps.
>>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.
yeah, ok, if you absolutely must do it OO, but the point of doing it like that
is very limited when they have no common member vars or functions, IMO.
>The only place where you need the hash table is the search algorithm, isn't it?
Some also use the HT for generating PV's, I don't do that, yet.
Besides I could have more "search" instances in a parallel program, so the HT
would have to at least be static.
>>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.
Ok, beginning to see your point :)
These should really vary as the game develops, a passed pawn is usually worth
more in the endgame, for instance.
>Also, the evaluation class is a good place to put the pawn hash table.
Then what about you fancy hash templete class ;)
This is one of those things that could be either place, don't you agree?
>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.
Ah, I have that book, now I just need to read it;)
-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.