Table of Contents
This man-page describes the configuration of the application;
its invocation is described in section-1 of the man-pages.
is read from an XML-file referenced from the command-line. The grammar of
this file is defined in "config/bishbosh.dtd" or more precisely using RELAX
NG in "config/bishbosh.rng", whereas the semantics of the more important
fields is described below.
field governs automatic move-evaluation:
- 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.
- 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)
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:
the value of the pieces remaining per side.||https://chessprogramming.wikispaces.com/Material
is dependent on the value of each type of piece; see "rankValues".|
difference between the number of moves available per side.||https://chessprogramming.wikispaces.com/Mobility
the reciprocal is measured, to emphasis the reduction caused by checking
|pieceSquareValue||Quantifies the position held by the pieces
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.|
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.|
between the total number of doubled Pawns per side.||https://chessprogramming.wikispaces.com/Doubled+Pawn
the reduced mobility of such Pawns.|
|isolatedPawns||The difference between the
total number of isolated Pawns per side.||https://chessprogramming.wikispaces.com/Isolated+Pawn
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
- Other criteria could be measured, but orthogonality
- 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.
The application defines a set of "ioOptions",
in which one can define:
- 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.
- Neither of these sort-algorithms affects
the relative order of non-capture moves; cf. preferMovesTowardsCentre & sortOnStandardOpeningMoveFrequency.
- This is performed after sortOnStandardOpeningMoveFrequency.
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.
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.
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;
- 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
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.|
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.|
to attempt to exactly match the moves already made, with a standard opening;
i.e. without matching transpositions.|
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.|
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.
- maximumPGNNames Int: the optional maximum number
of names, with which to annotate moves matching games from the configured
- 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
path in the local file-system, to a PGN-database.|
number of half moves, for an archived game to be considered valuable.|
the recorded move-numbers are accurate.|
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
|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.
file in which game-state will be persisted.|
the game-state is automatically saved.|
"ioOptions" has a sub-section "uiOptions",
which defines the user-interface.
Written by Dr. Alistair Ward.
Copyright © 2018 Dr.
- moveNotation (Coordinate|ICCFNumeric|Smith),
defaulting to "Smith"; https://en.wikipedia.org/wiki/Chess_notation
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
- 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.
horizontal magnification of the board-image.|
- colourScheme: defines the physical
colour of each component of the display.
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,
Table of Contents