Castling Evaluation

[D Sceviour]

Evaluating castling can be difficult. Here are some possible castling states:

CASTLING_AVAILABLE_KINGSIDE
CASTLING_AVAILABLE_QUEENSIDE
CASTLING_AVAILABLE_BOTHSIDES
CASTLED_KINGSIDE
CASTLED_QUEENSIDE
CASTLING_FORFIET
ROOT_CASTLING_STATE
KING_POSITION_ROOK_H1
KING_POSITION_ROOK_A1

Each of these states can be compared and evaluated. The values given are arbitrary and based on centi-pawns for the purpose of comparison. The first comparison looks easy enough to understand. Simply, it is better to be able to castle than to forfeit a castle so one could compare values:

CASTLING_AVAILABLE_BOTHSIDES = +10
CASTLING_AVAILABLE_KINGSIDE = +5
CASTLING_AVAILABLE_QUEENSIDE = +5
CASTLING_FORFIET = -5

Another evaluation is to compare how much to score for a castled position, which should more favorable than an un-castled position, or a forfeited castle position:

CASTLING_AVAILABLE_BOTHSIDES = +10
(CASTLED_KINGSIDE OR CASTLED_QUEENSIDE) = +10

The two values fight against each other and the side does not know what to do unless the difference in values is large! Although there may often be general problems with evaluation overlapping on total evaluations, castling status is a specific conflict. Maybe it looks simple enough to give more weight to a castled position, but how does one tell the difference between CASTLED_KINGSIDE and CASTLING_FORFIET? It is very difficult to tell whether the side has forfeited castle, or castled and then moved the king.

Castling status is directly related to development, so even further code could assess how close castling is available. For example, assess whether the bishop or knight has also been developed. Additionally, compare the castling state at evaluation time with the castling state at the root position to determine a dynamic castling value. Also, evaluate the king position relative to the rooks. Maybe additional code can be used to determine rook position such as rook on H1, but is the expense worth it? For example:

KING_POSITION_ROOK_H1[king square] = {-5,...}

This sort of code can grow exotically. Ultimately the position also has to be assessed considering king safety. Given enough depth, the engine will often find a castle for other reasons or values than a CASTLING state.

One cannot continually test for a forfeited castle position far into the endgame. Such a calculation would be wasted. There are many positions where a forfeited castle is preferable, especially once the queens come off the board. Here, the King should scoot to the center of the board as quickly as possible, and play e2:

[d]r2r2k1/p1p2pp1/1pn4p/8/4pNnP/2P1B3/PPP2PP1/R3K2R w KQ -

It is tempting to conclude that testing for castling legality is enough, and one could ignore castling evaluation.

[bob]

Evaluating castling can be difficult. Here are some possible castling states:

CASTLING_AVAILABLE_KINGSIDE
CASTLING_AVAILABLE_QUEENSIDE
CASTLING_AVAILABLE_BOTHSIDES
CASTLED_KINGSIDE
CASTLED_QUEENSIDE
CASTLING_FORFIET
ROOT_CASTLING_STATE
KING_POSITION_ROOK_H1
KING_POSITION_ROOK_A1

Each of these states can be compared and evaluated. The values given are arbitrary and based on centi-pawns for the purpose of comparison. The first comparison looks easy enough to understand. Simply, it is better to be able to castle than to forfeit a castle so one could compare values:

CASTLING_AVAILABLE_BOTHSIDES = +10
CASTLING_AVAILABLE_KINGSIDE = +5
CASTLING_AVAILABLE_QUEENSIDE = +5
CASTLING_FORFIET = -5

Another evaluation is to compare how much to score for a castled position, which should more favorable than an un-castled position, or a forfeited castle position:

CASTLING_AVAILABLE_BOTHSIDES = +10
(CASTLED_KINGSIDE OR CASTLED_QUEENSIDE) = +10

The two values fight against each other and the side does not know what to do unless the difference in values is large! Although there may often be general problems with evaluation overlapping on total evaluations, castling status is a specific conflict. Maybe it looks simple enough to give more weight to a castled position, but how does one tell the difference between CASTLED_KINGSIDE and CASTLING_FORFIET? It is very difficult to tell whether the side has forfeited castle, or castled and then moved the king.

Castling status is directly related to development, so even further code could assess how close castling is available. For example, assess whether the bishop or knight has also been developed. Additionally, compare the castling state at evaluation time with the castling state at the root position to determine a dynamic castling value. Also, evaluate the king position relative to the rooks. Maybe additional code can be used to determine rook position such as rook on H1, but is the expense worth it? For example:

KING_POSITION_ROOK_H1[king square] = {-5,...}

This sort of code can grow exotically. Ultimately the position also has to be assessed considering king safety. Given enough depth, the engine will often find a castle for other reasons or values than a CASTLING state.

One cannot continually test for a forfeited castle position far into the endgame. Such a calculation would be wasted. There are many positions where a forfeited castle is preferable, especially once the queens come off the board. Here, the King should scoot to the center of the board as quickly as possible, and play e2:

[d]r2r2k1/p1p2pp1/1pn4p/8/4pNnP/2P1B3/PPP2PP1/R3K2R w KQ -

It is tempting to conclude that testing for castling legality is enough, and one could ignore castling evaluation.

I don't think you need a castling evaluation, other than for the special case of losing castling rights due to moving one of the rooks, or moving the king which is even worse.

Otherwise, your king safety evaluation should dictate when you should castle, or if you should.

I saw a quote from a GM once that went like "castle if you want to, or if you need to, but not just because you can."

[Sven]

Hi Dennis,

you gave a lot of reasons why castling itself should better not be part of the static evaluation. In fact many engines do not include it. The information provided by the statement "xy has castled kingside" is often not precise enough to use it for evaluation. Think of 0-0 followed by Rf1-d1, Kg1-f2-e1. Here White has castled kingside but his king is back on e1. Or 0-0-0 followed by Kc1-c2-b3, how is that position related to once having castled? Or Ke1-f2, Rh1-f1, Kf2-g1 as "artificial castling". Usually king safety (as other elements of evaluation) is evaluated by looking at the current position, not how we got there. So evaluating castling is a kind of path-dependent evaluation that should mostly be avoided.

A king on e1/e8 having lost all castling rights might receive a penalty since you can expect that bringing the king to a safer place (from an opening/middlegame viewpoint) will cost more time compared to having at least one castling available.

Some parts of king safety evaluation, e.g. pawn shield, might also take into account castling availability in combination with knowledge about the degree of safety the king would get when castling kingside resp. queenside. So castling kingside might be unattractive if some of the f-g-h pawns have already been moved or are missing completely. I think Fruit did that kind of pawn shield evaluation. But I still think this includes some guesswork so I'm not sure whether this should be recommended.

[D Sceviour]

I don't think you need a castling evaluation, other than for the special case of losing castling rights due to moving one of the rooks, or moving the king which is even worse.

Otherwise, your king safety evaluation should dictate when you should castle, or if you should.

I saw a quote from a GM once that went like "castle if you want to, or if you need to, but not just because you can."

I agree mainly with your point about not needing a direct castling evaluation. Rules of thumb for chess players are different from rules for chess engines. A great one for chess players is "Castle first - philosophize later." That rule is not usually effective for chess programmers.

However, some engines seem to want to put something in for castling status. In Crafty we see the note:

If the king hasn't moved at the beginning of the search, but it has moved somewhere in the current search path, make *sure* it's a castle move or else penalize the loss of castling privilege.

followed by a development_not_castled penalty. Crafty also takes into account (Queens(enemy)) which covers my point about positions where a forfeited castle is preferable.

Ok, but I do not understand how to calculate the loss of castling rights. How does one tell whether the side has forfeited castling, or castled and then moved the king and the rook? From the point of view of the engine evaluation on the horizon, both positions may be the same but the castling status flag can add an unnecessary bias to the score. I have traced some opening bugs to artificial castling that can add discomfort and confusion to the search tree.

[D Sceviour]

Hello Sven,

I agree that "artificial castling" is the problem when trying to establish a castling state. Some old Fruit source shows a pawn shield method similar to Crafty's pawn defect method for King Safety, and both engines make castling status a condition. However, Fruit does not appear to make any penalty for development_not_castled as Crafty tries.

[bob]

I don't think you need a castling evaluation, other than for the special case of losing castling rights due to moving one of the rooks, or moving the king which is even worse.

Otherwise, your king safety evaluation should dictate when you should castle, or if you should.

I saw a quote from a GM once that went like "castle if you want to, or if you need to, but not just because you can."

I agree mainly with your point about not needing a direct castling evaluation. Rules of thumb for chess players are different from rules for chess engines. A great one for chess players is "Castle first - philosophize later." That rule is not usually effective for chess programmers.


However, some engines seem to want to put something in for castling status. In Crafty we see the note:

If the king hasn't moved at the beginning of the search, but it has moved somewhere in the current search path, make *sure* it's a castle move or else penalize the loss of castling privilege.

followed by a development_not_castled penalty. Crafty also takes into account (Queens(enemy)) which covers my point about positions where a forfeited castle is preferable.

Ok, but I do not understand how to calculate the loss of castling rights. How does one tell whether the side has forfeited castling, or castled and then moved the king and the rook? From the point of view of the engine evaluation on the horizon, both positions may be the same but the castling status flag can add an unnecessary bias to the score. I have traced some opening bugs to artificial castling that can add discomfort and confusion to the search tree.

Depends on how you implement things. I have a 2-bit variable that has a bit for kingside castling right and queenside castling right. When the king is moved, this is set to zero. When one of the rooks is moved, the corresponding bit is set to 0. If an actual castling move is played (in the search) the status is set to -1 so that I can recognize the difference between just moving the king and castling.

Works well for me...

I think a penalty for losing one (or both) castling rights makes sense. It is a loss of tempi, as it takes multiple moves to get the king to g1 or c1 and the rook to f1 or d1. So losing the opportunity to connect the rooks faster and get the king out of the center, all in one move, is a measurable loss of time most of the time anyway.