26

I often hear chess experts and chess articles say that when opposite side castling occurs on the board that it is important to launch an attack on the enemy player as fast as possible. Up to the point where giving up a couple pawns or a piece could be justified.

In other words, it seems like castling opposite sides changes the dynamic of the game. How much this change is I'm not sure of. So here is my question:

Is opposite side castling significant enough that a chess engine should think about such positions differently from how it would normally?

For example, a chess engine could lower the importance of material and up the importance of king safety in its evaluation when opposite castling occurs.

  • 6
    It's certainly not conclusive, but I did a search for the terms "castle", "castl", "opposite" and "opp" in the Stockfish code and found nothing related opposite castling. – emdio Aug 11 at 9:32
  • 9
    The philosophy of neural-network based approaches, such as Leela, are that the engine should not be given any preconceived notions at all, but would presumably learn these kinds of heuristics through experience. – usul Aug 12 at 13:50
35

I'm pretty sure Stockfish doesn't have explicit code that handles opposite-side castling. What it does have is:

  • Some kind of "menace" score for enemy pawns advancing against our king. The closer they get, the more dangerous Stockfish thinks they are.
  • Some kind of "pawn shield" score for friendly pawns in front of our king. The fewer there are, the more dangerous Stockfish thinks the position is.

Therefore you get kind of a balancing act: if we castle on the same side, then we could advance our pawns against their king (getting the "menace bonus"), but it would reduce our pawn shield (and therefore losing the "pawn shield bonus"). The converse does not hold in opposite side castling, which therefore encourages the engine to push pawns against the enemy king.

Of course, the details are more complicated than this, but that's the gist.

| improve this answer | |
  • 1
    "The closer they get, the more dangerous Stockfish thinks they are." That makes sense, doesn't it? A pawn at it's starting position is usually a lot less dangerous than a pawn at the center of the board. – Mast Aug 13 at 13:09
  • 3
    @Mast yeah, it does. Things like that are why we say Stockfish incorporates human knowledge. – Allure Aug 13 at 13:24
16

Interesting question. I think it depends on how much bottom-up intelligence the engine has. For example, AlphaZero was given no explicit heuristics, but was able to infer plenty of strategy by playing itself millions of times and learning that way.

An engine with explicit heuristics can also exhibit additional strategies you didn't program into it. As a non-chess example, I've programmed a Connect Four engine with a number of heuristics. Using these and its search algorithm, it then tended to favour clumping pieces together in the centre when given the opportunity. While you might argue the engine doesn't necessarily "understand" this bottom up behaviour it's doing here (does a program really understand anything it does?), it's still playing so that for all intents and purposes, it values clumping pieces in the centre.

In my opinion, if a chess engine is able to infer some heuristic A (or behave as if it understands this heuristic, even if it's just bottom-up behaviour), given a set of explicit heuristics X, then the question comes down to whether you can describe A better than the engine would understand it on its own. If you're making your own chess engine then I think it's best to make some explicit heuristic for opposite-side castling. For the top engines though I'm not sure whether or not they do this, for the reasons discussed. It might be hard to understand the raised importance of king safety without calculating far ahead and seeing pawn storms happen, so it's reasonable to think these engines would have something given to them about opposite-side castling.

| improve this answer | |
  • 3
    Your connect four engine doesn't sound like it inferred any heuristics. It sounds like it just frequently computed the best move to be near the center, from which you then inferred the idea of a heuristic that your program did not actually use. – user2357112 supports Monica Aug 12 at 2:15
  • 6
    @user2357112supportsMonica Well a computer program has to obey its code, and do nothing else. So it can't write additional code for some extra heuristic, but it can behave as if it has this heuristic. At that point you can debate whether the engine "understands" this extra behavior it's exhibiting, and it comes down to what understanding even means. I edited the second paragraph for more clarity. – Inertial Ignorance Aug 12 at 6:29
  • 1
    AFAIK your connect four engine does not employ any heuristics. Stockfish or similar engines have hard-coded strategies in the program, they are not just "behave as if it has this heuristic". On the other hand, your program did not move to the center intentionally. It's just you who concluded its moves. – null Aug 13 at 2:37
  • 1
    @HighlyRadioactive I have hard coded strategies/heuristics for certain aspects of Connect Four, but not particularly for clumping pieces in the centre. This was just for an analogy to a hypothetical chess engine that doesn't have an explicit heuristic for opposite side castling (instead it would have many other heuristics), but behaves as if it does. – Inertial Ignorance Aug 13 at 3:57
  • 3
    Clumping pieces in the centre is not a heuristics, just a behaviour. The OP is asking "should opposite castling be a heuristics". – null Aug 13 at 4:05
7

I'd like to make explicit a point that's been hinted at by the existing answers.

I'm from an AI, not specifically a chess, background. The usual approach to problems in games like this is to treat the game as a Markov process: a system in which future states are (maybe probabilistically) determined entirely by the current state, with no need for an explicit "memory" of how one arrived at the current state. Everything there is to know is represented in the observed board state.

In this context, a chess engine wouldn't need to be aware of any history at all. Maybe the players just randomly placed pieces on the board until they arrived at the current board state: the engine doesn't know or care if it was switched on mid-game or whatever, it doesn't rely on remembering anyone's past moves. This makes sense: suppose your engine did pay extra attention to the fact that opposite-side castling occurred. How long should that matter for? Should we learn separate evaluations for "the pieces are here, and OSC occurred [1, 2, 5...] turns ago"?

Humans playing human opponents may develop a model of opponent psychology: maybe you can tell your opponent's attention is fixated on a certain part of the board, or predict what they're planning based on their prior moves, their tempo, the decisiveness with which they handle the pieces. For a computer to consider this would require adding far too much extra uncertainty and supposition into a problem that's already really really hard just from the board state combinatorics--assuming you could even find a way to communicate those factors to the computer. And learning from it would mean learning bad data about board position--because the computer would have to separate the learned model of its (individual) opponent's psychology from the learned evaluation of how good a particular board position is.

Instead the computer plays like one of those chess masters who plays 15 different opponents at once: by ignoring the history of the game and just making moves based on where things are now.

My guess is that the chess experts you're alluding to are giving a heuristic for evaluating board states. Now, it's possible to imagine an engine which looks at board states and classifies them according to various properties: "OSC has occurred," "[I/my opponent] control[s] the center of the board," etc., and then predicts moves based on those properties as features (to reduce the overwhelming combinatorial complexity of board states & capture some of their natural symmetries). You now have two learning problems: first, how to identify a board state that meets a given heuristic; and second, how to use that set of heuristics to determine how to play. This might have been interesting twenty years ago, but it looks like the state of the art is past that (although this is probably happening in some sense in neural network-based chess engines; but as is typical for neural networks, we humans don't recognize anything coherent in the features that are learned in the middle layers of the network.)

| improve this answer | |
  • TL;DR for all the answers: Markov property. – Mateen Ulhaq Aug 14 at 9:05
  • 1
    @MateenUlhaq yes. I was hoping to also give a bit of an explanation for what that is & the rationale involved as well, though. – Tiercelet Aug 14 at 13:15
5

Is opposite side castling significant enough that a chess engine should think about such positions differently from how it would normally?

I'm not sure your question makes sense. Obviously, a chess engine should take into account the game state. Opposite side castling is part of the game state. So obviously it should influence the evaluation. But what does it mean to "think about such positions differently from how it would normally?" Like, the engine does a "general" evaluation that doesn't take into account opposite side castling, and then "adds in" a factor that takes into account opposite side castling? What would that mean? That there's been opposite side castling is part of the position. What would it mean to to evaluate the position except for the fact that there's been opposite side castling? I guess if your basic analysis just looks at material strength, and doesn't look at position, then adding in opposite side castling could be useful, but any engine advanced enough to be at all competitive is already going to be deeply positional.

| improve this answer | |
  • I gave an example of lowering the weight of material and increasing the weight of king safety as a change that could be made when opposite side castling occurs. Similar to how engines use different evaluation for endgames and middlegames, I thought it could be useful to have different evaluation for opposite side castled positions since I've heard it changes the dynamic of the game. As I've learned through this post though, that is unnecessary as other heuristics can account for it. As user Allure pointed out, menace and pawn shield. – Tauist Aug 12 at 19:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.