aboutsummaryrefslogtreecommitdiff
path: root/doc/tex/conclusions.tex
diff options
context:
space:
mode:
authorInigoGutierrez <inigogf.95@gmail.com>2023-06-02 13:02:08 +0200
committerInigoGutierrez <inigogf.95@gmail.com>2023-06-02 13:02:08 +0200
commit88fbf5f8919211cfa06116a76f42fb26ec9f2e18 (patch)
tree962d26ca9b07bb28fae607e4d8ba4008893b1900 /doc/tex/conclusions.tex
parent2d895e4abb26eccefe6b4bc201fd60eb79600e3e (diff)
downloadimago-88fbf5f8919211cfa06116a76f42fb26ec9f2e18.tar.gz
imago-88fbf5f8919211cfa06116a76f42fb26ec9f2e18.zip
Second revision and added rules of the game.
Diffstat (limited to 'doc/tex/conclusions.tex')
-rw-r--r--doc/tex/conclusions.tex19
1 files changed, 10 insertions, 9 deletions
diff --git a/doc/tex/conclusions.tex b/doc/tex/conclusions.tex
index 16118e0..a6bc434 100644
--- a/doc/tex/conclusions.tex
+++ b/doc/tex/conclusions.tex
@@ -6,8 +6,8 @@ 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 \gls{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
@@ -20,8 +20,8 @@ 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
@@ -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}