Position Evaluation

RDChess's position evaluation is like in most other chess programs dominated by material. The possession of a pawn is worth 100 units. Stronger pieces are valued similar to figures documented in the chess literature (a queen  with about 900 units, a rook with about 510 units, bishops and knights with about 325 units).
Positional scores for diverse positional advantages (e.g. a rook on a free file) are much less weighted as material advantage. They rarely exceed the value of one pawn (e.g. at bonuses for passed pawn near the 8th rank).

 A chess mate position  is valued -VMATT or +VMATT (generic value about  +/- 18000 for  loosing respectively  winning), although such a position is detected in the search, and not in the evaluation function. 

The RDChess evaluation is called in game states outside the opening library and discriminates between

• standard positions in the early and middle game,
• standard positions in (early) endgames states,
• Pawn end games (with only  both kings and some pawns on the board),
• Near mating positions (the opponent being more than one rook value behind and having no pawns left). In such positions an abbreviated evaluation function is applied, driving the opponents king  into a corner  to mate;
•  drawn positions because lack of material, positions with 50 Move Rule counts > 100 etc. A value for "Drawn position" is returned;
• Game theoretical special positions like KBB against K or KBN against K end games. A specifically adapted evaluation function is called for these positions.

RDChess doesn't (yet) use Endgame databases.

RDChess keeps diverse global game state variables like the side to which (white and black) has castled, "White in the Endgame" etc.
Depending on that Game State variables,  some position evaluation parameters are switched before searching at the root level.
E.g. the pawn advancement bonuses are increased at falling material sums or on the opposite side where we have castled, or the king changes his strategy from hiding in a corner in the early middle games to strive for the center, if the opponent material decreases.  

 For standard positions the evaluation function  calculates  the sum of  

• the material balance (material difference between the sum of the material values of the white and black pieces), 
• an additional material function value with a trade down bonus, raising the score for the side in advantage, if there are less pieces and less pawns on the board (this term is described in articles about the Northwestern university chess program CHESS 4.5),
• a field control term (difference between the number of from black and white attacked squares, weighted with quality factors),
• and positional score terms for pawns, the king and all the other pieces.

The detailed evaluation features and exact  values of the many evaluation parameters  are not described here because of lacking space. Interested may look at the source code, freely available.

Pawn evaluation

The calculation of the pawn score term is the most elaborated part of the evaluation function and certainly one of the most important procedures.

Various positional characteristics like isolated pawns, doubled pawns, backward pawns, pawn advancement and passed pawns are scored.
For pawn advancement 12 x12 board advance tables are pre calculated at each root position, containing a value which is scored for a pawn standing on this square. The king castling status at the root position is taken into account. E.g. pawns on the opposite side of the board  where the own king has castled get a higher advance bonus. Has the opponent king castled to this side, the advance bonus is even more raised.
Passed pawns are scored higher if they are supported by adjacent, connected own pawns. The attack status or blocks on squares before a passed pawn (in direction to the promotion square) is taken into account.    

King evaluation

The king evaluation is strongly divided into a standard evaluation where king safety is of importance and an Endgame evaluation, where the king actively takes part in the game. 

The standard evaluation punishes facts which hinder castling and rewards  a king which has already castled. The punishment decreases for an not castled or "lone standing" king proportionally with a falling material strength of the opponent.

In the endgame there is a bonus for center tropism (small distance of king to the center of the board).. 

The king evaluation is strongly interconnected with the positions of the pawns.
In standard evaluation the pawn shelter around the king is rewarded.
In the Endgame the distance of the king to pawns, especially to passed pawns and to "backward" pawns (pawns which cannot advance because of threads or hang behind) is of advantage and positively scored.

In a Pawn Endgame the distances of the kings to the promotion squares are considered ("square of king"- promotion rule) and in unmistakable favorable positions for queening very high bonuses are scored .

King-Pawn Hash Table

RDChess doesn't use like most other chess programs a pawn formation hash table and eventually a king hash table..

Instead of, because of the many evaluation terms both depending on the places of the kings and pawns, a single hash table, holding evaluation values for positions with identical king and pawn squares is kept.
This unique scheme proved to be quite advantageous, the read hit rate in the King-Pawn-Hash-Table  is quite high, which I believe is because of  seldom advantageously made king moves during a search.    

Evaluation of Officers

All officers are punished for standing on the first rank in the early middle game, in order to favor early piece development (but queens are punished for moving too early over the third rank).
All officers get bonuses for controlling more centrally located squares and squares around near the opponents king.
Hung pieces (of the side on move) are punished. Against the king pinned own pieces are punished (see Pinned Pieces).
Rooks get a bonus for being on the seventh rank, for doubled rooks, for being on a file with passed or backward pawns. Standing behind a passed pawn in the Endgame is even more advantageously.
"Bishop pairs" (possession of more than one bishops of opposite colors) get a bonus.
In the endgame an proprietary RDChess bishop positional term is added. At endgames with different colored bishops or where the opponent has only a bishop of one color the own pawns get bonuses for standing on fields with the same color as the own bishop and punishments on fields with opposite color as the opponents (lone) bishop. For the opponents pawns there counts the opposite.
This term makes it easier to defend own pawns and attack the opponents pawns with bishops and should be advantageously in  endgames, where is more room on the board. On the other side putting

There are some other scores not mentioned. 

Performance

RDChess is a medium strength program, comparable with other free/ shareware chess programs like GNUCHESS or Waxman.
It is clearly inferior to commercial programs like Fritz etc. and other good academic programs like Crafty.

Anyway, it's strong enough to win nearly always against its creator (me) and 95% of all chess players on the world with a setting of 3 seconds/ move.

RDChess searches about 30.000 nodes/second in the opening,  about 60.000 in the middle game and more than 90.000 nodes/s in end games (with few pieces left) on an Intel Pentium III 450 MHz processor.

I observed a strong dependence of the search velocity on the alignment of critical data structures and (supposedly) the distribution of dynamical data in memory (L2 cache). Inserting a few bytes of code and rebuilding the program causes an unpredictable variation in the search velocity of  up to 20 %, supposedly depending on the alignment (byte, word, .. paragraph/32 byte boundary) of often used data structures !

 I have no data about the quality of code (relating to speed) generated by the Delphi 5 compiler (with compiler option “optimization” checked) compared to C++ Builder V4 or MS Visual C++ V6 generated code.

I assume that C++ code with compiler optimization is faster than Object Pascal code, but that is only a guess of mine.
I tried compiling the Delphi 5 code with C++ Builder V4, in order to port later the code to C++. This failed because of some incompatibilities between both compilers relating to register use in inline assembler code.

Back to RDChess Technical Description Part 2

Back to RDChess Technical Description Part 1

Last modified 2002-08-22   Rudolf Posch