aboutsummaryrefslogtreecommitdiff
path: root/doc/tex
diff options
context:
space:
mode:
Diffstat (limited to 'doc/tex')
-rw-r--r--doc/tex/biber.bib18
-rw-r--r--doc/tex/implementation.tex140
-rw-r--r--doc/tex/systemDesign.tex93
-rw-r--r--doc/tex/tfg.tex10
4 files changed, 169 insertions, 92 deletions
diff --git a/doc/tex/biber.bib b/doc/tex/biber.bib
index f22e058..8884962 100644
--- a/doc/tex/biber.bib
+++ b/doc/tex/biber.bib
@@ -109,8 +109,26 @@
url = {http://www.dabeaz.com/ply}
}
+@online{vim,
+ title = {welcome home : vim online},
+ urldate = {2022},
+ url = {https://www.vim.org}
+}
+
@online{neovim,
title = {Home - Neovim},
urldate = {2022},
url = {http://neovim.io}
}
+
+@online{latex,
+ title = {LaTeX - A document preparation system},
+ urldate = {2022},
+ url = {https://www.latex-project.org}
+}
+
+@online{puml,
+ title = {Open-source tool that uses simple textual descriptions to draw beautiful UML diagrams.},
+ urldate = {2022},
+ url = {https://plantuml.com}
+}
diff --git a/doc/tex/implementation.tex b/doc/tex/implementation.tex
index 40dfb93..f88d57f 100644
--- a/doc/tex/implementation.tex
+++ b/doc/tex/implementation.tex
@@ -22,20 +22,20 @@ layouts.
\paragraph{NumPy\cite{numpy}}
-NumPy is a scientific package for python providing a lot of mathematical tools.
-The most interesting for this project are its capabilities to create and
-transform matrices.
+A scientific package for python providing a lot of mathematical tools. The most
+interesting for this project are its capabilities to create and transform
+matrices.
\paragraph{Matplotlib\cite{matplotlib}}
-Matplotlib is a python library for creating graphs and other visualizations. It
-is used to show the likelihood of moves the neural networks of the project
-create from a board configuration.
+A python library for creating graphs and other visualizations. It is used to
+show the likelihood of moves the neural networks of the project create from a
+board configuration.
\paragraph{PLY\cite{ply}}
-PLY is a tool for generating compilers in Python. It is an implementation of the
-lex and yacc utilities, allowing to create lexers and parsers. It is used in the
+A tool for generating compilers in Python. It is an implementation of the lex
+and yacc utilities, allowing to create lexers and parsers. It is used in the
project to create the SGF parser which transform SGF files to internal
representations of Go matches.
@@ -44,103 +44,61 @@ representations of Go matches.
These are some utility libraries commonly used for frequent programming tasks:
\begin{itemize}
- \item \textbf{sys}, to stop the execution of the program or access system info such
+ \item \textbf{sys}: to stop the execution of the program or access system info such
as primitives maximum values.
- \item \textbf{os}, to interact with files.
- \item \textbf{re}, to check strings with regular expressions.
- \item \textbf{random}, to get random values, for example to obtain a random
+ \item \textbf{os}: to interact with files.
+ \item \textbf{re}: to check strings with regular expressions.
+ \item \textbf{random}: to get random values, for example to obtain a random
item from a list.
- \item \textbf{copy}, to obtain deep copies of multidimensional arrays.
+ \item \textbf{copy}: to obtain deep copies of multidimensional arrays.
\end{itemize}
\subsubsection{Development tools}
\paragraph{Neovim\cite{neovim}}
-\begin{itemize}
+A text editor based on Vim\cite{vim}, providing its same functionality with
+useful additions and defaults for modern computers and terminal emulators. With
+some extensions and configuration it can become a powerful development
+environment with a very fluid usage experience. That, and the fact that the
+developer considers Vim's modal editing the best writing experience possible on
+a computer, have made Neovim the editor of choice.
- \item Extensions
+\begin{itemize}
+ %TODO: Write about neovim extensions
+ \item FZF
\item Extensions
\end{itemize}
-% Old stuff starts here
+\subsubsection{Documentation tools}
-\subsection{Engine}
+\paragraph{\LaTeX\cite{latex}}
-An implementation of GTP, that is, the piece of software which offers the GTP
-interface to other applications.\@ It is designed to be used by a software
-controller but can also be directly run, mostly for debugging purposes. Its
-design is shown in \fref{fig:engine}. The core of the engine is related with
-three components, each with a separate responsibility:
+A typesetting system widely used in the investigation field, among others. It
+allows for documentation like this text to be written in plain text and then
+compiled to PDF or other formats, which permits keeping the source files of the
+documentation small and organized plus other benefits of plain text such as
+being able to use version control.
-\begin{itemize}
- \item The IO component is the one called from other applications and offers
- the text interface. It reads and processes input and calls corresponding
- commands from the core of the engine.
- \item The EngineBoard component stores the state of the match, recording
- information such as the history of boards positions and whose turn goes
- next. The engine core uses it for these state-storing purposes.
- \item The EngineAI component is responsible of analyzing the match and
- generate moves. The engine core uses it when a decision has to be made
- by the AI, such as when a move needs to be generated by the engine.
-\end{itemize}
+\paragraph{PlantUML\cite{puml}}
+
+A program which creates diagrams from plain text files. PlantUML supports syntax
+for many different sorts of diagrams, mainly but not only UML. It has been used
+to generate the diagrams used in this text.
+
+\paragraph{Make}
+
+A tool for specifying and handling dependencies on a build system. It reads a
+file, typically named ``Makefile'', containing which files are needed and on
+which other files each of them depends, and then generates those files or
+updates them if they already exist but their source files are newer than them.
+
+It has been used to generate this text from \LaTeX{} and PlantUML source files.
+The contents of the Makefile with which this document has been compiled are
+shown in \flist{code:makefile}.
-\begin{figure}[h]
- \begin{center}
- \includegraphics[width=\textwidth]{diagrams/gtpEngine.png}
- \caption{Design of the GTP engine.}\label{fig:engine}
- \end{center}
-\end{figure}
-
-\subsection{Modules}
-
-One module to store the state of the game and the game tree. One module to parse
-moves. One module to read and write SGF files. Modules are shown in
-\fref{fig:modules}.
-
-\begin{figure}[h]
- \begin{center}
- \includegraphics[width=\textwidth]{diagrams/modules.png}
- \caption{Modules.}\label{fig:modules}
- \end{center}
-\end{figure}
-
-\subsection{Representation of a match}
-
-A regular Go match is composed of a list of moves. But since game review and
-variants exploration is an important part of Go learning, \program{} allows for
-navigation back and forth through the board states of a match and for new
-variants to be created from each of these board states. Therefore, a match is
-represented as a tree of moves. The state of the board at any given move must
-also be stored so liberties, captures count and legality of moves can be
-addressed, so it is represented with its own class, which holds a reference both
-to the game tree and the current move. Moves depend on a representation of the
-game board to have access to its current layout and count of captured stones.
-These classes and their relationships can be seen in
-\fref{fig:gameRepresentation}.
-
-\begin{figure}[h]
- \begin{center}
- \includegraphics[width=0.7\textwidth]{diagrams/gameRepresentation.png}
- \caption{A game is represented as a tree of moves.}\label{fig:gameRepresentation}
- \end{center}
-\end{figure}
-
-\subsection{SGF}
-
-To parse SGF files a lexer and parser have been implemented using PLY.\@ The
-result of the parsing is an AST (Annotated Syntax Tree) reflecting the contents
-of the text input, each node with zero or more properties, and with the ability
-to convert themselves and their corresponding subtree into a GameTree. This is
-done for the root node, since from the SGF specification there are some
-properties only usable in the root node, like those which specify general game
-information and properties such as rank of players or komi. These components are
-shown in \fref{fig:sgfModule}.
-
-\begin{figure}[h]
- \begin{center}
- \includegraphics[width=\textwidth]{diagrams/sgfModule.png}
- \caption{Components of the SGF file parsing module.}\label{fig:sgfModule}
- \end{center}
-\end{figure}
+\begin{listing}[h]
+ \inputminted{make}{Makefile}
+ \caption{Documentation Makefile}\label{code:makefile}
+\end{listing}
diff --git a/doc/tex/systemDesign.tex b/doc/tex/systemDesign.tex
index 5988ae0..ccd1c48 100644
--- a/doc/tex/systemDesign.tex
+++ b/doc/tex/systemDesign.tex
@@ -1,2 +1,95 @@
\section{System Design}
+\subsection{Class diagram}
+
+The full class diagram is shown in \fref{fig:fullClasses}
+
+\begin{figure}[h]
+ \begin{center}
+ \includegraphics[width=\textwidth]{diagrams/fullClasses.png}
+ \caption{Full class diagram.}
+ \label{fig:fullClasses}
+ \end{center}
+\end{figure}
+
+% From here
+
+
+\subsection{Engine}
+
+An implementation of GTP, that is, the piece of software which offers the GTP
+interface to other applications.\@ It is designed to be used by a software
+controller but can also be directly run, mostly for debugging purposes. Its
+design is shown in \fref{fig:engine}. The core of the engine is related with
+three components, each with a separate responsibility:
+
+\begin{itemize}
+ \item The IO component is the one called from other applications and offers
+ the text interface. It reads and processes input and calls corresponding
+ commands from the core of the engine.
+ \item The EngineBoard component stores the state of the match, recording
+ information such as the history of boards positions and whose turn goes
+ next. The engine core uses it for these state-storing purposes.
+ \item The EngineAI component is responsible of analyzing the match and
+ generate moves. The engine core uses it when a decision has to be made
+ by the AI, such as when a move needs to be generated by the engine.
+\end{itemize}
+
+\begin{figure}[h]
+ \begin{center}
+ \includegraphics[width=\textwidth]{diagrams/engineModule.png}
+ \caption{Design of the GTP engine.}\label{fig:engine}
+ \end{center}
+\end{figure}
+
+\subsection{Modules}
+
+One module to store the state of the game and the game tree. One module to parse
+moves. One module to read and write SGF files. Modules are shown in
+\fref{fig:modules}.
+
+\begin{figure}[h]
+ \begin{center}
+ \includegraphics[width=\textwidth]{diagrams/modules.png}
+ \caption{Modules.}\label{fig:modules}
+ \end{center}
+\end{figure}
+
+\subsection{Representation of a match}
+
+A regular Go match is composed of a list of moves. But since game review and
+variants exploration is an important part of Go learning, \program{} allows for
+navigation back and forth through the board states of a match and for new
+variants to be created from each of these board states. Therefore, a match is
+represented as a tree of moves. The state of the board at any given move must
+also be stored so liberties, captures count and legality of moves can be
+addressed, so it is represented with its own class, which holds a reference both
+to the game tree and the current move. Moves depend on a representation of the
+game board to have access to its current layout and count of captured stones.
+These classes and their relationships can be seen in
+\fref{fig:gameRepresentation}.
+
+\begin{figure}[h]
+ \begin{center}
+ \includegraphics[width=0.7\textwidth]{diagrams/gameRepresentation.png}
+ \caption{A game is represented as a tree of moves.}\label{fig:gameRepresentation}
+ \end{center}
+\end{figure}
+
+\subsection{SGF}
+
+To parse SGF files a lexer and parser have been implemented using PLY.\@ The
+result of the parsing is an AST (Annotated Syntax Tree) reflecting the contents
+of the text input, each node with zero or more properties, and with the ability
+to convert themselves and their corresponding subtree into a GameTree. This is
+done for the root node, since from the SGF specification there are some
+properties only usable in the root node, like those which specify general game
+information and properties such as rank of players or komi. These components are
+shown in \fref{fig:sgfModule}.
+
+\begin{figure}[h]
+ \begin{center}
+ \includegraphics[width=\textwidth]{diagrams/sgfModule.png}
+ \caption{Components of the SGF file parsing module.}\label{fig:sgfModule}
+ \end{center}
+\end{figure}
diff --git a/doc/tex/tfg.tex b/doc/tex/tfg.tex
index f387064..4c64bb2 100644
--- a/doc/tex/tfg.tex
+++ b/doc/tex/tfg.tex
@@ -13,6 +13,9 @@
\usepackage[backend=biber, style=numeric, sorting=none]{biblatex}
\addbibresource{tex/biber.bib}
+\usepackage{minted} % Code importing and formatting
+\setminted{linenos, breaklines}
+
\geometry{left=4cm,top=2cm,bottom=2cm,right=4cm}
\hypersetup{colorlinks=false,
@@ -27,6 +30,7 @@
\newcommand{\program}{Imago}
\newcommand{\fref}[1]{Fig.~\ref{#1}}
+\newcommand{\flist}[1]{Listing~\ref{#1}}
%\newcommand{\uurl}[1]{\underline{\url{#1}}}
\newcommand{\tabitem}{~~\llap{\textbullet}~~}
@@ -110,10 +114,14 @@ inclusion to use this template is included here.
\clearpage
+\setcounter{secnumdepth}{3}
+\setcounter{tocdepth}{4}
\tableofcontents
\listoffigures
+\listoflistings
+
\clearpage
\input{tex/introduction.tex}
@@ -122,7 +130,7 @@ inclusion to use this template is included here.
\input{tex/systemAnalysis.tex}
-%\input{tex/systemDesign.tex}
+\input{tex/systemDesign.tex}
\input{tex/implementation.tex}