Description

Configuration

Options

• maximumPlies Int: the optional maximum number of plies (half moves) before the game is terminated.
• randomSeed Int: optionally seed the pseudo-random number-generator to produce a repeatable game. See "--randomSeed" in section-1 of the man-pages.

Evaluation-options

• incrementalEvaluation Bool, defaulting to "True". Whether to incrementally generate position-hashes & evaluate the piece-square value, from the previous values; otherwise these quantities are evaluated from scratch. This option slightly reduces memory-requirement, but doesn’t affect the result.
• rankValues: defines the value within the closed unit interval "[0, 1]", of each type of piece, defaulting (ref. https://chessprogramming.wikispaces.com/Point+Value) to:

  Piece	Value
  =====	=====
  Rook	0.525
  Knight	0.35
  Bishop	0.35
  Queen	1
  King	Moot, since it can’t be taken.

• criteriaWeights: the weights in the closed unit-interval "[0,1]", each associated with a criterion used to evaluate a move; at the lower bound, the corresponding criterion is not even evaluated. The criteria to which these weights correspond, are:

  Criterion	Metric	Ref	Notes
  =========	======	===	=====
  material	Quantifies the value of the pieces remaining per side.	https://chessprogramming.wikispaces.com/Material	This is dependent on the value of each type of piece; see "rankValues".
  mobility	The difference between the number of moves available per side.	https://chessprogramming.wikispaces.com/Mobility	Actually the reciprocal is measured, to emphasis the reduction caused by checking one’s opponent.
  pieceSquareValue	Quantifies the position held by the pieces per side.	https://chessprogramming.wikispaces.com/Piece-Square+Tables	This metric includes aspects of both "material" & "mobility". The value can be made linearly dependent on progress through the game.
  castlingPotential	Whether each player has been permanently prevented from castling.		Reflects the disadvantage of moving one’s King, thus preventing subsequent castling.
  defence	The difference between the number of pieces defending one’s own, per side.		There’s neither any penalty for gaps in this defence nor account made of the value of the defended piece; it’s just the total number of defenders.
  doubledPawns	The difference between the total number of doubled Pawns per side.	https://chessprogramming.wikispaces.com/Doubled+Pawn	Reflects the reduced mobility of such Pawns.
  isolatedPawns	The difference between the total number of isolated Pawns per side.	https://chessprogramming.wikispaces.com/Isolated+Pawn	Reflects the lack of defence from adjacent Pawns.
  passedPawns	The difference between the total number of passed Pawns per side.	https://chessprogramming.wikispaces.com/Passed+Pawn	Reflects improved promotion-prospects.

  Other criteria could be measured, but orthogonality is problematic.
  One could reasonably argue that most of these criteria are ultimately reflected in "material", but often they quantify some strategic advantage which manifests further into the future than it is feasible to predict the likely exchange of pieces.
  N.B.: "defence" & the three Pawn-related criteria typically can’t justify their existence; even if one ignores the time required to calculate them, their value is dubious. This is the nub of the esoteric choice of whether to accurately quantify each board, or to accept a vague quantification in order to explore deeper in the same time.
• pieceSquareTables: defines the value within the closed unit interval "[0, 1]", of each type of piece occupying every square.
  N.B.: the values defined for a Pawn occupying any square in the first or last rank, are irrelevant.
  Values are defined for just the White pieces, which are then used to generate by reflection, those for the Black pieces.
  Values are optionally defined for just the left-hand side of the board, which are then used to generate by reflection, the right-hand side.
  For each type of piece, the values are defined in a SAN-coordinate-order list, rastering over the board from left to right, bottom to top; "a1 b1 c1 d1 a2 b2 c3 ... c7 d8".
  For each type of piece, an alternative definition may be provided for use during the end-game, to account for the different criteria relevant to that phase of the game. Under such circumstances, the two piece-square tables for that type of piece will be interpolated between, according to the number of pieces remaining (which is used to measure progress towards the end-game). The packaged configuration-files define modified tables for both Pawn & King.

Search-options

• preferMovesTowardsCentre: whether to sort the moves available from any position, using the magnitude of their progress towards the centre of the board.
• sortOnStandardOpeningMoveFrequency: whether to sort the moves available from any position, using the frequency with which they occur in referenced standard openings. This is performed after preferMovesTowardsCentre, but since the sort-algorithms are stable, i.e. they don’t affect the order of those moves which compare equal, they can usefully be sequentially applied.
• captureMoveSortAlgorithm: the optional algorithm by which to partition & sort capture-moves for preferential evaluation when searching for the optimum amongst available moves. If unspecified, the order of capture-moves will remain unaltered both wrt each other & wrt other moves.
  

  Value	Meaning
  =====	=======
  MVVLVA	moves are advanced depending on the value of rank of the piece they capture, but where this is equal, those which achieve this using a less valuable piece are preferred; https://chessprogramming.wikispaces.com/MVV-LVA . This is highly effective.
  SEE	moves are advanced depending on the net material gain resulting from any battle at the destination; https://chessprogramming.wikispaces.com/Static+Exchange+Evaluation . This is not currently competitive.

  Neither of these sort-algorithms affects the relative order of non-capture moves; cf. preferMovesTowardsCentre & sortOnStandardOpeningMoveFrequency.
  This is performed after sortOnStandardOpeningMoveFrequency.
• minimumHammingDistance Int: the optional positive lower bound on the Hamming-distance between any of the random numbers used to generate Zobrist hashes from positions; https://chessprogramming.wikispaces.com/Zobrist+Hashing .
  CAVEAT: linear independence of the bit-vectors is a better measure than Hamming-distance, of the quality of the selected random numbers.
• retireKillerMovesAfter Int: the optional non-negative number of full moves (one by each player) after which killer-moves are retired; https://chessprogramming.wikispaces.com/Killer+Move . If unspecified, killer-moves won’t even be recorded.
  N.B.: this is highly effective up to about 3, beyond which returns diminish.
  Killer-moves are used to dynamically sort the moves available from a position, based on whether similar moves previously triggered beta-cutoff; https://chessprogramming.wikispaces.com/Beta-Cutoff .
• trapRepeatedPositions: whether to short-circuit the fitness-evaluation of positions which have been visited before in the current game; https://chessprogramming.wikispaces.com/Repetitions . These situations result from loops of consecutive reversible moves, in the move-tree which defines the game of chess. The fitness of such positions can be derived by induction, since were one to search from this position, one would ultimately arrive back another time, so the fitness of this future position equals the current fitness.
  N.B.: this doesn’t typically improve performance in either space or time.
• usePondering: whether an automated player should plan their next move, based on a prediction of the opponent’s response, & thus make use their opponent’s thinking-time; https://chessprogramming.wikispaces.com/Pondering .
• transpositions: these can be used to reorder the evaluation of moves, based on the results previously found for identical positions in sibling games reached by an alternative sequence of arbitrary moves; https://chessprogramming.wikispaces.com/Transposition .

  Value	Type	Meaning
  =====	====	=======
  retireTranspositionsAfter	Int	the non-negative number of full moves (one by each player) after which transpositions are retired. N.B.: this is highly effective at about 1, beyond which returns diminish.
  minimumTranspositionSearchDepth	Int	the search-depth beneath which transpositions are not recorded. When the remaining search-depth is low, the potential gain from finding a recorded transposition of the current position, doesn’t justify the effort. N.B.: this is most effective at about 2.

• standardOpeningOptions

  Field	Type	Default	Meaning
  =========	====	=======	=======
  tryToMatchMoves	Bool	True	whether to attempt to exactly match the moves already made, with a standard opening; i.e. without matching transpositions.
  tryToMatchViaJoiningMove	Bool	True	whether to attempt to join the current position (irrespective of the means by which it was achieved) to a standard opening that’s only one move away.
  tryToMatchColourFlippedPosition	Bool	True	whether to attempt to match a colour-flipped (https://chessprogramming.wikispaces.com/Color+Flipping) version of the current position with a standard opening.

• searchDepth Int, defaulting to "4" (minimum "1"): the number of plies (half moves) to search ahead, when selecting the next move. This is defined for each of zero, one or two logical colours, corresponding to the players; it is the absence of any specification, from which the application infers manual move-selection. This value can be changed dynamically, see "set searchDepth" in section-1 of the man-pages.
  CAVEAT: the space & time complexity of the application are exponentially related to this quantity.

IO-options

• maximumPGNNames Int: the optional maximum number of names, with which to annotate moves matching games from the configured PGN-databases.
• pgnOptions: these options allow one to reference PGN-databases, which the application can leverage during move-selection; https://en.wikipedia.org/wiki/Portable_Game_Notation .

  Field	Type	Default	Meaning
  =========	====	=======	=======
  databaseFilePath	File-path		The path in the local file-system, to a PGN-database.
  minimumPlies	Int	1	The minimum number of half moves, for an archived game to be considered valuable.
  isStrictlySequential	(True|False)	True	Whether the recorded move-numbers are accurate.
  validateMoves	(True|False)	False	Whether to validate all the moves. In the absence of validation, PGN-databases can be read faster, but the consequence of reading invalid moves is unpredictable. This option is required to read games which continued after a draw can be inferred.
  identificationTags	String		The PGN-field(s) from which to construct a composite identifier for a game.

• persistence: these options govern how the application persists its state, so that a game may span multiple sessions.

  Field	Type	Default	Meaning
  =========	====	=======	=======
  filePath	File-path		The local file in which game-state will be persisted.
  automatic	(True|False)	True	Whether the game-state is automatically saved.

"ioOptions" has a sub-section "uiOptions", which defines the user-interface.

• moveNotation (Coordinate|ICCFNumeric|Smith), defaulting to "Smith"; https://en.wikipedia.org/wiki/Chess_notation . The expected syntax used to define a move. This application also understands Standard Algebraic notation, but it is only used to read the PGN-databases used to define standard openings.
• printMoveTree Int. Print the tree of all possible moves in the configured notation, truncated to the specified depth. The forest of moves available at each node, is sequentially sorted according to; preferMovesTowardsCentre, sortOnStandardOpeningMoveFrequency, captureMoveSortAlgorithm; since the sort-algorithm is stable, the relative order of moves which compare equal, remains unchanged. The fitness of each move, from the perspective of the player of the move, is also printed to the configured number of decimal places; see nDecimalDigits. See "--printMoveTree" in section-1 of the man-pages.
• nDecimalDigits Int, defaulting to "3". Defines the precision with which fractional ancillary data is displayed.
• verbosity (Silent|Normal|Verbose|Deafening), defaulting to "Normal": defines the quantity of ancillary output required. See "--verbosity" in section-1 on the man-pages.
• boardMagnification: the size-multiplier used when rendering the board.

  Field	Type	Meaning
  =========	=======	=======
  nColumns	Int	The horizontal magnification of the board-image.

• colourScheme: defines the physical colour of each component of the display.

  Field	Options
  =========	=======
  axisLabelColour	(Black|Red|Green|Yellow|Blue|Magenta|Cyan|White)
  darkPieceColour	(Black|Red|Green|Blue|Magenta|Cyan)
  lightPieceColour	(Red|Green|Yellow|Magenta|Cyan|White)
  darkSquareColour	(Black|Red|Green|Blue|Magenta|Cyan)
  lightSquareColour	(Red|Green|Yellow|Magenta|Cyan|White)
  menuLabelColour	(Black|Red|Green|Yellow|Blue|Magenta|Cyan|White)
  menuBackgroundColour	(Black|Red|Green|Yellow|Blue|Magenta|Cyan|White)

Files

Author

Copyright

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/ .

Table of Contents

• Description
• Configuration
• Options
• Evaluation-options
• Search-options
• IO-options
• Files
• Author
• Copyright