NAME

Chess::PGN::EPD - Perl extension to produce and manipulate EPD text.

SYNOPSIS

CODE examples

THIS

 #!/usr/bin/perl
 #
 #
 use warnings;
 use strict;
 use Chess::PGN::Parse;
 use Chess::PGN::EPD;
 
 if ($ARGV[0]) {
     my $pgn = new Chess::PGN::Parse($ARGV[0]) or die "Can't open $ARGV[0]: $!\n";
     while ($pgn->read_game()) {
         $pgn->parse_game();
         print join ( "\n", epdlist(  @{$pgn->moves()} ) ), "\n\n";
     }
 }

OR

 #!/usr/bin/perl
 #
 #
 use warnings;
 use strict;
 use Chess::PGN::EPD;

 my $position = 'rnbqkb1r/ppp1pppp/5n2/3P4/8/8/PPPP1PPP/RNBQKBNR w KQkq -';
 print join("\n",epdstr(epd => $position,type => 'latex'));

OR

 #!/usr/bin/perl
 #
 #
 use strict;
 use warnings;
 use Chess::PGN::Parse;
 use Chess::PGN::EPD;
 
 if ($ARGV[0]) {
     my $pgn = new Chess::PGN::Parse($ARGV[0]) or die "Can't open $ARGV[0]: $!\n";
     while ($pgn->read_game()) {
         my @epd;
 
         $pgn->parse_game();
         my @moves = @{ $game{'GameMoves'} };
         print join("\n",epdTaxonomy(moves => \@moves,all => 1,astags => 1)),"\n";
     }
 }

DESCRIPTION

epdcode(code,epdlistref)

Determines the requested code given a list of epd strings in reverse order. Allowed codes are:

'ECO' from The Encyclopedia of Chess Openings.
'NIC' from New in Chess.
'Opening' Traditional Opening name in English.

At the moment, this routine depends on three Storable files installed along with the module. On demand other database formats may be implemented. The 'ToDo' list also mentions the possibility of extending the databases, although that might come in the form of a 'How To' rather than any code solution. NOTE: This routine is deprecated in favor of epdTaxonomy and will at some point be removed.

epdfromto(movelist)

Returns an array of hashes that contain move information. Useful for conversions to other forms of notation; i.e. telegraphic or english notation.

epdgetboard([epd])

Provides access to the 'board' with the current epd postition set up. If given an EPD string, set board accordingly. The returned values are:

$w - boolean, white to move?
$Kc - boolean, has white castled king side?
$Qc - boolean, has white castled queen side?
$kc - boolean, has black castled king side?
$qc - boolean, has black castled queen side?
%board - hash board, keys are algebraic square names, values are occupying piece.

epdlist(movelist)

Returns an array of strings that represent the conversion of game text into positional shorthand, one entry for each move made in the game.

Concepts

EPD

"Extended Position Description" is a standard for describing chess positions along with an extended set of structured attribute values using the ASCII character set. It is intended for data and command interchange among chessplaying programs. It is also intended for the representation of portable opening library repositories.

A single EPD uses one text line of variable length composed of four data field followed by zero or more operations. The four fields of the EPD specification are the same as the first four fields of the FEN specification.

A text file composed exclusively of EPD data records should have a file name with the suffix ".epd".

EPD is based in part on the earlier FEN standard; it has added extensions for use with opening library preparation and also for general data and command interchange among advanced chess programs. EPD was developed by John Stanback and Steven Edwards; its first implementation is in Stanback's master strength chessplaying program Zarkov.

Like FEN, EPD can also be used for general position description. However, unlike FEN, EPD is designed to be expandable by the addition of new operations that provide new functionality as needs arise.

FEN

"Forsyth-Edwards Notation" is a standard for describing chess positions using the ASCII character set.

A single FEN record uses one text line of variable length composed of six data fields. The first four fields of the FEN specification are the same as the first four fields of the EPD specification.

A text file composed exclusively of FEN data records should have a file name with the suffix ".fen".

History

FEN is based on a 19th century standard for position recording designed by the Scotsman David Forsyth, a newspaper journalist. The original Forsyth standard has been slightly extended for use with chess software by Steven Edwards with assistance from commentators on the Internet.

Uses for a position notation

Having a standard position notation is particularly important for chess programmers as it allows them to share position databases. For example, there exist standard position notation databases with many of the classical benchmark tests for chessplaying programs, and by using a common position notation format many hours of tedious data entry can be saved. Additionally, a position notation can be useful for page layout programs and for confirming position status for e-mail competition.

Data fields

FEN specifies the piece placement, the active color, the castling availability, the en passant target square, the halfmove clock, and the fullmove number. These can all fit on a single text line in an easily read format. The length of a FEN position description varies somewhat according to the position. In some cases, the description could be eighty or more characters in length and so may not fit conveniently on some displays. However, these positions aren't too common.

A FEN description has six fields. Each field is composed only of non-blank printing ASCII characters. Adjacent fields are separated by a single ASCII space character.

Piece placement data

The first field represents the placement of the pieces on the board. The board contents are specified starting with the eighth rank and ending with the first rank. For each rank, the squares are specified from file a to file h. White pieces are identified by uppercase SAN piece letters ("PNBRQK") and black pieces are identified by lowercase SAN piece letters ("pnbrqk"). Empty squares are represented by the digits one through eight; the digit used represents the count of contiguous empty squares along a rank. A solidus character "/" is used to separate data of adjacent ranks.

Active color

The second field represents the active color. A lower case "w" is used if White is to move; a lower case "b" is used if Black is the active player.

Castling availability

The third field represents castling availability. This indicates potential future castling that may of may not be possible at the moment due to blocking pieces or enemy attacks. If there is no castling availability for either side, the single character symbol "-" is used. Otherwise, a combination of from one to four characters are present. If White has kingside castling availability, the uppercase letter "K" appears. If White has queenside castling availability, the uppercase letter "Q" appears. If Black has kingside castling availability, the lowercase letter "k" appears. If Black has queenside castling availability, then the lowercase letter "q" appears. Those letters which appear will be ordered first uppercase before lowercase and second kingside before queenside. There is no white space between the letters.

En passant target square

The fourth field is the en passant target square. If there is no en passant target square then the single character symbol "-" appears. If there is an en passant target square then is represented by a lowercase file character immediately followed by a rank digit. Obviously, the rank digit will be "3" following a white pawn double advance (Black is the active color) or else be the digit "6" after a black pawn double advance (White being the active color).

An en passant target square is given if and only if the last move was a pawn advance of two squares. Therefore, an en passant target square field may have a square name even if there is no pawn of the opposing side that may immediately execute the en passant capture.

Halfmove clock

The fifth field is a nonnegative integer representing the halfmove clock. This number is the count of halfmoves (or ply) since the last pawn advance or capturing move. This value is used for the fifty move draw rule.

Fullmove number

The sixth and last field is a positive integer that gives the fullmove number. This will have the value "1" for the first move of a game for both White and Black. It is incremented by one immediately after each move by Black.

Examples

Here's the FEN for the starting position:

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1

And after the move 1. e4:

rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq e3 0 1

And then after 1. ... c5:

rnbqkbnr/pp1ppppp/8/2p5/4P3/8/PPPP1PPP/RNBQKBNR w KQkq c6 0 2

And then after 2. Nf3:

rnbqkbnr/pp1ppppp/8/2p5/4P3/5N2/PPPP1PPP/RNBQKB1R b KQkq - 1 2

For two kings on their home squares and a white pawn on e2 (White to move) with thirty eight full moves played with five halfmoves since the last pawn move or capture:

4k3/8/8/8/8/8/4P3/4K3 w - - 5 39

NOTE

With only a little observation, the astute user will notice that actually this function doesn't return either EPD or FEN, but rather a bit of both. It is mostly FEN, but it lacks the Fullmove number field, since for most usage that information is available else where or can easily be reconstructed. As to why the module is called EPD, well I figured since it wasn't one and it wasn't the other, that left it up to me to choose--besides, who would want a module named after a swamp?!

epdset(epd)

For those instances where the game in question does not begin with a complete move list, this function allows the user to set the starting position using a 'EPD' string as described elsewhere in the document.

epdstr(epd|board,type [border,corner,legend])

Returns an array of strings that represent a diagramatic conversion of the specified epd string or board postion to the specified type. Parameters are passed as a anonymous hash, i.e. epdstr(epd => $position,type => 'diagram') or similar.

Types Supported

The following types are understood by epdstr:

'diagram'

A plain ASCII diagram with simple border showing rank and file. Typical output:

 8  rnbqkb r
 7  ppp pppp
 6   - - n -
 5  - -P- - 
 4   - - - -
 3  - - - - 
 2  PPPP PPP
 1  RNBQKBNR
    abcdefgh
'text'

A plain ASCII diagram. Typical output:

 rnbqkb r
 ppp pppp
  - - n -
 - -P- - 
  - - - -
 - - - - 
 PPPP PPP
 RNBQKBNR
'palview'

An array of HTML information that represents the tabular diagram information for PalView. Typical output:

<IMG SRC="jpc/br.gif"><IMG SRC="jpc/bn.gif"><IMG SRC="jpc/bb.gif"><IMG SRC="jpc/bq.gif"><IMG SRC="jpc/bk.gif"><IMG SRC="jpc/bb.gif"><IMG SRC="jpc/bn.gif"><IMG SRC="jpc/br.gif"><BR> <IMG SRC="jpc/bp.gif"><IMG SRC="jpc/bp.gif"><IMG SRC="jpc/bp.gif"><IMG SRC="jpc/bp.gif"><IMG SRC="jpc/bp.gif"><IMG SRC="jpc/bp.gif"><IMG SRC="jpc/bp.gif"><IMG SRC="jpc/bp.gif"><BR> <IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><BR> <IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><BR> <IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><BR> <IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/wn.gif"><BR> <IMG SRC="jpc/wp.gif"><IMG SRC="jpc/wp.gif"><IMG SRC="jpc/wp.gif"><IMG SRC="jpc/wp.gif"><IMG SRC="jpc/wp.gif"><IMG SRC="jpc/wp.gif"><IMG SRC="jpc/wp.gif"><IMG SRC="jpc/wp.gif"><BR> <IMG SRC="jpc/wr.gif"><IMG SRC="jpc/wn.gif"><IMG SRC="jpc/wb.gif"><IMG SRC="jpc/wq.gif"><IMG SRC="jpc/wk.gif"><IMG SRC="jpc/wb.gif"><IMG SRC="jpc/i.gif"><IMG SRC="jpc/wr.gif"><BR>

'latex'

The necessary text fragment to 'set' the diagram in LaTeX using any variation of Piet Tutelars original chess12.tar.Z package. As given, the LaTeX command 'diagram' is used. As an example here is the source to test.tex:

 %%
 %% test.tex -- example LaTeX file to demonstrate output from Chess::PGN::EPD
 %%
 \documentclass{article}
 \usepackage{chess}
 \usepackage{bdfchess}
 \begin{document}
 \newenvironment{diagram}{\begin{nochess}}{$$\showboardwithnotation$$\end{nochess}}
 %%
 %% fragment as produced by epdstr(epd => $position,type => 'latex');
 %%
 \begin{diagram}
 \board
 {rnbqkb r}
 {ppp pppp}
 { * * n *}
 {* *P* * }
 { * * * *}
 {* * * * }
 {PPPP PPP}
 {RNBQKBNR}
 \end{diagram}
 %%
 %% end of fragment
 %%
 \end{document}
'linares'

Alpine Electronics' LinaresDiagram font. Mapping also works with both HastingsDiagram and ZurichDiagram fonts. Single or double border, With or without algebraic legend.

'linares1'

Standard mapping, single border, squares offset.

'linares2'

Standard mapping, thick single border.

'tilburg'

A borderless font designed by Eric Schiller and Bill Cone.

'marroquin'

This type refers to any font designed by Armando H. Marroquin, excepting his FigurineSymbol fonts. They having a different purpose, have a different mapping.

'leschemelle'

The map for Chess Cases designed by Matthieu Leschemelle.

'bentzen1'

The map for Chess Alpha designed by Eric Bentzen.

'bentzen2'

The map for Chess Berlin designed by Eric Bentzen.

'hickey'

The map for Chess Plain designed by Alan Hickey.

'scott1'

The map for Chess Regular a port of Adobe Cheq ported to True Type by Alistair Scott.

'scott2'

The map for Chess Usual a modification of Chess Regular by Armando H. Marroquin.

'bodlaender'

The map for Chess Utrecht designed by Hans Bodlaender.

'cowderoy'

The map for Traveller Standard v3 designed by Alan Cowderoy.

Note that 'type' is not case sensative so that 'latex' and 'LaTeX' will both work equally well.

Fonts Supported

List with font name, font author, and type name:

Chess Cases -- Matthieu Leschemelle -- leschemelle
Chess Adventurer -- Armando H. Marroquin -- marroquin
Chess Alfonso-X -- Armando H. Marroquin -- marroquin
Chess Alpha -- Eric Bentzen -- bentzen1
Chess Berlin -- Eric Bentzen -- bentzen2
Chess Condal -- Armando H. Marroquin -- marroquin
Chess Harlequin -- Armando H. Marroquin -- marroquin
Chess Kingdom -- Armando H. Marroquin -- marroquin
Chess Leipzig -- Armando H. Marroquin -- marroquin
Chess Line -- Armando H. Marroquin -- marroquin
Chess Lucena -- Armando H. Marroquin -- marroquin
Chess Magnetic -- Armando H. Marroquin -- marroquin
Chess Mark -- Armando H. Marroquin -- marroquin
Chess Marroquin -- Armando H. Marroquin -- marroquin
Chess Maya -- Armando H. Marroquin -- marroquin
Chess Mediaeval -- Armando H. Marroquin -- marroquin
Chess Mérida -- Armando H. Marroquin -- marroquin
Chess Millennia -- Armando H. Marroquin -- marroquin
Chess Miscel -- Armando H. Marroquin -- marroquin
Chess Montreal -- Gary Katch -- katch
Chess Motif -- Armando H. Marroquin -- marroquin
Chess Plain -- Alan Hickey -- hickey
Chess Regular -- Alistair Scott -- scott1
Chess Usual -- Armando H. Marroquin -- scott2
Chess Utrecht -- Hans Bodlaender -- bodlaender
Tilburg -- Eric Schiller and Bill Cone -- tilburg
Traveller Standard v3 -- Alan Cowderoy -- cowderoy

These are available at http://www.enpassant.dk/chess/fonteng.htm along with a good deal of useful information on chess desktop publishing.

Font Designers Supported

Eric Bentzen
Bill Cone
Alan Cowderoy
Alan Hickey
Gary Katch
Armondo H. Marroquin
Eric Schiller
Alastair Scott
Steve Smith
Piet Tutelaers

Borders and Such Like

Some fonts, for example those designed by Armondo H. Marroquin support a variety of border styles and decorations. The border may be single or double, with square corners or rounded, and with an algebraic legend. These effects are supported by the addition of the necessary parameters to the allowed parameter list. In particular:

  • Border, values can be either 'single' or 'double' (default is 'single')

  • Corner, values can be either 'square' or 'rounded' (default is 'square')

  • Legend, values can be either 'yes' or 'no' (default is 'no')

Again, letter case is not particularly important, 'yes' works as well as 'Yes' etc. As for those fonts that don't support a particular feature, epdstr will fail silently, that is, the parameter will be ignored and processing will continue as though no such request had been made.

epdTaxonomy(options)

At one point the following was required in order to properly 'tag' a PGN file with opening names and information:

 if ($ARGV[0]) {
     my $pgn = new Chess::PGN::Parse($ARGV[0]) or die "Can't open $ARGV[0]: $!\n";
     while ($pgn->read_game()) {
         my @epd;
 
         $pgn->parse_game();
         @epd = reverse epdlist( @{$pgn->moves()} );
         print '[ECO,"',epdcode('ECO',\@epd),"\"]\n";
         print '[NIC,"',epdcode('NIC',\@epd),"\"]\n";
         print '[Opening,"',epdcode('Opening',\@epd),"\"]\n";
     }
 }

Not all that bad, but not all that clear either. As can be seen from the examples shown at the begining of this documentation, I've created a new subroutine called epdTaxonomy that replaces all of the above with:

 if ($ARGV[0]) {
     my $pgn = new Chess::PGN::Parse($ARGV[0]) or die "Can't open $ARGV[0]: $!\n";
     while ($pgn->read_game()) {
         my @epd;
 
         $pgn->parse_game();
         my @moves = @{ $game{'GameMoves'} };
         print join("\n",epdTaxonomy(moves => \@moves,all => 1,astags => 1)),"\n";
     }
 }

Clearly a win for the parsimonious team! This sub takes a single parameter, a hash with the following possibilities:

'moves' -- required in order to have something to work with.
'all' -- if true, create all three tags supported.
'astags' -- if true, create complete PGN header tags for the specified codes.
'eco' -- create tag information for ECO codes.
'nic' -- create tag information for NIC codes.
'opening' -- create tag information for Opening codes.

See the description of epdcode for brief descriptions of what these codes represent.

psquares(piece,board)

Given a 'piece' (single character, uppercase for white, lowercase for black, KQRBNPkqrbnp) and the current board hash, return a list of square names (algebraic) locating instances of the piece.

EXPORT

epdcode - given a list of EPD strings, return the requested code or 'unknown'.
epdfromto - given a list of moves, return an array of hashes which contain move information.
epdlist - given a list of moves, return a list of EPD strings.
epdset - allows the user to specifiy an initial position.
epdstr - given an EPD string or a board, convert it to the specified string representation.
epdTaxonomy - one stop shopping for conversion of epd array to ECO, NIC and opening tag information.
psquares - given the piece and the board, generate and return a list of squares occupied by that type of piece.

DEPENDENCIES

Chess::PGN::Moves => 0.04
Chess::PGN::Parse => 0.19
Test::More => 0.94
Text::CSV => 1.18
Storable => 2.21
Cwd => 3.31
File::Spec::Functions => 3.3

TODO

Continue to improve documentation.
oo-ify support variables.
Allow font map customization.
Solve the english to algebraic problem.

KNOWN BUGS

None known; Unknown? Of course, though I try to be neat...

AUTHOR

Hugh S. Myers

Always: hsmyers@gmail.com

1 POD Error

The following errors were encountered while parsing the POD:

Around line 1704:

Non-ASCII character seen before =encoding in 'Mérida'. Assuming ISO8859-1