aboutsummaryrefslogtreecommitdiff
path: root/doc/tex/conclusions.tex
diff options
context:
space:
mode:
authorInigoGutierrez <inigogf.95@gmail.com>2023-06-12 20:16:04 +0200
committerInigoGutierrez <inigogf.95@gmail.com>2023-06-12 20:16:04 +0200
commitd4a81490bf1396089eb3dac5955a3a8e4cb26e37 (patch)
treef96febc7950c2742bc36f04ab13bff56851f2388 /doc/tex/conclusions.tex
parentb08408d23186205e71dfc68634021e3236bfb45c (diff)
parent65ac3a6b050dcb88688cdc2654b1ed6693e9a160 (diff)
downloadimago-master.tar.gz
imago-master.zip
Merge branch 'devel'HEADmaster
Diffstat (limited to 'doc/tex/conclusions.tex')
-rw-r--r--doc/tex/conclusions.tex23
1 files changed, 12 insertions, 11 deletions
diff --git a/doc/tex/conclusions.tex b/doc/tex/conclusions.tex
index ebbf7fd..a6bc434 100644
--- a/doc/tex/conclusions.tex
+++ b/doc/tex/conclusions.tex
@@ -6,22 +6,22 @@ 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
-previous board positions after each move so no boards are repeated.
+must be specifically addressed. As an 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.
\subsection{Problems with the Monte Carlo Tree Search Algorithm}
-The implementation Monte Carlo Tree Search algorithm was not precise by itself
-when asked for moves. This could be attributed to various factors:
+The implemented Monte Carlo Tree Search algorithm was not precise by itself when
+asked for moves. This could be attributed to various factors:
\begin{itemize}
@@ -31,7 +31,7 @@ when asked for moves. This could be attributed to various factors:
are not precise on analyzing the result since the moves in them are
played at random.
- \item The configuration used, 5 explorations with 10 simulations each for
+ \item The configuration used, 5 explorations with 10 simulations each per
cycle, does not allow for many good moves to be found.
\end{itemize}
@@ -48,7 +48,7 @@ on this section.
\subsubsection{Finding the correct design}
-When approaching neural networks design with a basic understanding of their
+When approaching neural networks design with just basic understanding of their
inner workings it is easy to get lost in all the different factors that can be
tuned. The number and variant of layers, their number of nodes, their activation
function, the learning rate; they can all be tweaked and doing so in the favour
@@ -84,7 +84,7 @@ for evaluation.
\subsubsection{Mistakes on Networks' Play Patterns}
One notable mistake made by the networks, specially the convolutional network,
-was passing to much. Passing is considered just another move, so the networks
+was passing too much. Passing is considered just another move, so the networks
have no grasp that they should not pass until there are no more valuable moves
to be made. A new design problem could be to create a specific passing policy.
@@ -93,7 +93,8 @@ make reasonable decisions at the start of the game, with some interesting
variations. But as the game progresses their moves make less sense. This could
be because they have seen many examples of starting moves but complications at
the middle and end game are much more diverse and the networks had not been
-trained on similar situations.
+trained on similar situations. These stages of the game are probably where a
+strong Monte Carlo Tree Search algorithm would help the most.
\subsection{Viable Extensions}
@@ -109,8 +110,8 @@ simpler. The logical next step would be to join both: the network could select
the best moves to be made, and the tree search algorithm could explore them to
select the best and grow its explored tree in meaningful directions.
-This is also what was done by AlphaGo. By seeing the results obtained in this
-project it makes sense they made that decision.
+This is also what was done by AlphaGo. Going by the results obtained in this
+project it makes sense they went with that design.
\subsubsection{Train the Engine by Itself}