1 Introduction
Over the last several decades, automated and interactive theorem provers have made huge advances which changed the mathematical landscape significantly. Theorem provers are already widely used in many areas of mathematics and computer science, and there are already proofs of many extremely complex theorems developed within proof assistants and with many lemmas proved or checked automatically [15, 20, 22]. We believe there are changes still to come, changes that would make new common mathematical practices and proving process will be more widely supported by tools that automatically and reliably prove some conjectures and even discover new theorems. Generally, proving of mathematical conjectures can be assisted by computers in several forms:

for exhaustive analysis (e.g., for checking of all possible cases);

for automated proving of relevant statements (e.g., by generic automated provers or by solvers for specific theories);

for interactive theorem proving (e.g., for proving correctness of exhaustive analysis algorithms or for direct proving of relevant statements).
Each of the above forms of support provides different sorts of arguments, each has its limitations, and its strengths and weaknesses. In this paper, we advocate that it is their synergy that provides a way for proving complex combinatorial conjectures. Namely, in every proving process, a human mathematician experiments, analyses special cases, tries to discover or prove simpler conjectures, etc. However, all these are typically hidden in the final product and published mathematics is typically the art of polished proofs, rarely the art of how to reach them. Computer support can be crucial in the demanding process of seeking and proving new mathematical truths. However, for each computersupported proving approach, one has to consider the following key questions:

What we have really proved?

Is our proof a real mathematical proof, or just a supporting argument?

How reliable is our proof?

What was the level of automation and the level of human effort required to make the proof?
As a case study, we use a conjecture from one of favourite domains for many AI approaches – chess. We consider a conjecture that states correctness of a strategy for one chess endgame. Endgame strategies provide concise, understandable, and intuitive instructions for the player and correctness means that the strategy always leads to the best possible outcome (under any play by the opponent). We show that both chess strategies and proofs of their correctness can be rigorously formalized, i.e., expressed in pure mathematical terms. Although a strategy for an endgame such as KRK (white king and white rook against black king) is very simple, its formalization has a number of details and it is not easy to prove its correctness. One of our goals and contributions is modelling the chess rules and chess endgames so that the correctness proofs can be made as automated, efficient and reliable as possible.
Through this complex exercise, we will show that a realworld process of proving conjectures such as correctness of a chess strategy can be naturally based on a synergy between different computersupported approaches and combines experimentation, testing special cases, checking properties, exploring counterexamples for some conjectures, and, at the end, proving conjectures within a proof assistant, using as much automation as possible. Correctness of the strategy for the KRK endgame is just an example, and the main purpose of this work is to illustrate a methodology that can be used in proving complex combinatorial conjectures in an efficient and a highly reliable way. In our previous work, we proved the correctness of the very similar KRK strategy within a constraint solving system URSA [19] and a proof assistant Isabelle/HOL[23]. In this paper, we give a unifying perspective of proving conjectures like that one using three approaches – a general purpose programming language, a constraint solver, and a proof assistant, and we further improve earlier proofs in terms of efficiency, reliability, understandability and generality.
Overview of the paper
In Section 2 we give some background on automated theorem proving, SAT and SMT, constraint programming systems and URSA, interactive theorem proving and Isabelle/HOL. In Section 3 we discuss formal representation of chess and chess endgames in various logic and languages. In Section 4 we discuss different methods for reasoning about chess endgames and proving their correctness. In Section 5 we discuss different methods to make our proofs faster, and our conjectures higherlevel and more general. In Section 6 we discuss some related work and in Section 7 we draw final conclusions.
2 Background
2.1 Automated and Interactive Theorem Proving
Automated theorem proving, SAT and SMT
Modern automated theorem provers based on uniform procedures, such as the resolution method, and also specific solvers, such as SAT and SMT solvers, can decide validity of huge formula coming a wide spectrum of areas including software and hardware verification, model checking, termination analysis, planning, scheduling, cryptanalysis, etc. [4]. One of the most widely used SMT theories is linear arithmetic, a decidable fragment of arithmetic (over integers – LIA, or reals – LRA) that uses only addition – multiplication is only allowed by a constant number, and is just a shorthand for where occurs times. Linear arithmetic is rather simple, but expressible enough to be widely used in applications in computer science [4]. There are several decision procedures for variants of linear arithmetic and they are widely available through modern SMT solvers [11].
Constraint programming systems and URSA
Constraint programming systems allow specifying problems and searching for models that meet given conditions, by using various approaches (e.g., constraint logic programming over finite domains, answer set programming, disjunctive logic programming). Some constraint systems, such as URSA
[19], are based on reduction to propositional satisfiability problem (SAT). In URSA, the problem is specified in a language which is imperative and similar to C, but at the same time, is declarative, as the user does not have to provide a solving mechanism for the given problem. URSA allows two types of variables: (unsigned) numerical (with names beginning withn
, e.g.,
nX
) and Boolean (with names beginning with b
, e.g.,
bX
), with a wide range of Clike operators (arithmetic, relational, logical, and bitwise). Variables can have concrete (ground) or symbolic values (in which case, they are represented by vectors of propositional formulae). There is support for procedures and there are controlflow structures (in the style of C). Loops must be with known bounds and there is no
ifelse
statement, but
only ite
expression (corresponding to ?:
in C). An URSA
specification is symbolically executed and the given constraint
corresponds to one propositional formula. It is then transformed into
CNF and passed to one of the underlying SAT solvers. If this formula
is satisfiable, the system can return all its models.
Interactive theorem proving and Isabelle/HOL
Interactive theorem provers or proof assistants are systems used to check proofs constructed by the user, by verifying each proof step with respect to the given underlying logic [31]. Proofs written within proof assistants are typically much longer than traditional, penandpaper proofs [3] and are considered to be very reliable [2]. Modern proof assistants support a highlevel of automation and significant parts of proofs can be constructed automatically. Some proof assistants are also connected to powerful external automated theorem provers and SMT solvers, and thanks to that are now capable of proving very complex combinatorial conjectures.
Isabelle [26] is a generic proof assistant, but its most developed application is higher order logic (Isabelle/HOL). Formalizations of mathematical theories are made by defining new notions (types, constants, functions, etc.), and proving statements about them (lemmas, theorems, etc.). This is often done using the declarative proof language Isabelle/Isar [30]. Isabelle/HOL incorporates several automated provers (e.g., classical reasoner, simplifier) and it has been connected to SMT solvers [5], enabling users to employ SMT solvers to discharge some goals that arise in interactive theorem proving.
2.2 Chess Endgame Strategies
Techniques used by computer programs for chess in midgames (minimaxstyle algorithms) are often not appropriate for endgames and then other techniques have to be used. One such technique is based on lookup tables (i.e., endgame databases) with precalculated optimal moves for each legal position. However, such tables for endgames with more chess pieces require a lot of memory and, in addition, they are completely useless for human players.^{1}^{1}1The Lomonosov Endgame Tablebases that contain optimal play for all endgames with seven or less pieces, generated by Zakharov and Makhnichev (http://tb7.chessok.com/) have around 140 Terabytes. It was shown that there is a position with seven pieces such that black can be mated in 545 moves but not in less moves, if she/he plays optimally. One alternative to huge lookup tables, that is usable both to human and computer players, are endgame strategies. Endgame strategies are algorithms that provide concise, understandable, and intuitive instructions for the player. Endgame strategies do not need to ensure optimal moves (e.g., shortest path winning moves), but must ensure correctness – i.e., if a player follows the strategy, he/she should always reach the best possible outcome. The main focus of our work is formal analysis of combinatorial algorithms, so we shall consider only endgame strategies (and not endgame databases).
One of the simplest chess endgames is the KRK endgame. There are several winning strategies for white for this endgame. Some of these were designed by humans, while some are generated semiautomatically or automatically, using endgame databases, certain sets of human advices, and approaches such as inductive logic programming, genetic programming, neural networks, machine learning, etc. However, only a few of them are really humanunderstandable. Some strategies for white were proposed by Zuidema
[32] (a strategy based on highlevel advices instead of search), Bratko [8, 10, 9] (an advicebased strategy consisting of several sorts of strategic moves), Seidel [28] (a strategy using the ring structure of the chessboard), Morales [24, 25] (short strategies produced by inductive logic programming assisted by a human), etc.2.2.1 BratkoStyle Strategy for White for the KRK Endgame
In the rest of the paper, we will consider one strategy for white for KRK: it is a variation of Bratko’s strategy and slightly modified with respect to the version published earlier [21].
We assume standard chess notions such as legal moves, mate, stalemate, etc. (as defined in the FIDE Handbook [13]). Legal KRK positions contain three pieces: the white king (WK), the white rook (WR), and the black king (BK). On the board, there are 399 112 such positions, while the strategy is applied only to 175 168 of them – those with white on turn.
Auxiliary Notions
In the following text, we assume that files (columns) and ranks (rows) of the chessboard are associated with the numbers , and the squares are represented by pairs of natural numbers between and . For formulating the strategy, we use several auxiliary notions (standard notions or notions introduced by Bratko):
Manhattan distance: For two squares of the chessboard and , the Manhattan distance equals .
Chebyshev distance: For two squares of the chessboard and , the Chebyshev distance is the minimal number of moves a king requires to move between them, i.e.,
Room: Following the strategy, white tries to squeeze the rectangular space available to black king – that space is called the room (Figure 1) and is measured by its halfperimeter. When the black king and the white rook are in line, the black king is not confined (not restricted to a rectangular area), and the room takes the value 15 (whenever the black king is confined, the halfperimeter of the guarded space is at most 14)^{2}^{2}2On the board, the halfperimeter is at most , and when the black king is not confined, the room is .. Therefore, if the rook is on the square and the black king on the square , then room equals:
where and are lengths of sides of the guarded space (it holds that if and if , and analogously for ).
Critical square: The critical square is the square adjacent to the square of the rook in the direction of the black king; if the rook and the black king are in the same column or the same row, then the critical square is between them, otherwise, it is diagonal to the square of the rook (Figure 1). More precisely, if the rook is on and the black king on , then the coordinates of the critical square are given as follows:
Rook exposed: The rook is exposed if white king cannot reach it fast enough to protect it, i.e., if white (black) is on turn and the Chebyshev distance between the rook and the white king is greater by at least 2 (by at least 1) than the Chebyshev distance between the rook and the black king.
Rook divides: The white rook divides two kings if its coordinate is (strictly) between coordinates of the two kings, or if its coordinate is (strictly) between coordinates of the two kings (or both).
Lpattern: Three KRK pieces form an Lpattern if the kings are in the same row (column), at the distance 2, and if the rook and the white king are in the same column (row) and at the distance 1 (Figure 1).
Kings on a same edge: The two kings are on a same edge if their files or ranks are both equal to 0 or 7.
Towards black king’s edge move: If the black king is on an edge, then the white king moves towards that edge.
Basic Strategy
The strategy can be defined as follows:

ImmediateMate: If there is a mating move, play it;

ReadyToMate: If the above is not possible and there is a move that leads to mate in the next move, play it (Figure 1).

Squeeze: If none of the above is possible, make a move (by the rook) that reduces the room and in the reached position it holds that: the rook is not exposed, the rook divides the kings and it is not stalemate.

Approach: If none of the above is possible, then approach the critical square, i.e., move the king so the Manhattan distance between the king and the critical square is decreased; in the reached position, the following has to hold: the rook is not exposed, the rook divides the kings or there is a Lpattern, if the room is less than or equal to 3, then the following holds: the white king is not on an edge and if its Chebyshev distance from the rook is 1, then it does not make a move towards the black king’s edge, and it is not stalemate. Play the approach move in a nondiagonal direction (ApproachNonDiag) only if no diagonal approach move (ApproachDiag) is possible.

KeepRoom: If none of the above is possible, then keep the room, i.e., move the king if that does not increase the Chebyshev distance from the rook; in the reached position, the following has to hold: the rook is not exposed and divides the kings, and if the room is less than or equal to 3, then the following holds: the white king is not on an edge and if its Chebyshev distance from the rook is 1, then it does not make a move towards the black king’s edge, and it is not stalemate. Play the keep room move in a nondiagonal direction (KeepRoomNonDiag) only if no diagonal keep room move (KeepRoomDiag) is possible.

RookHome: If none of the above is possible, then move the rook to be horizontally or vertically adjacent to the white king; in the reached position the following has to hold: the rook is adjacent to the black king only if it is guarded by the white king and it is not stalemate.

RookSafe: If none of the above is possible, then move the rook to some edge (other than the edge it is possibly is on); in the reached position the following has to hold: either both kings are next to the rook or the Chebyshev distance between the rook and the black king is greater^{3}^{3}3If the distance would be equal to 2, then the black king could approach the rook, so the rook would have to make the rook safe move again and again. than 2, and it is not stalemate.
On the board, the above steps are used in the following number of positions (in total 175168): 1512 (ImmediateMate), 4676 (ReadyToMate), 116504 (Squeeze), 12160+4020 (ApproachNonDiag + ApproachDiag), 3160+184 (KeepRoomNonDiag + KeepRoomDiag), 32520 (RookHome), 432 (RookSafe). Note that some kinds of strategy moves can be played in different ways. For example, when the Squeeze move is applicable, there are often several possibilities to play it. Although it is not necessary for correctness (as we shall show), for efficiency reasons (i.e., for reaching mate faster) Squeeze should be maximal – it should be played so that the black king is confined to the smallest possible room. Also, if there are more RookHome moves applicable, the one with the smallest Manhattan distance between the rook and the black king should be chosen. For other moves for which there are more options, it does not matter which of them will be selected.
For the sake of formal analysis, the above strategy differ to some extent from Bratko’s strategy, but still keeps its spirit [21].
3 Problem Representation
The FIDE Handbook [13] is the authoritative account of the laws of chess, but it specifies chess only informally and is suitable only for informal reasoning. For more rigorous reasoning, the chess notions have to be specified formally, in some strict framework. In the rest of this section, we will discuss central issues in representing general chess rules and notions in various computer based frameworks. We will discuss three concrete examples – representation within the general purpose programming language C, within the constraint solver URSA and within the proof assistant Isabelle/HOL.^{4}^{4}4All formalizations, programs and proofs discussed in this paper are available online from http://argo.matf.bg.ac.rs/downloads/software/krkstrategy.zip.
3.1 General Chess Rules
General chess notions can be strictly defined, for example, in terms of the structure of natural numbers, or within ZermeloFraenkel set theory (ZFC), or given axiomatically, via axioms in first order logic (FOL), or even using a generalpurpose programming language (such as C or Haskell). For computersupported reasoning about chess, the most reliable approach is to have explicit definitions of chess within a rigorous logical framework of some proofassistant, which is usually some variant of higherorder logic (HOL) or type theory.
Chess is a complex game, with many rules, but it turns out that there are not many central notions that have to be used to state the properties like correctness of strategies for chess endgames that we are primarily concerned about. The chess game starts in an initial position, then two players play after each other and the game proceeds through a series of legal positions until one player wins or the game is drawn. Transitions between positions are made by legal moves played by the players. Therefore, to formally specify a chess game, one must represent arbitrary chess positions, the initial position, legal positions, legal moves, positions won for a player (its opponent is checkmated) and positions that are drawn (it is stalemate or a checkmate cannot be reached). Other specific definitions (e.g., the capture rules, or the promotion rules for a pawn) are just building blocks used to define the central notions. Instead of full details of a general chess formalization [17, 23], we shall give only a rough outline. Since it needs to be strict and formal, we will present it in the style of the proof assistant Isabelle/HOL. The basic notions are the following.^{5}^{5}5Following the spirit of given representation, a general theory of two player strategic games (including chess) could be defined.

The is a datatype denoting two players ( and ).

Positions are represented by a type , characterized by the following components.

A function gives the player that is on turn in the given position.

A function gives the piece on the given square in the given position (or returning the special value if the square is empty). In the above, the datatype contains the chess pieces , , , , (note that we do not consider pawns) and the datatype contains the squares on the board. The function implicitly ensures that there cannot be more than one piece on a square.

The above notions are used in definitions of the following basic functions.

The function checks if the given position is legal.

The function checks if the second given position can be reached from the first given one by a legal chess move.

The function checks if the player on turn is checkmated in the given position.
The above notions for chess need to meet some conditions. For example, concrete definitions for and have to ensure that legal moves can only be made between legal positions, so the following holds: (which we can prove as a lemma).^{6}^{6}6Notice that such conditions hold for most (if not all) two player strategic games, so if we build a general theory of two player games, formulae like the given two would have a role of axioms. Also, after a legal move, the opponent is on turn, must hold (where denotes the opponent side).
Some details of implementation in Isabelle/HOL
^{†}^{†}margin:For illustration, we show some auxiliary definitions from our Isabelle/HOL formalization (that follows Hurd [17]) that are used in definitions of , , and . The type is a pair of a side that is on turn and a function that maps squares to white and black pieces (or the special value if the square is empty).
The type is implemented as a pair of integers^{7}^{7}7Instead of integers, natural numbers could have been used. However, integers allow expressing some properties using subtraction more easily. – this enables to express many chess definitions succinctly, using arithmetic. definition must ensure that all pieces are within the board bounds, for which the function is used (global constants and , for files and ranks, determine the size of the board). We also define functions that for a given position and a square check if is empty (), or occupied by a piece of a given side ().
Next we define scope of each piece. For instance:
In a position , a square attacks if the line between them is clear ()^{8}^{8}8Since squares that a knight attacks are not on the same line with the square that it is on, the clear line condition is always satisfied., and if there is a piece on such that is in its scope.
(  
False  
(_, )  
(_, ) …) 
A side is in check in a position if its king is on a square , and there is an opponent’s piece on some square such that it attacks the king on .
( .  = (, ) 
( ) ) 
Finally, a position is legal (denoted by the function ) if the opponent of the player on turn is not in check, and, since we represent squares as pairs of integers, if all pieces are within the board bounds (coordinates of their squares are between 0 and 7, which is checked by the function defined above).^{9}^{9}9It may seem that the definition of legal position should require that the kings are not on adjacent squares. However, that condition is not necessary: if the two kings are on adjacent squares then, following Hurd’s definitions, the player who is not on turn would be in check (his/her king would be attacked by the other king), which is not legal by the above definition.
The notions of legal move and checkmate (i.e., the functions and ) are defined in a similar fashion. Since we shall prove that our endgame strategy will always succeed in checkmating the opponent, we do not need to formalize the definition of a draw.
Note that the outlined theory makes some important simplifications (since we are primarily focused on endgames). First, only pawnless games with no castling are considered. Also, the FIDE rules state that a position is legal if it is reachable from the initial position by a sequence of legal moves, but in the definition of legal positions (i.e., the predicate) we omit this condition and the definition of the initial position. Namely, all positions legal in the strict FIDE sense will satisfy the conditions of the our definition (there might exist some positions that satisfy our definition, but are not legal in the strict FIDE sense). So, since we show correctness of endgame strategies for all positions legal in a weaker sense, our proofs will be valid also wrt. the FIDE definition.
3.2 Chess Endgames
The type represents general chess positions. It can be significantly simplified if only the positions reachable during a specific endgame need to be considered (e.g., in a KRK endgame, only the rules for and are relevant and all other pieces and conditions describing their moves can be omitted). Simpler and more compact representations lead to more efficient reasoning.
The functions on the type that formally describe the general chess notions (e.g., functions , and ) need not be executable (e.g., if definitions of those functions contain quantifiers, the computer framework need not be able to effectively compute if there is a checkmate in a given position). However, to aid some automatic reasoning approaches, it is desirable to have an executable representation (e.g., it should be possible to compute effectively if a position is checkmate, if a move is legal, or to enumerate effectively all legal positions satisfying some given property).
Therefore, an alternative definition of the chess game (chess positions and moves) can be given, and the chess rules relevant for the endgame can be described in simpler and executable terms, which we will call the endgame definition. In the ideal case, both simplified and general chess representation (and all corresponding definitions) should be described within the same computer framework (e.g., proof assistant). In that case, some morphism between the two representations can be defined, and the relationship between them can be formally shown. Further, all reasoning about the endgame properties should be done within the proof assistant leading to highest possible reliability. Reasoning about the endgame properties can also be done in some other systems (e.g., it can be done by using a constraint solver or some customdesigned C programs). In that case, the specific, simplified representation of endgame positions and rules have to be implemented in that system, but the relationship of such implementation with the general rules of chess can be shown only informally, leading to a lower degree of confidence.
In either case (a proof assistant, or some other system), the following notions can be used to represent the endgame rules.

A type represents chess positions encountered during a specific endgame.^{10}^{10}10Note that we will use font for the endgame definition related notions (e.g., or ) and font for general chess notions (e.g., ). It should be able to represent all chess positions that contain pieces relevant for the specific endgame (e.g., in the KRK case, two kings and the white rook) and all positions that can be reached from those during a play based on the strategy. Therefore, there can be a function that is a bijection between and this subset of i.e., a function such that each position from represents some such position from .

The set is the set of possible initial positions for the endgame, i.e., the set of all legal positions in that contain all pieces relevant for the endgame (note that can contain some positions where some pieces have been captured). It must hold that this set represents exactly all legal positions from that contain all relevant pieces (correctness of the endgame strategy is usually formulated for all plays that start in a position from this set).

The function checks if the given position is legal. For any position of type it must hold that .

The function checks if the second given position can be reached from the first given position by a legal move. It must hold that for any given positions and of type it holds that .

The function checks if the player on turn is checkmated in a given position. It must hold that for any position of type it holds that .
The above conditions are necessary (and sufficient) to prove in order to show that if we prove some property for the endgame then that property holds wrt. the general chess rules, too.
3.2.1 A Case Study of KRK
We will present several instances of the KRK endgame definition. The relevant pieces are the two kings and the white rook (that could be captured and our representation needs to cover that situation, too).
Isabelle/HOL and Records
The most natural way of representing the position is to pack all relevant information into a record (a structure) or an array. In Isabelle/HOL we define the following record.
record =  
:: "" (* position of white king *)  
:: "" (* position of black king *)  
:: " option" (* position of white rook ( if captured) *)  
:: "" (* Is white on turn? *) 
In order to represent a chessboard position, such record has to meet several conditions. First, the following condition checks whether all pieces are within the board bounds:
() () ( ()) 
denotes that the rook is captured in position , i.e., that . The following condition checks whether pieces are on different squares
( ) 
Note that this definition uses the notion of , and the predicate which are also used in the definition of the general chess rules. Since both the general chess definition and the endgame definition are given in the same system (proof assistant), we could reuse such definitions.
is the type consisting of all records that satisfy the two conditions given above. The abstraction function () that maps KRK positions to general chess positions that they represent is defined as follows:
= . (  if = then 
else if = then  
else if = Some then  
else )" 
Auxiliary functions that lead to the and definitions are reformulated for the endgame. The following function checks if the black king is attacked, and is used in the definition of checkmate, along with the and definitions (that are not shown here, but are available in the formal proof documents).
() () () () ()  
The definition is taken from the general chess formalization, but the notion of the black king being attack is specific for KRK ( call checks only if the white kings blocks the line between the rook and the black king horizontally or vertically) and such simple way is not correct wrt. the general chess rules (in general chess other pieces must be taken into account). Because of such differences, it is essential to have a formal link between the two layers.
C and Structures
In C, it is natural to represent squares by two integer coordinates. Also, there is no builtin option type in C so, for simplicity, we just add a flag that tells if the rook has been captured (if the rook is captured then its two coordinates become irrelevant). The type is the following:
typedef struct pos { bool bWhiteOnTurn; bool bRookCaptured; unsigned char WKx, WKy, WRx, WRy, BKx, BKy; } KRKPosition;
For efficient storing, we represent each position by a bitvector of length 20: each board square by two triples of bits (as a triple of bits gives 8 possible values, corresponding to the default chessboard size) and two bits for representing which player is on turn and whether the rook has been captured. We implemented functions for transforming the above structure into bitvectors and back.
Unlike Isabelle/HOL, where the conditions that the record must satisfy are explicit, in C these conditions are ensured by additional functions.
It is easy to formulate all relevant chess notions and rules. For instance, the definition of mate is formulated in C as follows.^{11}^{11}11Presented specifications in different frameworks are equivalent and substantially the same. However, there are still some minor differences (e.g., in naming conventions, in grouping of some conditions into predicates, etc), just as there are different programming styles.
bool Mate(KRKPosition p) { return LegalPositionBlackToMove(p) && BlackCannotMove(p) && WRAttacksBK(p); }
URSA Constraint Solver, Bitvectors, and SAT
The URSA constraint solver is based on bitvectors and reduction (“bitblasting”) to SAT. In URSA, a position can be conveniently and naturally specified by six triplets of bits (two for each board square) plus bits for representing which player is on turn and whether the rook has been captured (as in the C version). Therefore, in URSA we represent positions with 20bit numbers, and we developed procedures for transformation from individual pieces of information to 20bit numbers and back.
Since the URSA language is Clike, it is easy to formulate all relevant chess notions and rules, very similarly as in the C version. For instance:
procedure Mate(nPos, bMate) { call LegalPositionBlackToMove(nPos, bLegalPositionBlackToMove); call BKCannotMove(nPos, bBKCannotMove); call WRAttacksBK(nPos, bBKAttacked); bMate = bLegalPositionBlackToMove && bBKCannotMove && bBKAttacked; }
Once the URSA specification is made, by merits of the URSA system, we can immediately get a representation of properties of the KRK endgame in the language of SAT – bitvectors are vectors of Boolean variables and each URSA procedure call generates a Boolean formula constraining the parameters.
Linear Integer Arithmetic (LIA)
Another possibility is to represent KRK positions and all relevant predicates using the language of linear integer arithmetic (LIA). The type then consists of integers , , , , , and , the Boolean , and the Boolean . We constructed such specification in terms of LIA within the Isabelle/HOL proof assistant. Here is an example definition.
Note that these definitions are very similar to the ones based on records and the option type, but they use only LIA constructs. Because of that, the Isabelle/HOL system can automatically transform such definitions to the SMTLIB input format and apply SMT solvers, which is the main method that we shall use for reasoning in Isabelle/HOL.
3.3 Chess Endgame Strategies
Given the representation of the chess (endgame) rules, endgame strategies can be represented. Without loss of generality, we can only consider strategies for the white player. We can think about a strategy as a function that maps a given position to a move i.e., to a position that is going to be reached after playing a strategy move. This function does not need to be total (for example, it need not be defined for positions that cannot be reached during the endgame). Sometimes a better choice could be to allow nondeterministic strategies and to model strategies by relations instead of functions. Namely, nondeterministic strategies can be underspecified and can have much simpler definitions than corresponding deterministic functions – relations should describe only those aspects that are necessary for correctness, while aspects related to efficiency could be omitted from the specification and postponed (see Section 5.1). Therefore, we have the following choices for the strategy definition.

A (nondeterministic) relation . There can be more than one position reachable by a strategy from a given position in one ply. The strategy must be legal i.e., it must give only legal moves:

A deterministicfunction ( denotes the option type, like in Isabelle/HOL). This function corresponds to one specific instance of the strategy and returns the (single) move that white following the strategy should play in the given position (or the special value , if the strategy is undefined for the given position).
If both the relation and the function are defined, then it is natural to require that they agree:
We also consider a nondeterministic function , defined as Note that given the implementation of , it can still be nontrivial to obtain an implementation of .
We will also consider the following relation:

is a relation such that holds whenever a position can be reached from the position by a legal move of black. Note that this is just a restriction of the relation on the set of positions in which black is on turn.
Since the play of black is not restricted, we can’t consider that would be analogous to .
Although we assume strategies on the general chess position type , it suffices to define them only on the endgame type (e.g., we consider the relation ). Every strategy definition on the type can naturally be lifted and yields a strategy on the type . Namely, given a strategy relation defined in the endgame terms, two positions and of the type are connected by the strategy relation defined in the general chess terms, i.e., if and only if both can be represented by the type i.e., if there are positions and of the type such that , and holds. If a strategy function is lifted, then it returns for all positions that cannot be represented by the type . Again, this is important for maintaining the link with the general chess game.
3.3.1 A Case Study of the Strategy for KRK
We have developed several implementations of the KRK endgame strategy described in Section 2.2.1, and then proved its correctness. Each implementation relies on some previously described KRK endgame representation.
Defining strategy conditions
For illustration, we show some auxiliary definitions that lead to the strategy definition. For example, in Isabelle/HOL the function that checks if a position can be reached from a position by an ImmediateMate move, is formalized as follows (assuming that auxiliary predicates and were previously defined).
Similarly, the RookHome condition is formalized as follows (the divide attempt requires that the white rook is in a file or rank next to the white king):
The corresponding definition in URSA is very similar^{12}^{12}12 The condition that the position is not stalemate makes one of small differences between the URSA and Isabelle/HOL specifications. In Isabelle/HOL, repeating the constraint on stalemate in conditions for all move kinds would give very large formulae, so in the definition of the strategy relation that condition is factored out and included only once, globally. On the other hand, URSA implements subformula sharing, so no significant overhead is incurred if a constraint is repeated several times.
procedure RookHomeCond(nPos1, nPos2, bRookHomeCond) { call LegalMoveWR(nPos1, nPos2, bLegalMoveWR); call DivideAttempt(nPos1, nPos2, bDivideAttempt); call BKNextWR(nPos2, bBKNextWR); call WKNextWR(nPos2, bWKNextWR); call Stalemate(nPos2, bStalemate); bRookHomeCond = bLegalMoveWR && bDivideAttempt && (!bBKNextWR  bWKNextWR) && !bStalemate; }
The corresponding definitions in C and LIA are also very similar.
Defining the strategy relation
The applied move must be the first one whose condition holds. Therefore, for each move we must have a function that checks if that move links the two given positions, and a function that checks if the strategy move is not applicable in a given position (notice that these two are not just opposites of each other). The latter requires to universally quantify over all possible moves of white pieces. In Isabelle/HOL, we introduce the function that for an index between 1 and 8, gives coordinates of 8 squares that surround the given central square . Similarly, the function for between 1 and 16 gives all squares that are in line with the rook (first horizontally, and then vertically). Combined, these give the enumeration of all possible moves of white (indices from 1 to 8 correspond to the king moves, and from 9 to 24 to the rook moves). We show this only for ImmediateMate in Isabelle/HOL, as other moves follow a similar pattern.
Since we want to have all our definitions executable and we want to deal only with quantifierfree SMT formulae, we must introduce bounded quantification (that is unfolded into a finite conjunction). Then we can define predicates that encode that a certain kind of move cannot be applied.
.  
8 ( . let = in  
16 ( . let = () in  
Note that the mating move can be performed only by the rook, and we have formally proved that in Isabelle/HOL, so the search for a mating move need not consider the moves of the king.
Since URSA, C and the quantifierfree fragment of LIA do not support quantifiers, conditions like the above are expressed by a finite conjunction or a loop.
Finally, we can introduce the relation , encoding that a position is reached from a position after a strategy move of a kind . We show only a fragment of the definition in Isabelle/HOL (the C, URSA and LIA definitions are very similar).
(if = then  
else  
if = then  
else  
…  
if = then  
else ) 
Note that this is our strategy relation , but it is parametrized by a move type (therefore, we can consider the relation , where is ImmediateMate, ReadyToMate, etc.).
Defining the strategy function
Although the strategy relation permits to play several different moves in each position, the ultimate goal is usually to reduce that to an executable function that calculates a single white player move for each position where it is on turn.
Defining deterministic strategy function requires a bit more effort. A function can iterate through all legal moves of white pieces until it finds a first move that satisfies the relational specification. An interesting exception is the Squeeze move. To make the strategy more efficient, the maximal Squeeze (the one that confines the black king the most) is always played (if there are several such moves, the first one found in the iterating process is used).
The strategy function definition in Isabelle/HOL uses several auxiliary functionals. The functional takes a position and a condition (a unary predicate formulated on the set of all positions), iterates through all possible moves of the white king (using the function ), and returns the index (a number between 1 and 8) of the first legal move (i.e., the move with the minimal index) that leads to a position that satisfies the given condition , or zero if there is no such move. The functionals and are defined similarly. For example, the value of the expression is the index of the first mating move by the white rook starting from the position , or zero if the black cannot be mated in one move. We also introduce the functional , that takes a position , a condition and a function that assigns penalty scores to positions. The functional returns the index of the move of the white rook (a number between 1 and 16) that leads into the position that has the minimal penalty score among all such positions that satisfy the given condition (if there is more than one such move, the first one i.e., the minimal index is returned).
Using these auxiliary functions, the strategy function is defined in Isabelle/HOL as follows.
" =  
(l  et i =  
in if i > 0 then ( (i+8), )  
else l  et i =  
in if i > 0 then ( i, )  
else l  et i = ( )  
in if i > 0 then ( (i+8), )  
... 
This definition always gives the Squeeze that maximally reduces the room.
In URSA, the function is implemented similarly. A loop trough all possible move indices is used to find the one that satisfies the current move condition.
4 Reasoning Methods
In this section we will describe several approaches for proving correctness of a given chess endgame strategy, i.e., for proving that the strategy for white is winning starting from any of relevant legal positions. We define that is a winning strategy for white on a set of positions with white on turn if all positions in are winning positions for white. A position is winning for white if each play starting from it terminates in a position where black is checkmated, given that white follows the strategy.^{13}^{13}13Note that every winning position is a winning position (assuming perfect play), but the opposite does not necessarily hold. More formally, winning positions can be defined inductively. (i) A position is winning, if white, following the strategy , immediately mates; (ii) A position is winning if each strategy move by white followed by any legal move of black leads into a winning position.
It is suitable, and sometimes even necessary to use computer support with chess rules and the strategy explicitly defined within a strict environment (proof assistant, theorem prover, constraint solving system, programming language etc.). Some of these proving approaches require that the implementation of the strategy is executable (i.e., that functions , , or are implemented and used). We shall assume that the reasoning will be performed on the endgame level, while the link to the general chess rules should be ensured as discussed previously. Two approaches can be used.
 Exhaustive retrograde analysis.

This approach assumes that the strategy is represented by a lookup table (endgame database) that assigns a strategy move to each relevant position. Then, using a retrograde procedure (in the style of Thompson’s work [29]), it is verified that the endgame lookup table ensures win for white. If the strategy is represented algorithmically (e.g., by the function ), then the strategy move for each position is computed and stored into the lookup table. This approach is straightforward, but it does not provide a highlevel, understandable and intuitive, argument on why the strategy really works.
 Highlevel conjectures.

Within this approach, correctness of the strategy relies on several conjectures (e.g., invariants for various strategy moves, termination conditions) which, when glued together, imply that the strategy is winning. Conjectures can be proved either by enumerating all possibilities or by some more sophisticated reasoning methods, either manually or by using computer support. In the latter case, the conjectures can be proved either formally, within a proof assistant, or informally checked using a general purpose programming language or a constraint solver.
4.1 Retrograde Analysis
In this section we present a retrogradestyle, enumerationbased procedure that can be used for showing correctness of a strategy^{14}^{14}14A slightly modified algorithm can be used for computing lookup table for optimal play, as Thompson did [29]..
Let denote a set of all initial positions for which we claim that every play (with white following the strategy) starting from them will terminate with black checkmated. Typically, we shall assume that equals the set defined in Section 3.2 as a set of all legal positions with only the relevant pieces on the board. Correctness of the strategy can be proved by showing that each position from is a winning positions.
WSwinning positions could be calculated by using a direct recursion, but it is much better to apply dynamic programming. For simplicity, we will assume that a deterministic strategy is given, and defined for all positions reachable from , and that functions , , and are executable. The set will contain positions determined to be winning. It will be initialized to all positions from which white following the strategy immediately mates, and those positions will be removed from the set . After that, the following is repeated. Among the remaining positions (which are not yet in the set ), the set is found, containing all positions such that: after a strategy move by white from to , it is not stalemate and all possible moves of black in lead to positions already in . These are also the winning positions and we transfer them from the set to the set . The process terminates if all positions are determined to be winning (in that case, the set of remaining positions is empty), or if there is no change made by the current iteration (in that case, the set is empty). This procedure can be implemented within a function :
function  
begin  
repeat  
until  
return  
end 
It can be easily proved that the strategy is winning strategy on the set iff the function returns true.
The procedure runs in a BFS fashion and positions are added to the set in increasing order of the number of plies needed to checkmate black. Hence, the procedure can also provide the longest possible game length, given that white follows the strategy.
Note that the analysis could be easily modified to use the nondeterministic definition of the strategy instead of the deterministic version .
Note that although we have defined the function in the general chess terms, it can be implemented in chessendgame terms.
4.1.1 A Case Study of the Strategy for KRK
Given the strategy implementation, it was rather straightforward to implement the above function in Isabelle/HOL and in C (the relevant part of the code was only around a hundred lines of code and took only half a day to write).
The retrograde analysis revealed some bugs in the initial implementation, and once they were fixed, confirmed that the strategy is correct. Therefore, this approach proved to be very suitable for rapid detection of bugs in the strategy implementation, without going into any deeper analysis of its properties.
There are 175 168 legal KRK positions with the three pieces on board and white on turn. It turns out that white always reaches win within 33 moves (i.e., within 65 plies). Due to the large number of positions and plies, this approach is hardly applicable without computer support. The check of correctness of the given KRK strategy using the C program is done in around 5s.^{15}^{15}15All running times are obtained on a cluster with 32 dual core 2GHz Intel Xeon processors with 2GB RAM per processor. All the tests were run sequentially, and no parallelism was employed. The URSA system was used with its default SAT solver – clasp (http://www.cs.unipotsdam.de/clasp/). Although the solving process is deterministic, the running times can vary to some extent (no more than 10%), but since the exact information on time spent is not critical, we kept the experiment simple and performed all measurements only once.
4.2 HighLevel Conjectures
Correctness of a strategy can be proved using a more abstract approach. The central statement can rely on a number of auxiliary, highlevel conjectures (lemmas) that combined together lead to the correctness arguments (that the strategy i.e., its counterpart is winning), but also provide insights into why the strategy really works. Such auxiliary conjectures can be proved in different ways. In the following we shall focus on the KRK strategy , but the method can be easily applied to other strategies.
Many properties of the strategy can be formulated by lemmas of the following form ( are positions with white on turn, are positions with black on turn, and are move types, e.g., ImmediateMate; the notation is just a shorthand for ):
The predicate denotes preconditions for . For example, it could express that a position is legal, or that all relevant pieces are on the board, but it could also give some additional constraints (for example, that the white king is closer to the white rook than the black king).
The predicate denotes a sequence of strategy moves of white followed by legal moves of black. Again, is just a shorthand notation:
Recall that the parameter in the relation denotes the type of the move played (e.g., denotes that there is an immediate mate in position , leading to the position ). Predicates additionally constrain the strategy move types played by white (e.g., some can require that belongs or does not belong to some set of move types).
Finally, is just a shorthand for a postcondition that relates all positions and move types encountered during such a sequence of moves, i.e.,
Comments
There are no comments yet.