... ... @@ -2,7 +2,7 @@ \label{chap:alg} \section{Idea} Since our approach to identifying candidates is large based on set theory, the algorithms for finding are also making heavy use of set operations, using essentially the same construction method for creating the set of optimization candidates as the definitions presented in \autoref{chap:candidates}. Since our approach to identifying candidates is largely based on set theory, the algorithms for finding are also making heavy use of set operations, using essentially the same construction method for creating the set of optimization candidates as the definitions presented in \autoref{chap:candidates}. \subsection{Graph Optimization} Optimization of the theory graph happens one theory at a time, beginning at the outer most edges of the theory graphs, i.e. those theories that are not included by any other theory. ... ... @@ -18,7 +18,7 @@ Optimization of a theory itself happens in two separate passes. The first pass d The reason for separating these passes is to avoid the removal of simply redundant inclusions, that will later have to be reinserted when eliminating a partially superfluous inclusion. An example for such a hazard is the example of an overlap between the two types of candidates in \autoref{fig:redundantoverlap} \subsubsection{First pass - Eliminating superfluous inclusions} \subsubsection{First Pass - Eliminating Superfluous Inclusions} In the first pass we first take a selection of optimization candidates, namely those theories that are directly included, but not used in the current theory. These are the theories that need to be replaced. ... ... @@ -35,7 +35,7 @@ Proof sketch: \item Any indirectly included theory is either included by a theory that is retained or by one that is being replaced. Since the replacement of a theory inclusion is the necessary subset of its included theories, all necessary dependencies will remain included. \end{itemize} \subsubsection{Second pass - Eliminating simply redundant inclusions} \subsubsection{Second Pass - Eliminating Simply Redundant Inclusions} The idea behind the second pass is to collect all those theories that are included indirectly by the current theory and throwing away all of those direct inclusions that are part of this set. This will leave us exactly with those inclusions that are not simply redundant, without changing the flattened theory graph. ... ... @@ -48,9 +48,9 @@ If we do so, all indirect inclusions must ultimately be the result of a direct i If these assumptions are wrong however, not only could we run into problems, but we will inevitably do so if the current theory is part of the cycle. It is therefore best to only perform this operation on a graph that satisfies our assumption. \end{itemize} \subsection{Future Lite Code} \subsection{Future Light Cone} \label{sec:futurelite} In \autoref{sec:viability} we already mentioned the problem of future lite code. The obvious method for aquiring the future lite code is traversing the entire theory graph and whenever we find a theory inclusion, we make a note for the included theory that the theory we are currently traversing is part of its future code. Unfortunately this requires traversing the graph in its entirety. In \autoref{sec:viability} we already mentioned the problem of future light cone. The obvious method for acquiring the future light cone is traversing the entire theory graph and whenever we find a theory inclusion, we make a note for the included theory that the theory we are currently traversing is part of its future code. Unfortunately this requires traversing the graph in its entirety. For the actual algorithm we skip this part and instead put create a map of used theories in the future code, since this is the part we actually require. Since this means potentially going over every theory for every theory (or at least reasonably close to it), our worst case runtime for this part of the algorithm is quadratic in the number of theories in the graph. ... ... @@ -114,7 +114,7 @@ To somewhat mitigate the effect this has on the performance, the future is creat \section{Pseudo Code} \subsection{Optimizing graph} \subsection{Optimizing Graph} \label{sec:optgraph} The following code applies the optimizations to the entire theory graph. ... ... @@ -139,7 +139,7 @@ The following code applies the optimizations to the entire theory graph. \caption{optimizeGraph(theorygraph)} \end{algorithm} \subsection{Optimizing theory} \subsection{Optimizing Theory} \label{sec:opttheo} The following pseudo code applies optimizations to a given theory. ... ... @@ -158,7 +158,7 @@ The following pseudo code applies optimizations to a given theory. \caption{optimize(theory, futureUse)} \end{algorithm} \subsection{Finding superfluous inclusions} \subsection{Finding Superfluous Inclusions} \label{sec:alg_si} The following pseudo code is for finding superfluous inclusions (see: \autoref{sec:superinc}). ... ... @@ -184,7 +184,7 @@ The following pseudo code is for finding superfluous inclusions (see: \autoref{s Note that in \autoref{sec:superinc} we made a destinction between purely and partially superfluous inclusions. However we do not need to make this distinction while searching for them, as we can search for them by using the criteria for generally superfluous inclusion. Since they only differ in the set of inclusions that needs to be retained and we write that set in our result anyway, both can be accomplished by the same routine. \subsection{Finding simply redundant inclusions} \subsection{Finding Simply Redundant Inclusions} \label{sec:alg_sri} The following pseudo code is for finding simply redundant inclusions (see: \autoref{sec:redinc}). ... ... @@ -208,7 +208,7 @@ The following pseudo code is for finding simply redundant inclusions (see: \auto \caption{simplyRedundantIncludes(theory)} \end{algorithm} \section{Performance analysis} \section{Performance Analysis} Since the performance will be heavily dependent on the size of the graph to be optimized, we will measure runtime and memory requirements depending on the variable t, which denotes the number of theories in the graph. \subsection{Runtime} ... ... @@ -216,6 +216,7 @@ Since the performance will be heavily dependent on the size of the graph to be o Exact runtime is specific to the library implementations of used functions, but after looking at the relevant Scala documentation we can make a few helpful assumptions \cite{scaladoccolperf}. With effective constant time to lookup, add and remove in a hashset, we can deduce that likely runtimes for the set-operations $\cup$, $\cap$ and $\setminus$ are O(n), where n is the number of elements in the sets involved. \vfill \subsubsection{First pass} \begin{algorithm}[H] ... ...