Commit a645b394 authored by Michael Banken's avatar Michael Banken

added fluff, placeholders and interface

parent 45a80015
......@@ -3,3 +3,9 @@
*.synctex.gz
*.out
*.toc
*.pdf
*.bbl
*.blg
*.fls
*.tks
*.fdb_latexmk
@misc{scaladoccolperf, title={{Scala Documentation} {Collections} Performance Characteristics}, howpublished = {\url{https://docs.scala-lang.org/overviews/collections/performance-characteristics.html}}, journal={Scala Documentation}, publisher={scala-lang.org}, note={Accessed: 2018-06-14}}
\ No newline at end of file
@misc{scaladoccolperf, title={{Scala Documentation} {Collections} Performance Characteristics}, howpublished = {\url{https://docs.scala-lang.org/overviews/collections/performance-characteristics.html}}, journal={Scala Documentation}, publisher={scala-lang.org}, note={Accessed: 2018-06-14}}
@article{rupprecht2017flexible,
title={A Flexible, Interactive Theory-Graph Viewer},
author={Rupprecht, Marcel and Kohlhase, Michael and M{\"u}ller, Dennis},
journal={MathUI},
year={2017}
}
\ No newline at end of file
......@@ -86,6 +86,12 @@
\newunicodechar{}{\ensuremath{\otimes}}
\newunicodechar{}{\ensuremath{\wedge}}
\lstset{
basicstyle=\ttfamily,
columns=fullflexible,
frame=single,
breaklines=true
}
\begin{document}
\pagestyle{plain}
......
......@@ -55,7 +55,8 @@ For the actual algorithm we skip this part and instead put create a map of used
This runtime is especially problematic, since we need to update the the information after every step of the optimization to make proper use of any improvements of the graph. We can demonstrate this by considering the following example.
\begin{figure}[h]
\begin{figure}[!htb]
\centering
\begin{tikzpicture}[node distance=2cm]\footnotesize
\node[thy] (bottom) {\begin{tabular}{l}
\textsf{bottom}\\\hline
......@@ -81,7 +82,8 @@ This runtime is especially problematic, since we need to update the the informat
As we can immediately see in \autoref{fig:changeablefuture}, it is possible to replace the partially superfluous inclusion of middle in top with bottom. The result is the changed graph in \autoref{fig:changedfuture}.
\begin{figure}[h]
\begin{figure}[!htb]
\centering
\begin{tikzpicture}[node distance=2cm]\footnotesize
\node[thy] (bottom) {\begin{tabular}{l}
\textsf{bottom}\\\hline
......
......@@ -15,6 +15,7 @@ An inclusion of a theory $A\hookrightarrow{}C$ is \underline{simply redundant},
\providecommand\myyscale{2.2}
\providecommand\myfontsize{\footnotesize}
\begin{figure}[!htb]
\centering
\begin{tikzpicture}[node distance=3cm]\footnotesize
\node[thy] (bottom) {\begin{tabular}{l}
\textsf{bottom}\\\hline
......@@ -41,6 +42,7 @@ An inclusion of a theory $A\hookrightarrow{}C$ is \underline{simply redundant},
Simply redundant inclusions can be safely optimized by simply removing the redundant inclusion, as seen in \autoref{fig:redundantoptimized}, without changing the flattened graph due to the transitive nature of inclusions.
\begin{figure}[!htb]
\centering
\begin{tikzpicture}[node distance=3cm]\footnotesize
\node[thy] (bottom) {\begin{tabular}{l}
\textsf{bottom}\\\hline
......@@ -83,6 +85,7 @@ where $DirectIncludes(T)$ are the theories included directly in the theory T and
An inclusion of a theory $A\hookrightarrow{}B$ is \underline{purely superfluous}, if $B$ uses none of the constants in $A$, not even if they were declared in a theory $C$ such that $C\hookrightarrow{}A$.\\
\label{sec:puresi}
\begin{figure}[!htb]
\centering
\begin{tikzpicture}[node distance=3cm]\footnotesize
\node[thy] (bottom) {\begin{tabular}{l}
\textsf{bottom}\\\hline
......@@ -102,6 +105,7 @@ An inclusion of a theory $A\hookrightarrow{}B$ is \underline{purely superfluous}
Purely superfluous inclusions can be removed while still retaining a valid theory, however this will change the resulting theory graph. These changes may or may not be what is desired. An example for such an optimization can be seen in \autoref{fig:purelysuperfluousoptimized}.
\begin{figure}[!htb]
\centering
\begin{tikzpicture}[node distance=3cm]\footnotesize
\node[thy] (bottom) {\begin{tabular}{l}
\textsf{bottom}\\\hline
......@@ -125,6 +129,7 @@ where $Includes(I)$ are the transitively included theories in I, $DirectIncludes
\label{sec:partiallysi}
An inclusion of a theory $A\hookrightarrow{}B$ is \underline{partially superfluous}, if $B$ uses none of the constants in $A$, but uses some declarations that were declared in one or more theory $C$ such that C is (transitively) included in A. We describe theories that have declarations being used in a theory A, which includes them, as \underline{theories used by A}.\\
\begin{figure}[!htb]
\centering
\begin{tikzpicture}[node distance=3cm]\footnotesize
\node[thy] (bottom) {\begin{tabular}{l}
\textsf{bottom}\\\hline
......@@ -158,6 +163,7 @@ An inclusion of a theory $A\hookrightarrow{}B$ is \underline{partially superfluo
Partially superfluous inclusions can be optimized by identifying the used subset of (transitive) inclusions and replacing the superfluous inclusion with these inclusions. As seen in \autoref{fig:partiallysuperfluousoptimized}.
\begin{figure}[!htb]
\centering
\begin{tikzpicture}[node distance=3cm]\footnotesize
\node[thy] (bottom) {\begin{tabular}{l}
\textsf{bottom}\\\hline
......@@ -199,7 +205,8 @@ The danger of performing the proposed optimizations varies between the type of c
\subsection{Simply redundant inclusion}
As noted in \autoref{sec:puresi} there is very little that speaks against removing simply redundant inclusions, since the flattened graph is preserved. However there are some cases where they might do more harm than good, particularly when they overlap with superfluous inclusions, as seen in \autoref{fig:redundantoverlap}.\\ Removing the redundant edge will not change the flattened graph, but it will complicate the changes needed to remove the superfluous edge between middle and top. A simple solution to avoiding this problem is to relegate the removal of simple redundancies until after other optimizations have been performed on the theory.\\
\begin{figure}[h]
\begin{figure}[!htb]
\centering
\begin{tikzpicture}[node distance=2cm]\footnotesize
\node[thy] (bottom) {\begin{tabular}{l}
\textsf{bottom}\\\hline
......@@ -230,7 +237,8 @@ Purely superfluous includes are a little trickier, as their removal can fundamen
A trivial example for a purely superfluous inclusion that should not be optimized is any theory union, ie. a theory that consists entirely of theory inclusions (\autoref{fig:theoryunion}).\\
Removing purely superfluous includes from a theory union will leave behind an entirely empty theory. Since an empty theory is rarely a desired outcome an easy fix is to skip theory unions for this or in fact any kind of optimization.
\begin{figure}[h]
\begin{figure}[!htb]
\centering
\begin{tikzpicture}[node distance=2cm]\footnotesize
\node[thy] (union) {\begin{tabular}{l}
\textsf{union}\\\hline
......@@ -260,7 +268,8 @@ If this content is required by a theory that originally included it via an inclu
Another problem arises were inclusion paths branch of before eventually meeting again. Ideally optimizing superfluous inclusions should retain exactly those theory inclusions that are necessary for keeping a valid theory graph with no undeclared objects. Unfortunately this is complicated by the requirement to keep a theory's future valid. Specifically the problem arises if a future theory indirectly includes a theory over more than one path (see \autoref{fig:doubleinclusion}).
\begin{figure}[h]
\begin{figure}[!htb]
\centering
\begin{tikzpicture}[node distance=3cm]\footnotesize
\node[thy] (bottom) {\begin{tabular}{l}
\textsf{bottom}\\\hline
......@@ -299,7 +308,8 @@ Due to the inherent similarities many of the prior considerations also apply to
Let us consider the following example from elementary Algebra (\autoref{fig:elalg}). It is easy to define a monoid as a semigroup with the addition of a neutral element. The problem this poses for our optimizations is that our definition doesn't make use of associativity in any way. If all the symbols needed for defining the neutral element are delivered through a theory included by semi groups called Magma, then replacing the inclusion of semigroups with magma is a perfectly valid optimization. This is however a vastly different theory then we would expect of something that calls itself a monoid and can lead to complications if a theory including this theory expects it to contain the associativity rule, as it should. Again this problem can be somewhat alleviated by looking at the future lite code.
\begin{figure}[h]
\begin{figure}[!htb]
\centering
\begin{tikzpicture}[node distance=2cm]\myfontsize
\node[thy] (magma) {\begin{tabular}{l}
\textsf{Magma}\\\hline
......
\chapter{Implementation}
\label{chap:implementation}
\section{Integration}
\section{Programming Interface}
\section{User Interface}
\ No newline at end of file
\subsection{Programming Interface}
\label{sec:api}
\begin{lstlisting}[language=scala]
/** Find simply redundant inclusions
*
* This method finds inclusions that are redundant, since they are already part of a different inclusion
* @param theoryPath This is the path of the theory to be optimized
* @param replacementmap This is a map containing inclusion replacements for each theory
* @return This is a list containing the suggested removals for the theory
*/
def findRedundantIncludes(theoryPath : MPath, replacementmap : HashMap[MPath, HashMap[Path, HashSet[MPath]]] = HashMap[MPath, HashMap[Path, HashSet[MPath]]]()) : List[Path]
\end{lstlisting}
\begin{lstlisting}[language=scala]
/** Finds superfluous inclusions
*
* This method optimizes a theory by reducing its inclusions to those used inside the theory
* @param theoryPath This is the path of the theory to be optimized
* @param replacementmap This is a map containing inclusion replacements for each theory
* @param futureUse This is a map containing used theories in the futureLite-code
* @return This is a map containing the suggested replacements for the theory
*/
def findUnusedIncludeReplacements(theoryPath : MPath, replacementmap : HashMap[MPath, HashMap[Path, HashSet[MPath]]] = HashMap[MPath, HashMap[Path, HashSet[MPath]]](), futureUse : HashMap[MPath, HashSet[MPath]] = HashMap[MPath, HashSet[MPath]]()) : HashMap[Path, HashSet[MPath]]
\end{lstlisting}
\begin{lstlisting}[language=scala]
/** Optimizes multiple theories
*
* This method optimizes all given theories in the Iterable.
* Boolean toggle for interactive mode.
* @param theories Theories to be optimized as Iterable[MPath]
* @return This is a map containing the suggested replacements for all analyzed theories
*/
def findReplacements(theories: Iterable[MPath], interactive : Boolean) : HashMap[MPath, HashMap[Path, HashSet[MPath]]]
\end{lstlisting}
\begin{lstlisting}[language=scala]
/** Optimizes all known theories
*
* This method optimizes all theories inside the onthology
* @return This is a map containing the suggested replacements for all analyzed theories
*/
def findReplacements(interactive : Boolean = false) : HashMap[MPath, HashMap[Path, HashSet[MPath]]]
\end{lstlisting}
\begin{lstlisting}[language=scala]
/** Converts map to xml
*
* This method converts a given mapping as generated by findReplacements to an XML representation
* @param map This is a map containing inclusion replacements for each theory
* @return XML-String
*/
def toXML(map : HashMap[MPath, HashMap[Path, HashSet[MPath]]]) : String
\end{lstlisting}
\subsection{User Interface}
\label{sec:ui}
\begin{figure}[!htb]
\centering
\includegraphics[scale=.5]{styler_window}
\caption{A screenshot of the styler dialog}
\label{fig:dialog}
\end{figure}
\subsection{UML}
\label{sec:uml}
\ No newline at end of file
\chapter{Introduction}
\section{Motivation}
Knowledge is complex and so is its representation.
\begin{figure}[!htb]
\centering
\includegraphics[width=\textwidth/2]{placeholder}
\caption{Picture of a theory graph using TGView\cite{rupprecht2017flexible}}
\label{fig:tgview}
\end{figure}
To help reduce unnecessary complexity of these theory graphs, I introduce styler, a semi-automated tool for optimizing theory inclusions.
\section{Goal}
\section{Goal}
\ No newline at end of file
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment