aboutsummaryrefslogtreecommitdiff
path: root/doc/tex/conclusions.tex
diff options
context:
space:
mode:
authorInigoGutierrez <inigogf.95@gmail.com>2022-10-28 19:09:24 +0200
committerInigoGutierrez <inigogf.95@gmail.com>2022-10-28 19:09:24 +0200
commit3b78e9f3751dfc7c77a7d137d0dbab04afcb23f5 (patch)
treece69f712378d54ac21d47a3ccad9211090aaf19a /doc/tex/conclusions.tex
parente74f404f9cb5f0d5752178ab8baf4055c0a10f84 (diff)
downloadimago-3b78e9f3751dfc7c77a7d137d0dbab04afcb23f5.tar.gz
imago-3b78e9f3751dfc7c77a7d137d0dbab04afcb23f5.zip
Adding glossary.
Diffstat (limited to 'doc/tex/conclusions.tex')
-rw-r--r--doc/tex/conclusions.tex4
1 files changed, 2 insertions, 2 deletions
diff --git a/doc/tex/conclusions.tex b/doc/tex/conclusions.tex
index 9b6fd00..16118e0 100644
--- a/doc/tex/conclusions.tex
+++ b/doc/tex/conclusions.tex
@@ -6,14 +6,14 @@ could be done in the future to improve the system are discussed here.
\subsection{Problems with the Implementation of the Game}
While Go has a simple set of rules, they lead to many borderline cases which
-must be specifically addressed. For example, the ko rule obliges to check the
+must be specifically addressed. For example, the \gls{ko} rule obliges to check the
previous board positions after each move so no boards are repeated.
These problems have been solved by designing the tree of moves of a match so
each move stores the full board layout after it has been played. This of course
increases the memory needed to run the application, but has been chosen over the
alternative of having to recreate the board parsing the tree backwards for each
-move to check if ko is occurring, if a move makes a capture and which stones
+move to check if \gls{ko} is occurring, if a move makes a capture and which stones
have already been captured, etc. It is the old problem of memory versus
processing, which in this case has been answered with memory. Which one would be
the best solution would require a deep analysis out of the scope of the project.