text:
\chapter{Implementation}
\label{prototype}

The \Meta\ prototype implements nodes, reductions, and grammars as described in the previous chapters, and a compiler for the kernel language. I built a core language via syntax extension of the kernel language. The \Meta\ editor is capable of editing and executing both grammars and core language programs.

The prototype demonstrates the feasibility of implementation all of the previously-discussed concepts, and provided a test bed for experiments with defining languages and syntax, described in the next chapter.

\section{The Host Platform}
The prototype system is implemented in Clojure \cite{clojure}, a language in the Lisp family which runs on the Java Virtual Machine \cite{jvm}. Clojure also fills the role of the host kernel language. Some characteristics of Clojure that make it a good choice include:
\begin{enumerate}
\item Similar notion of a kernel language. The prototype simply adopts (a subset of) the special forms of Clojure as its kernel language.
\item Functional orientation. Clojure is a non-pure functional language; it allows side-effects but (in contrast to most Lisps) all of its bindings and data structures are immutable.
\item Compilation service available at runtime. The Clojure compiler is part of the runtime stack, so once a program is reduced to the kernel language, it can be evaluated (compiled) and executed immediately.
\item Access to the Java platform. The prototype takes advantage of Java's GUI toolkit for rendering and editing.
\end{enumerate}

Nodes are represented as a Lisp-style abstract data type comprising a series of functions \clojure{make-node}, \clojure{node?}, \clojure{node-type}, etc., which allow Clojure programs to construct and manipulate nodes independent of the concrete representation. The prototype uses only these functions to work with nodes.

The implementation of the node ADT uses Clojure's \clojure{deftype} construct to represent nodes as instances of a \clojure{nodetype} class at the JVM level. This reduces the overhead for simple nodes to the minimum. Map- and sequence-valued nodes use Clojure's built-in persistent hash map and persistent vector data structures (based on Bagwell's array mapped tries \cite{bagwell}) to store their children.

The \clojure{make-node} function provides a convenient serialized form for nodes: s-expressions. A \clojure{print-node} function turns a node object back into text which can be read and evaluated to re-constitute the node. This low-level representation is never seen by the user of the system.

\section{The Host Language}
\label{host}
The host language is composed of a kernel based on the primitive constructs and values of Clojure together with a core language built via syntax extension on top of the kernel language. \Meta\ core language programs are reduced to the kernel language (via reductions defined in a \keyword{grammar} program), to Clojure's s-expressions (via the \Meta\ meta-compiler), to Java bytecode (via the Clojure compiler), and finally to a native executable (via the JVM's compiler/optimizer). Therefore a program written using newly-introduced syntax runs without any fixed overhead. This allows the editor to perform reductions during editing with good responsiveness, and allows for non-trivial programs to be executed (see the next chapter). At the same time, taking advantage of the Clojure compiler and platform allowed me to build a working system in a short time and with only a modest amount of code. This efficiency allowed me to bring two previous approaches to a mostly-working stage before I arrived at the node representation, reduction scheme, and grammar language described in this thesis.

\subsection{The Kernel Language}
The kernel language, shown in Figure \ref{fig-kernel}, consists of six kinds of primitive values, six node types corresponding to Clojure's special forms, two nodes for quotation, and a node for making external references to the platform. Virtually every node is an instance of the abstract \keyword{expr} type, yielding some kind of value as a function of its arguments; there are no statements and no mutating assignments.

%The kernel language is somewhat simplified relative to the complete list of Clojure's special forms. A few forms which are not currently used are left out, and several of the nodes are somewhat less flexible in form than the corresponding Clojure syntax.

\begin{figure}
%  \todo{fix columns? clean up primitives with some syntax}

%  \fbox{
  \begin{minipage}[t]{0.48\linewidth}
  \vspace{0pt}  % align to top
  \begin{center}
  \includegraphics[scale=0.65]{src/image/kernel1.pdf}
  \end{center}
  \end{minipage}
%  }
%  \hfill
%  \fbox{
  \begin{minipage}[t]{0.48\linewidth}
  \vspace{0pt}  % align to top
  \begin{center}
  \includegraphics[scale=0.65]{src/image/kernel2.pdf}
  \end{center}
  \end{minipage}
%  }

%\todo{\keyword{loop}}

  \caption{\label{fig-kernel} Grammar for the host kernel language.}
\end{figure}

The kernel language is extremely simple compared to a typical general-purpose language. Like Clojure, the kernel language is not statically typed, which helps keep \Meta's implementation simple---all checking of operands is done at runtime, by the Clojure/Java platform. All but a few kernel language node types are instances of \keyword{expr}, representing expressions yielding a single value. This simplicity makes the language easy to implement, and makes it an easy target for reductions.

The primitive values of the kernel language are the singular values \keyword{nil}, \keyword{true}, and \keyword{false}, plus integers, strings, and names.

A \keyword{lambda} node introduces a function taking a fixed number of arguments. A \keyword{params} node always represents the parameters of a function, and can appear only as the \keyword{params} attribute of a \keyword{lambda} node. Each parameter is a \keyword{bind} node, discussed later. A lambda node is ``bound'' within its body, supporting simple recursive calls. \keyword{recur} is a non-stack-consuming recursive call, and must appear in tail position.

$n$-ary functions are included in the kernel language as they are in Clojure to allow a simple mapping to Java methods for high performance without sophisticated compilation techniques. The kernel language does not support Clojure's variable-arity functions.

\keyword{app} is (call-by-value) function application. The \emp{expr} is evaluated first (to a function), then the expressions in \keyword{args} are evaluated from left to right.

Simple conditionals are provided by \keyword{if}. All values except \keyword{false} and \keyword{nil} are treated as true when they appear as the \emp{test} expression.

\keyword{let} evaluates an expression, binds a name to the resulting value and then evaluates its body with that binding in scope. \Meta\ provides only a single-binding, non-recursive primitive \emp{let} form.

A \keyword{var} node is a reference to the value bound by the parameter of a lambda, by the lambda itself, or by a let expression. Variables are lexically-scoped, and lambdas capture all bindings in scope at their point of declaration. All these forms are strict in all their arguments, and have no side-effects.

An \keyword{extern} node refers to a variable at the Clojure level. This allows any function or value defined by the Clojure platform or \Meta\ runtime to be accessed. Use of these external facilities is minimized in order to make the core language as self-contained as possible.

\keyword{quote} and \keyword{unquote} are given special treatment by the meta-compiler.

\subsection{Meta-compilation}
Given a program in the kernel language, a function \clojure{meta-compile} translates the nodes to Clojure s-expressions in a mostly straight-forward way, due to the close correspondence between kernel nodes and Clojure's special forms. Only a few types of nodes need special consideration. %Then Clojure's \clojure{eval} function is invoked, and the program is compiled to Java bytecode, loaded into the JVM, and executed. Because the kernel language maps so closely to Clojure's forms, the meta-compilation process is mostly trivial.

%Each kernel language node corresponds precisely to a Clojure special form or value, without any additional interpretation. Furthermore the structure of a Clojure program after reading matches the structure of the kernel program precisely: a Clojure program is a tree made from lists where the first element of each list is a symbol which names a special form. For example, the list produced by the reader for the string \clojure{"(+ 1 (* 2 3))"} has exactly the same overall shape as the corresponding kernel language program, with lists replaced by \keyword{app} nodes, and the simple names \clojure{*} and \clojure{+} wrapped in \keyword{extern} nodes. \todo{include a picture of the nodes version? How to do that without going into presentation issues? Can I avoid having tons of pictures of trees?}

A \keyword{bind} node is reduced to a symbol, and a \keyword{var} node to the symbol of the corresponding binding. The problem of producing suitable names and avoiding conflicts is easily solved due to the uniqueness of labels in the \Meta\ program. The meta-compiler simply generates a new name for each label and uses that name for both \keyword{bind} and \keyword{var} nodes.

When the meta-compiler encounters a \keyword{quote} node, it enters a separate mode where instead of translating kernel language nodes to s-expressions, it instead translates nodes (potentially in any language) to s-expressions that construct a new copy of the quoted nodes. When an \keyword{unquote} node is encountered, the meta-compiler reduces the contents in the normal way, and then inserts the resulting value into the expression building the quoted node. Quotations may be nested more than one level deep, so the reduction keeps track of the current level and only resumes ordinary translation when the level reaches zero.

When quoted nodes are compiled, they are relabeled (that is, each node is assigned a fresh, globally-unique label) and each non-free reference is updated to point to the new node. This is important because it means that no code outside of the newly-generated fragment can possibly contain a reference to anything defined in it. For example, reductions for syntax extensions commonly bind values to names (in order to control evaluation order, for example), and each name is defined by some \keyword{bind} node. So in a reduced program, each instance of the reduced fragment will contain a binding which originated in the same node, but each binding is completely distinct and independent in the reduced program due to the relabeling that is performed when the reduction is executed. Because all names are unique at all times, the problem of unintended variable capture does not arise, and some of the complexities of providing ``hygienic macros''\cite{hygiene} may be avoided.

Once a kernel language program has been meta-compiled, the standard Clojure function \clojure{eval} is invoked, which compiles the expression to Java bytecode, loads it into the running JVM, invokes it, and returns the result as a Clojure/Java value.

\subsection{Core Language}
The host core language provides common facilities built via syntax extension on top of the kernel language.
%That is, nodes of the core language are reduced to kernel language nodes prior to meta-compilation.
A subset of Clojure's Core API~\cite{clojure-and} is implemented, plus primitives for constructing and manipulating AST nodes. Some examples using the syntax which exposes Clojure's cons-list primitive are shown in Figure~\ref{fig-core}. Some of the definitions used in these examples are presented in Section~\ref{for}.

%One such primitive is \keyword{cons} (rendered as an infix `:'), which constructs a lazy sequence given head and tail expressions; the head is evaluated immediately, and the tail expression is wrapped in a thunk---it will be evaluated the first time the tail of the resulting sequence is needed. This simple mechanism allows lazy infinite sequences to be used in core language programs, as seen in some of the examples in Figure \ref{fig-core}.

\begin{figure}
	\centering

	\includegraphics[scale=0.8]{src/image/core3.pdf}

	\caption{Example core language expressions and their values.}
	\label{fig-core}
\end{figure}

%\todo{some more examples and/or some of the grammar?}

\subsection{Compiling Reductions}
To employ a \emp{display} or \emp{expand} reduction defined in a grammar, it needs to be transformed into a reduction function which can be applied to a source program node, yielding a reduced node (see Section~\ref{reduction}). Each reduction in the grammar is an expression which may contain variables referring to the attributes of the node. Therefore a reduction function can be constructed by simply wrapping the reduction expression in a lambda abstraction and a series of \keyword{let}s binding each of the attributes. For example, the reduction for \keyword{string} nodes looks like this:
\begin{center}
\includegraphics{src/image/reduce.pdf}
\end{center}
where $\keyword{attr}[\mathit{node}, \mathit{name}]$ extracts the named attribute from a node. Once the \keyword{value} attribute is bound, the result node is constructed by evaluating the quoted \keyword{string} node (which appeared in the actual declaration in the grammar shown in Figure~\ref{fig-kernel}).

A similar function is constructed and compiled for each node type, and then an overall reduction function is built which dispatches to the right reduction based on the type of each node. This overall function is built incrementally as the declarations of a grammar are processed, so that later reductions can make use of syntax defined in earlier declarations.

%
% Rendering :expr:
%
\section{Rendering the Expression Language}

After a program is reduced to the \keyword{expr} presentation language (via the \keyword{display} reductions specified in the particular grammar being used), it can be presented to the user using the common facilities of \Meta. To do so, the program is further reduced to a low-level presentation language.

\subsection{The \textit{\keyword{view}} Presentation Language}
\label{view}

The \keyword{view} language is a lower-level presentation language. Some of the algorithms of \TeX\ \cite{tex-math} are used to lay out nodes and construct glyphs, as in e.g.\ \cite{mathml}. In contrast to the \keyword{expr} language, all the elements of the \keyword{view} language specify fonts, colors, and sizes in concrete terms, so they can be rendered directly. The main tasks of the reduction from \keyword{expr} to \keyword{view} are to identify the correct font size for each atom based on the nesting of expressions, and to transform \keyword{embed}/\keyword{disembed} nodes into border/background colors. Both of these computations involve propagating some information about the structure of the tree down as the nodes are recursively processed.

The mode, a concept from \TeX, identifies the depth of nesting of expressions, and controls the selection of font sizes for atoms. There are four modes, \textit{Display} ($D$), \textit{Text} ($T$), \textit{Script} ($S$), and \textit{Scriptscript} ($SS$). $D$ and $T$ call for normal-sized text, $S$ is about 30\% smaller, and $SS$ is about 50\% smaller. The handling of modes follows \TeX's algorithm in most cases, but deviates from it when necessary for consistency. For example, typographical convention dictates that addition expressions in the smaller modes should be set without spaces, but that would clash with \Meta's handling of parentheses, so \Meta\ sets these expressions with proportionately smaller spaces.

Each of the atom types of the \keyword{expr} language is reduced to a \keyword{chars} node. For example, when a node $n$ having the type \keyword{keyword} and \emp{str} attribute $s$ is reduced:
$$
n:~\mapnode{keyword}{ \attr{str}{s} }
 	\reduces
	\mapnode{chars}{ \attr{str}{s},~\attr{font}{ \mathbf{keywordfont}_{\mathbf{mode}[n]}} }
$$
where $\mathbf{keywordfont}_D$ and $\mathbf{keywordfont}_T$ are both names for the normal-size font for keywords, and $\mathbf{keywordfont}_S$ and $\mathbf{keywordfont}_{SS}$ name the two smaller versions. $\mathbf{mode}[n]$ is an inherited attribute~\cite{attribute-grammar}; except where specified, the mode of each node is the mode of its parent. Except for a handful of types, most atoms are reduced in exactly the same way, with a different font used for each type.

\vspace{12pt}
% string -> chars
Atoms representing string literals get special treatment. They're surrounded by quotes, and any white space characters in the string value are replaced by Unicode OPEN BOX characters (~\textvisiblespace~).
$$
n:~\mapnode{string}{\attr{str}{s}}
 	\reduces
	\mapnode{chars}{\attr{str}{\textrm{``} + \mathbf{escapews}[s] + \textrm{''}},
		~\attr{font}{\mathbf{stringfont}_{\mathbf{mode}[n]}} }
$$

\vspace{12pt}
% -> sequence
Each of \keyword{expr}'s four sequence types are reduced to a single type, and spaces are inserted between the child nodes:
\begin{align*}
& \seqnode{juxt}{ c_0, c_1, \dots, c_m }
 	\reduces
	 \seqnode{sequence}{ c_0, c_1, \dots, c_m }
\\
& \seqnode{binary}{ c_0, c_1, \dots, c_m }
 	\reduces
	 \seqnode{sequence}{ c_0, \keyword{thinspace}, c_1, \keyword{thinspace}, \dots,\keyword{thinspace}, c_m }
\\
& \seqnode{relation}{ c_0, c_1, \dots, c_m }
 	\reduces
	 \seqnode{sequence}{ c_0, \keyword{medspace}, c_1, \keyword{medspace}, \dots,\keyword{medspace}, c_m }
\\
& \seqnode{flow}{ c_0, c_1, \dots, c_m }
 	\reduces
	 \seqnode{sequence}{ c_0, \keyword{thickspace}, c_1, \keyword{thickspace}, \dots,\keyword{thickspace}, c_m }
\end{align*}

\vspace{12pt}
% fraction -> over
A \keyword{fraction} node is reduced to \keyword{over}, which has a configurable line weight, and the mode of each child is reduced:
$$
n: \mapnode{fraction}{ \attr{numer}{c_0},~\attr{denom}{c_1} }
 	\reduces
	\mapnode{over}{ \attr{top}{c_0},~\attr{bottom}{c_1},~\attr{weight}{1} }
$$
\begin{align*}
\mathbf{mode}[c_0] & \leftarrow \mathit{fractionmode}(\mathbf{mode}[n])
\\
\mathbf{mode}[c_1] & \leftarrow \mathit{fractionmode}(\mathbf{mode}[n])
\end{align*}
\begin{align*}
\mathit{fractionmode}(D) & = T
\\
\mathit{fractionmode}(T) & = S
\\
\mathit{fractionmode}(S) & = SS
\\
\mathit{fractionmode}(SS) & = SS
\end{align*}

\vspace{12pt}
% scripted
A \keyword{scripted} node is unchanged except that the mode of the raised and lowered child nodes is reduced:
$$
n: \mapnode{scripted}{ \attr{nucleus}{c_0},~
							\attr{super}{c_1},~
							\attr{sub}{c_2} }
$$
\begin{align*}
\mathbf{mode}[c_1] &\leftarrow \mathit{scriptmode}(\mathbf{mode}[n])
\\
\mathbf{mode}[c_2] &\leftarrow \mathit{scriptmode}(\mathbf{mode}[n])
\end{align*}
\begin{align*}
\mathit{scriptmode}(D) &= S
\\
\mathit{scriptmode}(T) &= S
\\
\mathit{scriptmode}(S) &= SS
\\
\mathit{scriptmode}(SS) &= SS
\end{align*}

\vspace{12pt}
% embed -> border
The \keyword{embed} and \keyword{disembed} nodes which represent quotations and other kinds of embedded code are reduced to \keyword{border} nodes, which draw a colored border around their contents and a background behind them. The color of each border is determined by the meta-level of the node. The level of the root node is always 0, and it is incremented when an \keyword{embed} node is encountered:
\begin{align*}
n:~& \mapnode{embed}{ \attr{content}{c} }
\\
	& \to
	\mapnode{border}{\attr{weight}{1},~
					\attr{margin}{3},~
					\attr{border}{b},~
					\attr{fill}{f},~
					\attr{content}{c} }
\end{align*}
\begin{align*}
b &= \mathbf{bordercolor}_{\mathbf{level}[c]}
\\
f &= \mathbf{fillcolor}_{\mathbf{level}[c]}
\end{align*}
\begin{align*}
\mathbf{level}[c] & \leftarrow \mathbf{level}[n] + 1
\end{align*}
Two series of colors $\mathbf{bordercolor}_i$ and $\mathbf{fillcolor}_i$ are pre-defined. $\mathbf{bordercolor}_1$ is dark blue, $\mathbf{bordercolor}_2$ is dark green, etc. Six colors are defined to support several levels of embedding. $\mathbf{fillcolor}_0$ is white (the background color of ordinary nodes). $\mathbf{fillcolor}_i$ is a lighter shade of $\mathbf{bordercolor}_i$.

For \keyword{disembed}, a similar border, but the border color corresponds to the \emp{parent} node's meta-level, while the background indicates the level of the inner node:
\begin{align*}
n:~& \mapnode{disembed}{ \attr{content}{c}, \attr{levels}{l} }
\\
	& \to
	\mapnode{border}{\attr{weight}{1},~
					\attr{margin}{3},~
					\attr{border}{b},~
					\attr{fill}{f},~
					\attr{content}{c} }
\end{align*}
\begin{align*}
b &= \mathbf{bordercolor}_{\mathbf{level}[n]}
\\
f &= \mathbf{fillcolor}_{\mathbf{level}[c]}
\end{align*}
\begin{align*}
\mathbf{level}[c] & \leftarrow \mathbf{level}[n] - l
\end{align*}

\vspace{12pt}
The remaining nodes of the \keyword{expr} language require no special handling, because they do not affect the mode or meta-level of their sub-expressions.

A handful of additional nodes are provided in \keyword{view} for handling some of the needs beyond what \keyword{expr} can do. A \keyword{section} arranges its children in a left-aligned vertical stack. A wider space node, \keyword{quad}, is useful for indentation.

The reduction described in this section is implemented directly in Clojure, not in a \Meta\ grammar, because the grammar language does not currently provide any way to declare attributes. That might be a useful extension; if both inherited and synthesized attributes \cite{attribute-grammar} could be defined, it would be possible to write type systems for expressions. However, the burden of implementing this particular reduction manually is modest because the \keyword{expr} language is small and not meant to be extended.

The smaller modes quickly become hard to read for anything but very simple expressions (especially on relatively low-resolution displays), so wise language designers (and programmers) will use them sparingly. The \TeX book \cite{knuth} gives much good advice about how to use them effectively. Some clear applications of the smaller modes are for constant ratios and exponents, and for decorating variable names with small integer subscripts and ``prime'' symbols, as in $x' = \frac{1}{2}x^2 + a_0$.

\subsection{Rendering the \textit{\keyword{view}} Presentation Language}
The \keyword{view} language is consumed by a \emp{renderer} written in Clojure using the graphics primitives of Java2D \cite{java2d}. The renderer recursively inspects the tree, calculating node sizes and layout, and then actually drawing nodes. The renderer also provides hit-testing for nodes, identifying a list of \keyword{view} nodes which enclose a given point.

For each node, the renderer calculates a width $w$ and height $h$ in (floating-point) pixels. Depending on the node type, there may be a baseline height, $b$ (between 0 and $h$), which defines the position of the node relative to a common baseline. When a node has children, the renderer calculates a horizontal and vertical position $(x, y)$ for each child, relative to the upper-left corner of the parent node.

For \keyword{chars} nodes, $w$, $h$, and $b$ values are calculated based on the string and font via Java2D. In general, other nodes' baselines are derived from their children, so that the \keyword{chars} nodes in nearby parts of the tree are baseline-aligned.

In a \keyword{sequence}, child nodes with baselines are vertically aligned to their baselines, and children without baselines are aligned to their centers (and to the collective center of the baseline-aligned nodes).

The baseline of a \keyword{scripted} node is that of its nucleus. An \keyword{over} node has no baseline.

The delimiters of a \keyword{group} node (e.g. parentheses or brackets) are vertically centered relative to the contents, and the actual glyph is chosen from a list of variously-sized alternatives. \TeX's fonts are used for these glyphs, as well as for most symbols reduced from \keyword{expr/symbol}.

Any node can have a \keyword{color} attribute, which causes the single node to be drawn with a different foreground color.

These definitions are sufficient to get simple expressions to render well, but the current algorithm lacks \TeX's second alignment step (the \emp{axis}), so some expressions are not quite properly aligned (e.g. fraction lines are not aligned with the vertical centers of $+$ and $-$ operators).

%Size and layout are calculated as follows:
%\begin{eqnarray*}
%w & = & \sum w_i
%\\
%h & = & \mathrm{max}\left( h_b, \mathrm{max}(h_i) \right)
%\\
%b & = & (h/2 - h_b/2) + a_\mathrm{max}
%\\
%x_i & = & \sum_{j=0}^{i-1} w_i
%\\
%y_i & = & \left\{
%		\begin{array}{lr}
%			b - b_i, & b_i\ \mathrm{defined}
%			\\
%			(h - h_i)/2, & \mathrm{otherwise}
%		\end{array}
%		\right.
%\\
%where &
%\\
%h_b & = & a_\mathrm{max} + d_\mathrm{max},\ \textit{the aggregate height of baseline-aligned nodes}
%\\
%a_\mathrm{max} & = & \mathrm{max}(b_i),\ \textit{the largest ascent}
%\\
%d_\mathrm{max} & = & \mathrm{max}(h_i - b_i),\ \textit{the largest descent}
%\end{eqnarray*}

%A \keyword{section} node contains a vertical series of nodes aligned at their left edges:
%\begin{eqnarray*}
%w_\mathrm{section} & = & \mathrm{max}(w_i)
%\\
%h_\mathrm{section} & = & \sum h_i
%\\
%b_\mathrm{section} & = & b_0
%\\
%x_i & = & 0
%\\
%y_i & = & \sum_{j=0}^{i-1} h_i
%\end{eqnarray*}

%\keyword{over}, \keyword{radical}, and \keyword{delimited} nodes were described earlier. \keyword{border} draws its content with a background color, surrounded by a rectangular border with a configurable weight.

%For layout purposes, the renderer calculates a size for each node, consisting of width, height, and optional baseline height. A baseline is calculated for each \keyword{chars} node based on its font, and certain other nodes calculate a baseline based on their contents. \keyword{sequence} nodes' children are laid out so that nodes with baseline heights are aligned to a mutual baseline, and nodes without baseline heights are aligned to their vertical center (and the overall vertical center of all baseline-aligned siblings). This is sufficient to get simple expressions to render well, but the current algorithm lacks \TeX's second alignment step (the \emp{axis}), so some expressions are not quite properly aligned (e.g. fraction lines are not aligned with the vertical centers of $+$ and $-$ operators).

%\keyword{radical} and \keyword{delimited} nodes are laid out by first sizing the content node, then selecting the appropriate glyph(s) from a list of variously-sized alternatives, and finally calculating sizes and positions based on the selected glyph. \TeX's fonts are used for these glyphs, as well as for most symbols reduced from \keyword{expr/symbol}.

The renderer makes several passes over the tree to draw different layers. The first pass draws only \keyword{border} nodes, which therefore appear ``behind'' all other elements. The nodes are drawn in pre-order, so that parent borders and their background fill are drawn behind any child borders. On the second pass, an indicator of the selected node is drawn, so that it will appear above the border rects, but behind the actual content. The final pass renders all non-border nodes.

\subsection{Renderer Implementation}

The renderer is written in a simple functional style, freely traversing the node tree as much as necessary. However because some of the necessary calculations are relatively expensive, the renderer initially performed poorly, taking on the order of 2-500ms to render a small program. This was easily improved by taking advantage of the fact that much of the renderer's time is spent in two kinds of referentially-transparent functions. The function that calculates the size of a text glyph given the characters and font is simply memo-ized, so that no more than one call is ever made for each unique glyph. The functions that calculate the position of each node are also cached, but only for the duration of a single rendering pass (mostly to avoid consuming arbitrary memory for no-longer-needed cached values when a succession of updated trees is rendered one after the other). That way the renderer performs well (10-20ms) despite being written in the most direct way, making no attempt to avoid redundant calculations. Clojure's functional nature and macro facility made it easy to implement this algorithmic change ``after the fact,'' without requiring the bulk of the rendering code to be re-written.

The renderer currently violates good functional programming style by performing the actual drawing via side-effecting operations during the traversal of the node tree. In hindsight, it would have been better to have the traversal yield a list of drawing commands to be executed later. For instance the layering of different kinds of visual elements could have been handled declaratively, rather than as a side-effect of traversal order.

%\subsection{Reducing \textit{\keyword{expr}} to \textit{\keyword{view}}}
%The reduction from \keyword{expr} to \keyword{view} is the most complex in \Meta, because it involves some non-local information. It is written by hand using an enhanced reduction algorithm which keeps track of a pair of values at each node: \emp{display mode} and \emp{meta-level}.

%The mode, a concept from \TeX, identifies the depth of nesting of expressions, and controls the selection of font sizes for atoms. There are four modes, \textit{Display} ($D$), \textit{Text} ($T$), \textit{Script} ($S$), and \textit{Scriptscript} ($SS$). By default, the mode of the root node is $T$, and the mode is decreased (roughly in sequence) whenever notational convention dictates that subexpressions should be typeset in a smaller font. When reducing an atom, the atom type and mode are used to look up the appropriate font. The handling of modes follows \TeX's algorithm in most cases, but deviates from it when necessary for consistency. For example, typographical convention dictates that addition expressions in the smaller modes should be set without spaces, but that would clash with \Meta's handling of parentheses, so \Meta\ sets these expressions with proportionately smaller spaces.

%\begin{figure}[h]
%\begin{center}
%\todo{capture something real}
%\end{center}

%$$
%\mathrm{D:} \quad
%a + b^2 + x^{c_1}
% - { x^{i+1} \over y }
% + { 1 \over { 1 \over R_1 }
% + { 1 \over R_2} }
% - \left({ 1 \over R_1 } + { 1 \over R_2}\right)^{-1}
%$$

%$$
%\mathrm{T:} \quad
%\textstyle
%a + b^2 + x^{c_1}
% - { x^{i+1} \over y }
% + { 1 \over { 1 \over R_1 }
% + { 1 \over R_2} }
% - \left({ 1 \over R_1 } + { 1 \over R_2}\right)^{-1}
%$$
%\caption{\label{fig-modes} Program fragment with multiple modes.}
%\end{figure}

%As the example in Figure \ref{fig-modes} shows, the smaller modes quickly become hard to read for anything but very simple expressions (especially on relatively low-resolution displays), so wise language designers (and programmers) will use them sparingly. The \TeX book\cite{knuth} gives much good advice about how to use them effectively. One clear application of the smaller modes in ordinary programs is for decorating variable names with small integer subscripts and ``prime'' symbols, as in $x' = x + a_0$.

%The meta-level is a non-negative integer indicating the level of nesting of the current node. It begins at zero and is incremented whenever an \keyword{embed} node is encountered and decremented on \keyword{disembed}. The \keyword{embed} node itself is reduced to a \keyword{border} which draws a light-colored background behind the embedded nodes, and a darker border of the same hue. A \keyword{disembed} node becomes a border with the hue of the lower level and the background of the outer level, making a visual connection between the outer and nested nodes that are at the same level. A fixed series of colors is used that can unambiguously indicate nesting of up to a half-dozen levels. An example of multi-level embedding appears in Figure \ref{fig-binary}, where the declaration is at level 0 (white background). The embedded right-side reduction is at level 1 (blue background), and it in turn contains a pair of embedded reductions (level 2, green background). The \emp{left} and \emp{right} attributes of the inner declaration are un-quoted (dis-embedded) back to level 1 within the level-2 reductions, while the \emp{op} and \emp{fn} are un-quoted to level 0.

%To compute the mode and meta-level at each node, the reduction function is extended to take the two values as additional parameters, and to return the pair of values along with the reduced node each time it is invoked. As the tree is visited, the values that were computed for a given node are passed to the reduction for its children. This allows the reduction function to compute values based on the shape of the tree, which would otherwise be impossible due to the lack of any reference from a sub-tree to its parent node. Effectively, the ``inherited'' value allows the reduction function to accumulate some information about the otherwise inaccessible ancestors. This simple extension is sufficient for this reduction (the most complicated yet encountered), and it does mean that this reduction could not be implemented in a grammar as almost all other reductions in \Meta\ are. A more sophisticated grammar language could support this kind of reduction, perhaps represented as an attribute grammar.\cite{attribute-grammar}

\subsection{Meta-reduction of \textit{\keyword{expr}}}
When editing regular programs, the \keyword{expr} language is meant to be invisible. When editing a grammar, the \keyword{expr} nodes of each presentation reduction are the subject at hand, so it's necessary for understanding to make them visible. To accomplish this, another hand-written reduction is used when editing grammars. This reduction decorates each node with a visual indication of its type, location, and size. This reduction is somewhat idiosyncratic in that it never actually replaces a node, but rather it inserts additional nodes (super-scripted \keyword{border} nodes), which surround the original nodes. Also, this reduction needs to be restricted to operate only on \keyword{expr} nodes of the original program, and not any nodes that might have been introduced by a reduction that was applied earlier. The reduction function is wrapped in a higher-order function that tracks which nodes remain to be reduced, using the mechanism described in the previous section.

The result can be seen in any of the examples of presentation reductions presented earlier. The idea of using a higher-order function (combinator) to assemble multiple simple reductions into something more complex came up again and again in building the prototype.

\subsection{Fallback Presentation Reduction}
Another useful reduction is one that is able to reduce any arbitrary node, imposing no restrictions whatsoever on the type or value of the node. This reduction can be used to show the internal structure of a node, disregarding the presentation reduction, or for displaying nodes for which no presentation reduction is available. This might be because the node's type is not declared in any applicable grammar, or because the presentation reduction itself is missing or unusable. All of these scenarios represent situations that \Meta\ aims to handle gracefully, because all of them can arise in the process of editing a program and/or the grammar that defines its language.

The solution is a \emp{fallback reduction}, which takes any node and reduces it to a node in the \keyword{view} language. A primitive-valued node is shown with a default style (similar to \keyword{expr}'s int, string, or name). A map- or sequence-valued node is surrounded by a border to set off the node as special, with the node type at the top and a series of lines with the attributes/indices and their values.

\begin{figure}[t]
  \begin{center}
  \includegraphics{src/image/gen.pdf}
  \end{center}
  \caption{Program fragment using a \keyword{cube} node, which hasn't been defined.}
  \label{fig-general}
\end{figure}

In Figure \ref{fig-general}, the programmer has attempted to write
$3  + (1 + 2)^3$,
but has used a ``cube'' node type for which no reduction is present. The fallback reduction makes the structure of the program clear in the absence of any specific knowledge of the ``cube'' node type, and gives the programmer the information she needs to figure out how to fix it. In this case she can either add a declaration for ``cube'' or change the program to use a different node type. This implementation does a good job of drawing attention to nodes that aren't handled properly and thus need attention, but it may be overly jarring when used within the context of an otherwise valid expression. Therefore, there may be a role for a less obtrusive reduction which shows any properly-defined children and gives an indication that something is amiss.

%
% Editing
%
\section{Editing}
The \Meta\ editor assembles the components described in the previous sections, along with a GUI shell. Each program is displayed in a separate window within a single process. When a grammar is used in the rendering of a program, changes to the grammar are reflected in the program's display immediately. Grammars and other kind of programs are presented and edited in the same way, the only difference being that a different sequence of reductions is applied. Neither the UI nor the programs themselves currently provide any way to specify the reductions that are to be applied to a particular program; it's up to the user to do that when invoking the editor.

An editor window (see Figure\ \ref{fig-editor}) shows a program in a scrollable panel, accompanied by some additional information about the selected node, if any. Actions to edit the program are available in the menus, or via keystrokes.

\begin{figure}[t]
	\centering

	\includegraphics[scale=0.60]{src/image/editor.png}

	\caption{The \Meta\ editor, showing a portion of the grammar for the core language.}
	\label{fig-editor}
\end{figure}

\subsection{Editor Pipeline}
To convert a program into \keyword{view} nodes for rendering, the editor applies a series of reductions in turn, as diagrammed in Figure~\ref{fig-pipeline}. Some of the reductions are baked into the platform, while others are compiled at runtime from the grammars that are specified when the editor is invoked. The first set of reductions takes different program elements from the source language to the \keyword{expr} language. A special reduction handles names, and another introduces a \keyword{missing} node wherever the grammar in effect defines an attribute (even if optional) but the program doesn't actually contain such a node. Then the reduction defined by the grammar is applied. At this point, all language-specific syntax should have been replaced by \keyword{expr} nodes, if the program and grammar are correct.

Next, a pair of reductions produce the final \keyword{expr} program, inserting parentheses where they are needed, and reducing any remaining non-\keyword{expr} nodes in the generic way. Next the \keyword{expr}-to-\keyword{view} reduction reduces the program to the \keyword{view} nodes that will be rendered, and finally that program is handed to the renderer for layout and drawing.

\begin{figure}[t]
	\begin{center}
	\includegraphics[scale=0.8]{src/image/pipeline.pdf}
	\end{center}

	\caption{Reductions in the editor pipeline.}
	\label{fig-pipeline}
\end{figure}

The editor itself takes charge of executing the reductions, keeping track of how the final \keyword{view} nodes were derived from the source program. Thus the end product of the rendering pipeline is a target program in the \keyword{view} language, plus a map identifying the target program node that arose from each source program node. Because a source program node often reduces to a sub-tree rather than a single node, not every target program node is identified with a source; only the root of each sub-tree needs to be tracked. The editor uses this tracking of nodes to let the user interact with the nodes of the \emp{source} program, even though what's actually being rendered is the target program, many layers of reduction removed.

%When it's desirable to keep track of what source node gave rise to a given target node, the reduction can record the labels of each pair of source and target node, forming a kind of mapping between the parallel trees.

The need to map target nodes back to source nodes drove many decisions about how to represent programs. The presentation reduction must operate on one node at a time, and must produce a single target node. For example, the arguments of an \keyword{app} node are held by a characteristic \keyword{args} node mostly so that the editor can identify the resulting sequence of nodes and provide appropriate editing actions on them. For now, \keyword{expand} reductions are not so restricted, because \Meta\ does not try to trace nodes of reduced programs back to the corresponding source node. However, that might become desirable in the future, for instance in order to provide proper source locations for runtime errors.

%\temp{For this to work, the reduction function needs to operate strictly on the single node it's given, and not reach into any child node. This in turn places some constraints on the way the source program is constructed: each node (along with any environment) must bear sufficient information to identify the correct reduction.}

\subsection{Selection}
One of the main tasks of the editor is to make the structure of the program apparent to the programmer. Rendering the nodes of the program in a rich, familiar notation enhances readability but may not always make the structure of nodes very clear. In order to make a change to the AST, the programmer needs to be aware of this structure. The editor's UI for selection facilitates this awareness by visually emphasizing the relationship between a single selected node and its children, and by providing a way to move between nodes that is defined in terms of the source AST. Thus the structure becomes visible once it is salient, but is left somewhat implicit or even obscured otherwise.

Unlike a text editor, where the typical unit of selection is a character position (i.e. the lowest level of the program text), in \Meta\ the selection identifies a single source-program node which can be at any level of the source tree. A new node can be selected by clicking anywhere in the view. The new selection node is the deepest node whose boundary encloses the clicked location. Once a selection has been established, a new node can be selected by invoking an action to move the selection to a neighboring node using the notion of relative position defined in the next section. Currently there are actions to select the parent, next or previous sibling, or the first visible child.

%The selection indicator is drawn as a distinctly-colored, slightly rounded rectangle filling in the boundary of the selected node. The boundaries of the visible children are not filled, thus visually emphasizing the relationship between the node and its children. This also means that the filled region corresponds with the region of the display that can be clicked to select that particular node.

The single selected node is the target of all editing operations. Limiting selection to a single node supports many but not all editing operations that might be desired, so a more sophisticated model might support more notions of selection. For example, multiple sequential nodes could be selected and moved as a unit.

Identifying program elements this way effectively exposes the tree structure of the program to the programmer in a tangible way and encourages the programmer to think about the program in terms of this structure. Whether or not this feels natural or is easy to understand represents one test of the overall concept of editing the AST.

\subsection{Identifying Nodes by Position}
Selection operates in terms of source nodes and their relationships to each other, but it also reflects the concrete representation of the program, using the mapping of target nodes to source nodes. Because each target node is identified with a rectangular area of the view, and because each source node is identified with a root target node, the editor can identify the boundary of the visual representation of each source program node. When reduced to concrete syntax, the unordered children of a map-valued node are effectively ordered, and some children may be ignored.

%Once the target program is produced, along with the mapping of origins, the editor can construct a correspondence between source nodes and view-space. Because each target node is identified with a rectangular area of the view, and because each source node is identified with a root target node, the editor can identify the boundary of the visual representation of each source program node. Somewhat more abstractly, the visual arrangement of source nodes can be gleaned, allowing the editor to identify the visible children of each source node, and the order that they appear in the concrete syntax. Based on this information, the editor defines certain relations between source nodes.

The \emp{parent} node is simply the parent in the usual sense. The editor assumes that every ancestor of every visible node is itself visible. Only the root node has no parent.

The \emp{visible children} of a node are the subset of the node's children for which there is some \keyword{view} node, ordered by their visual position. That is, the visible children do not include any child nodes which were ignored by the presentation reduction, and the otherwise unordered children of a map-valued node are ordered according to how they appear in the visual representation of the node. The order is from left to right (sequences) and top to bottom (sections and fractions). The children of a \keyword{subscript} node are ordered as follows: nucleus, superscript, subscript.

The \emp{visible siblings} of a node are the visible children of the node's parent. The \emp{next} sibling is defined in the obvious way for all nodes which are not the last visible child of their parent. The \emp{previous} sibling is similarly defined (except for the first visible child).

%Figure \ref{fig-position-tree} shows an example AST, hand-drawn to show the tree structure and to identify the parent, sibling, and child nodes of the node labeled ``selected''. Note that the three children of the \keyword{if} node are identified by attribute names (then, test, and else), but not ordered.
Figure~\ref{fig-position} shows a simple expression, annotated to indicate the parent, sibling, and child nodes of the node labeled ``selected''.

%\begin{figure}
%  \begin{center}
%  \includegraphics[scale=1.5]{src/image/position-tree.pdf}
%  \end{center}
%
%  \caption{A simple expression as an AST, annotated to show relative node positions.}
%  \label{fig-position-tree}
%\end{figure}

\begin{figure}
  \begin{center}
  \includegraphics[scale=1.5]{src/image/position-ann.pdf}
  \end{center}

  \caption{A simple expression in \Meta, annotated to show relative node positions.}
  \label{fig-position}
\end{figure}

\subsection{Edit Actions}
The editor provides a range of operations on source nodes, which the user can use to construct and modify node trees. The examples in the next chapter will show them in action.
%The current prototype provides only basic editing operations; to demonstrate a truly usable system would involve more investment in making common operations intuitive and efficient. Edit actions may be invoked through menus or keystrokes.

There are just two primitive operations.

\emp{Delete} removes the selected node from its parent. If the parent is a map, it will no longer have any value for the attribute that was occupied by the selected node. If a sequence, the node is removed and any following children move to smaller indices. Note that a simple delete removes an entire subtree, not just the selected node itself.

\emp{Insert} adds a new node as a child of the selected node with a particular attribute name or index. If the selected node is a map, any previous child with the same attribute name is replaced. If a sequence, the new child pushes any existing children to the right.

All other edits are composed out of those two primitives:

\emp{Replace} deletes the selected node and inserts a new node in the same position.

\emp{Swap with previous} exchanges the places of the selected node and the previous sibling, by a sequence of three replace operations. \emp{Swap with next} is similar.

\emp{Insert parent} Interposes a new node between the selected node and its parent, by deleting the selected node, constructing a new node with it as a child, and then inserting the new node in the same position.

%\temp{Change type?}

%\temp{Swap with parent?}

\emp{Copy} does not affect the selected node, but saves a reference to it as a separate piece of editor state (the \emp{clipboard}).

\emp{Cut} copies and then deletes the selected node.

\emp{Paste} replaces the selected node with the contents of the clipboard.

When a new node is to be introduced, a simple interface is presented to allow the node's type to be specified. Another UI allows primitive values to be edited.

Before each edit operation, the current source AST and the identity of the selected node are pushed onto a stack of previous states. When the \emp{undo} action is performed, the most recent state is popped from the stack and restored. Because each edit involves $O(\log n)$ nodes, this is efficient enough for extended use.

When any editing action changes the source AST, the editor re-reduces the entire program and then redisplays the new reduced target tree. When a grammar is edited, the grammar itself is re-displayed, and then any reductions that were compiled from it are regenerated and any programs using them are redisplayed as well. This environment allows languages to be redefined dynamically.

%\subsection{Errors \todo{}}

%
% Example
%
\section{Example: Entering Expressions}

Here's how the \Meta\ editor can be used to enter some simple expressions.

Suppose you want to evaluate the expression $(1+2) \times 3$. Begin with an empty core-language program, which is a single \keyword{program} node, with no children. The core grammar requires at least one \keyword{doc} or \keyword{expr} node in the program, so the editor supplies an empty node to start you off:
\begin{center}
\includegraphics{src/image/expr1.pdf}
\end{center}
%$$?$$

Select the node and type the character `\clojure{1}'. The editor infers you want to replace the missing node with a new \keyword{int} node in the core language, and does so, leaving the new node selected:
\begin{center}
\includegraphics{src/image/expr2.pdf}
\end{center}
%$$[1]$$

Now we want to add 2 to that, so first type `\clojure{+}'. The editor assumes you want to replace the selected node with a new \keyword{plus} node, and it adds the selected node as the first child of the new node (this is the \emp{insert parent} action with the type \keyword{plus} for the new node). Now the missing right argument is selected:
\begin{center}
\includegraphics{src/image/expr3.pdf}
\end{center}
%$$1+[?]$$

Simply typing `\clojure{2}' completes the first sub-expression:
\begin{center}
\includegraphics{src/image/expr4.pdf}
\end{center}
%$$1+[2]$$

Now we want to multiply this expression by 3, but you can't simply add the \keyword{times} node yet, because that would make a new node with only 2 as the left argument. Instead, use the ``select parent node'' action (from now on, $\uparrow$) to move the selection to the \keyword{plus} node (or just click on the $+$ sign):
\begin{center}
\includegraphics{src/image/expr5.pdf}
\end{center}
%$$[1+2]$$

Now type `\clojure{*}' to create a new node. The previous selection becomes the left child, and \Meta\ inserts parentheses to indicate that the actual grouping of sub-expressions is contrary to what would be suggested by the normal spacing of the operators alone:
\begin{center}
\includegraphics{src/image/expr6.pdf}
\end{center}
%$$\lsyn 1+2 \rsyn \times [?]$$

Finally, type `\clojure{3}' to complete the expression:
\begin{center}
\includegraphics{src/image/expr7.pdf}
\end{center}
%$$\lsyn 1+2 \rsyn \times [3]$$

For this kind of simple expression, the \Meta\ editor's efficiency is quite similar to that of entering text. In fact the sequence of characters is not much different: `\clojure{1+2}$\uparrow$\clojure{*3}' as opposed to, say, `\clojure{(1+2)*3}'. Assuming you use only the keyboard, the actual number of keystrokes is fewer by one with \Meta.

Alternatively, you could have entered the same expression in ``top-down'' fashion using the sequence `\clojure{*+1}$\rightarrow${2}$\uparrow\rightarrow$\clojure{3}'. Interestingly, this seems to mimic the process of typing a prefix expression, with `$\rightarrow$' taking the place of spaces between sibling nodes, and `$\uparrow$' acting as a '\clojure{)}' to close one node and return to the parent. I suspect in practice this is more intuitive than it sounds when described in that way, but only experience will tell (just ask anyone who has learned to use an RPN calculator). The editor attempts to support both styles equally well.

Furthermore, \Meta's rendering of the expression includes appropriate spacing, which you might feel the need to add if you were entering text, maybe like this: `\clojure{(1+2) * 3}' or `\clojure{(1 + 2)*3}', depending on your preference. This kind of manual type-setting is extra work for the programmer (imagine how many hours each year world-wide are spent entering and adjusting white-space!), and it's not very effective anyway. None of the three alternatives is particularly readable.

\vspace{12pt}

The host language provides syntax for more specialized purposes also, and these nodes aren't quite so easily accessed. For example, to generate a list of the first 10 perfect squares, you can use a sequence comprehension. Again, starting with a blank program:
\begin{center}
\includegraphics{src/image/for1.pdf}
\end{center}
%$$[?]$$

Use the \emp{insert node} action to create new node, entering the type \keyword{for}. The new node includes a variable binding. The editor supplies the default name, $x$ (which we won't change):
\begin{center}
\includegraphics{src/image/for2.pdf}
\end{center}
%$$\keyword{for} [x] \leftarrow ? | ?$$

%So just move the selection to the next sibling ($\rightarrow$), and :
For the expression, first enter a variable reference by typing `\clojure{x}'. This inserts a reference to a nearby variable, which happens to be $x$. Alternatively, hold down the \emp{insert reference} modifier keys and click on $x$.
\begin{center}
\includegraphics{src/image/for3.pdf}
\end{center}
%$$\keyword{for} \  x \leftarrow [?] \: .. \: ? \ | \ ?$$

Use the \emp{insert parent} action, entering \keyword{square} for the type:
\begin{center}
\includegraphics{src/image/for4.pdf}
\end{center}
%$$\keyword{for} \  x \leftarrow 1 \: .. \: [10] \ | \ ?$$

Now move the selection to the next sibling twice ($\rightarrow$, $\rightarrow$, or just click on the last `?').
\begin{center}
\includegraphics{src/image/for5.pdf}
\end{center}
%$$\keyword{for} \  x \leftarrow 1 \: .. \: 10 \ | \ [x]$$

Insert another node, this time a \keyword{range}.
\begin{center}
\includegraphics{src/image/for6.pdf}
\end{center}

Enter 1 and 10 for the range's min and max:
\begin{center}
\includegraphics{src/image/for7.pdf}
\end{center}

And that's it. Switching to \Meta's evaluation view:
\begin{center}
\includegraphics{src/image/for.pdf}
\end{center}

In this case, there is some extra effort to enter the \keyword{for}, \keyword{square}, and \keyword{range} nodes. That's the price of being able to add arbitrary nodes to your language. Furthermore, the editor UI could and should be extended to make this penalty as small as possible, for example, since the keystroke `\clojure{f}' has no particular behavior, it could offer a choice of all known node types beginning with `f'.

These examples hopefully give a sense of how an editor can offer both generality and reasonable usability, but the current \Meta\ editor is certainly only a starting point. Different UI interactions would be appropriate for different kinds of devices (say, emphasizing gestures over keyboard input for a device with a touch-sensitive screen), or for different users (say, something more like a mouse-driven structure editor for end-user programming applications).

max_stars_repo_name: mossprescott/lorax

max_issues_repo_name: mossprescott/lorax

max_forks_repo_name: mossprescott/lorax


text:
\documentclass[a4paper,12pt]{cv}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage[english]{babel}

\fullname{John Smith}

\begin{document}

\mkheader

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Personal Information}

\begin{description}
   \item[Date of Birth] { 1970-01-01 }
   \item[Address]       { ul. Wiejska 4/6, 00--902 Warsaw, Poland }
   \item[Phone number]  { (+48)012 345 678 }
   \item[E-mail]        { john-smith@example.org }
\end{description}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Work Experience}

\begin{description}
  \item[01.2012 -- present]{
     \begin{itemize}
        \item {
           Intercal programmer at Acme, Warsaw.
        }
        \item {
           Responsible for foo, bar, baz and qux.
        }
        \item {
           {\bf Keywoards:} Intercall, Make, etc
        }
     \end{itemize}
   }
\item[01.2011 -- 12.2011]{
   \begin{itemize}
      \item {
         Lolcode Programmer -- Lolcats Ltd, Gotham.
      }
      \item {
         I CAN HAZ CHEESBURGER
      }
      \item {
         How did I get here I'm not good with computer
      }
      \item {
         {\bf Keywoards:} Lolcode.
      }
   \end{itemize}
}
\end{description}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Education}

\begin{description}
   \item[2011--now]{Hogwarts, specialty Applied Computer Science}
\end{description}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Programming languages}

\begin{description}
   \item[Intercal]{3-4 years of experience}
   \item[Lolcode]{1-2 years of experience}
   \item[Lolcode Enterpreise Edition]{2 years of experience}
\end{description}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Languages}
\begin{description}
   \item[English]{Proficient}
   \item[Klingon]{Basic}
\end{description}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Home Page}
\texttt{http://example.org}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Hobbies and interests}
Amateur radio, Audiophilia, Baking, Basket weaving, Bboying, Baton twirling, Blogging

\footer {
  I hereby authorize you to process my personal data included in my job
application for the needs of the recruitment process in accordance with the
Personal Data Protection Act dated 29.08.1997 (uniform text: Journal of Laws of
the Republic of Poland 2002 No 101, item 926 with further amendments)
}

\end{document}

ext: tex

max_stars_repo_name: bartosz-witkowski/latex-cv-class

max_issues_repo_name: bartosz-witkowski/latex-cv-class

max_forks_repo_name: bartosz-witkowski/latex-cv-class


text: \subsection*{\quad$I\quad$}


text:
\hypertarget{classglite_1_1wms_1_1jdl_1_1AdSemanticMandatoryException}{
\section{glite::wms::jdl::Ad\-Semantic\-Mandatory\-Exception Class Reference}
\label{classglite_1_1wms_1_1jdl_1_1AdSemanticMandatoryException}\index{glite::wms::jdl::AdSemanticMandatoryException@{glite::wms::jdl::AdSemanticMandatoryException}}
}
{\tt \#include $<$Request\-Ad\-Exceptions.h$>$}

Inheritance diagram for glite::wms::jdl::Ad\-Semantic\-Mandatory\-Exception::\begin{figure}[H]
\begin{center}
\leavevmode
\includegraphics[height=3cm]{classglite_1_1wms_1_1jdl_1_1AdSemanticMandatoryException}
\end{center}
\end{figure}
\subsection*{Public Member Functions}
\begin{CompactItemize}
\item
\hyperlink{classglite_1_1wms_1_1jdl_1_1AdSemanticMandatoryException_a0}{Ad\-Semantic\-Mandatory\-Exception} (std::string file, int line, std::string method, int code, std::string attr\_\-name)
\end{CompactItemize}

\subsection{Detailed Description}
\hyperlink{classglite_1_1wms_1_1jdl_1_1AdSemanticMandatoryException}{Ad\-Semantic\-Mandatory\-Exception} - raised when a mandatoty attribute is missing to the class\-Ad

\subsection{Constructor \& Destructor Documentation}
\hypertarget{classglite_1_1wms_1_1jdl_1_1AdSemanticMandatoryException_a0}{
\index{glite::wms::jdl::AdSemanticMandatoryException@{glite::wms::jdl::Ad\-Semantic\-Mandatory\-Exception}!AdSemanticMandatoryException@{AdSemanticMandatoryException}}
\index{AdSemanticMandatoryException@{AdSemanticMandatoryException}!glite::wms::jdl::AdSemanticMandatoryException@{glite::wms::jdl::Ad\-Semantic\-Mandatory\-Exception}}
\subsubsection[AdSemanticMandatoryException]{\setlength{\rightskip}{0pt plus 5cm}glite::wms::jdl::Ad\-Semantic\-Mandatory\-Exception::Ad\-Semantic\-Mandatory\-Exception (std::string {\em file}, int {\em line}, std::string {\em method}, int {\em code}, std::string {\em attr\_\-name})}}
\label{classglite_1_1wms_1_1jdl_1_1AdSemanticMandatoryException_a0}

Raised when mandatory attribute is missing, unable to find a specified path, wrong attribute coexistence

The documentation for this class was generated from the following file:\begin{CompactItemize}
\item
\hyperlink{RequestAdExceptions_8h}{Request\-Ad\-Exceptions.h}\end{CompactItemize}

max_stars_repo_name: italiangrid/wms

max_issues_repo_name: italiangrid/wms

max_forks_repo_name: italiangrid/wms


text:
\section{Template} \label{sec:template}
\phantomsection
\begin{checklist}{Template}
  \item{Prepare one }{2 Aspects}
  \item{Consent form}{printed}
  \item{Main Activity is the blue line}{10 Minutes}
  \sepbar{blue}
  \item{Post Activity node}{}
  \item{Post experiment Questionnaire}{}
  \step{Q1}
  \step{Q2}
  \step{Q3}
  \item{Store Experiment Data}{}
\end{checklist}

max_stars_repo_name: DavidGoedicke/Researcher-Life-Checklist

max_issues_repo_name: DavidGoedicke/Researcher-Life-Checklist

max_forks_repo_name: DavidGoedicke/Researcher-Life-Checklist


text:
\documentclass[11pt]{article}

\usepackage[utf8]{inputenc} % Required for inputting international characters
\usepackage[T1]{fontenc} % Output font encoding for international characters

\usepackage{mathpazo} % Palatino font
\usepackage{graphicx}
\usepackage{geometry}
\usepackage{float}
\usepackage{amsmath}
\usepackage{tabu}
\usepackage{array}
\usepackage{cellspace}
\usepackage[table]{xcolor}
\usepackage{multirow}
\usepackage{multicol}
\usepackage{parskip}

\usepackage{titlesec}
\titlespacing\subsection{0pt}{1pt plus 4 pt minus 2pt}{1pt plus 4 pt minus 2pt}

\renewcommand{\baselinestretch}{1.25}
\geometry{margin=0.75 in}

\begin{document}

%----------------------------------------------------------------------------------------
%	TITLE PAGE
%----------------------------------------------------------------------------------------

\begin{titlepage} % Suppresses displaying the page number on the title page and the subsequent page counts as page 1
	\newcommand{\HRule}{\rule{\linewidth}{0.5mm}} % Defines a new command for horizontal lines, change thickness here

	\center % Centre everything on the page

	%------------------------------------------------
	%	Headings
	%------------------------------------------------

	\textsc{\LARGE Portland State University
}\\[.25cm] % Main heading such as the name of your university/college

	\textsc{\Large Department of Electrical and Computer Engineering }\\[.5cm] % Major heading such as course name
\includegraphics[width=0.2\textwidth]{psuLOGO}\\[.5cm]
	\textsc{\LARGE ECE 411 - Industry Design Process }\\[0.75cm] % Minor heading such as course title

		\textsc{\Large Professor Andrew Greenberg, MS\\
Professor of Electrical \& Computer Engineering
 }\\[.75cm]

	%------------------------------------------------
	%	Title
	%------------------------------------------------

	\HRule\\[0.4cm]

	{\huge\bfseries Design Review Notes}\\[0.4cm] % Title of your document

	\HRule\\[1.5cm]

	%------------------------------------------------
	%	Author(s)
	%------------------------------------------------

%	\begin{minipage}{0.4\textwidth}
%		\begin{flushleft}
%			\large
%			\textit{By:}\\
%		 \textsc{Kimball S. Davis} % Your name
%		\end{flushleft}
%	\end{minipage}
%	~
%	\begin{minipage}{0.4\textwidth}
%		\begin{flushright}
%			\large
%			\textit{Professor of Electrical \& Computer Engineering}\\
%		 \textsc{Professor Branimir Pejcinovic, Ph.D.} % Supervisor's name
%		\end{flushright}
%	\end{minipage}

	% If you don't want a supervisor, uncomment the two lines below and comment the code above
	\Large{Group \#16:}\\
		 \Large\textsc{Kimball S. Davis, Jason Houlihan, \& Nathan Lutterman} % Your name

	%------------------------------------------------
	%	Date
	%------------------------------------------------

	\vfill\vfill\vfill\vfill % Position the date 3/4 down the remaining page

	{\large\today} % Date, change the \today to a set date if you want to be precise

	%------------------------------------------------
	%	Logo
	%------------------------------------------------

	%\vfill\vfill
	%\includegraphics[width=0.2\textwidth]{PSULOGO}\\[1cm] % Include a department/university logo - this will require the graphicx package

	%----------------------------------------------------------------------------------------

	\vfill % Push the date up 1/4 of the remaining page

\end{titlepage}

%----------------------------------------------------------------------------------------
\setlength{\columnsep}{.2 in}

\setlength{\parskip}{0pt}

\section*{Schematic and Board Layout Design Review Notes}
\textbf{Team Being Reviewed:} Group 16: Kimball Davis, Jason Houlihan, Nathan Lutterman\\
\textbf{Reviewer:} Douglas Hall, Ph.D\\

\textit{NOTE: Although Professor Geenberg never directly reviewed our design, we discovered some flaws in our design while watching the reviews done in class. We included these in our review notes because we changed our design based on these observations before Dr. Hall reviewed the design.}

\section*{Schematic}

\subsection*{Critical}

\begin{itemize}

    \item Missing bypass capacitors on +5V inputs to AT89S52. Added 100 nF bypass capacitors to design.
    \item Don't put anything on the NET layer that is not a net. We had some section labeling on the NET layer. The text was moved to the NOTES layer.

\end{itemize}

\subsection*{Major}

\begin{itemize}

    \item Not clear exactly what the power is coming from. Changed power supply labeling in schematic.
    \item Make sure there are adequate test points. Added test points for I2C signals for display.
    \item Not clear how much current the loads require to operate, or what the loads are. Labeled the loads on the schematic with part number, voltage, and current specifications.

\end{itemize}

\subsection*{Minor}

\begin{itemize}

    \item For LEDS use 500 to 1K resistors to keep them dimmer. Changed resistors in LED circuits from 330 to 1k $\Omega$
    \item When presenting a schematic for review be aware of the scale. If our schematic were projected on a screen or on a laptop with zoom capabilities it would be fine. Presented on 11x7 paper a lot of the text is hard to read.

\end{itemize}

\section*{Layout}

\subsection*{Critical}

\begin{itemize}

    \item None

\end{itemize}

\subsection*{Major}

\begin{itemize}

    \item Will the voltage regulator need additional heat sinks based on the power the loads will draw?

\end{itemize}

\subsection*{Minor}

\begin{itemize}

    \item Consider printing top and bottom layers separately, or on transparencies that can overlap so it is easier for the reviewer to follow traces.
    \item Not clear what type of mounting hardware will be needed for connectors.

\end{itemize}

\section*{Bill of Materials}

\begin{itemize}

    \item Power supply, fan, and light-bulb specifications are not clearly defined.

\end{itemize}

\end{document}


text:
\documentclass[letterpaper,12pt]{scrartcl}
\usepackage{epsfig,latexsym,amsmath,amssymb,epic,eepic,psfrag,subfigure,float,euscript,array}
\usepackage[latin1]{inputenc}
\usepackage[margin=24mm]{geometry}
\usepackage{enumitem}
\usepackage{tikz,pgf,pgfplots}
\usepgfplotslibrary{fillbetween}
\usepgfplotslibrary{groupplots}
\usetikzlibrary{decorations, arrows}

\usepackage[amssymb]{SIunits}

\newenvironment{exercise}[1][Problem]{\begin{trivlist} \item[\hskip
    \labelsep {\stepcounter{exerctr}\bfseries #1
      \arabic{exerctr}}]}{\end{trivlist}\vspace{10mm}}

\newcounter{exerctr}
\newcounter{abcctr}[exerctr]

\newcommand{\abc}{\noindent\vspace{1mm}\\ {\bf
    \stepcounter{abcctr}(\alph{abcctr})\ }}
\newcommand{\bbm}{\begin{bmatrix}}
\newcommand{\ebm}{\end{bmatrix}}
\newcommand{\point}[1]{\hfill {\bf (#1p)}\\ \vspace{-5mm}}
\newcommand{\ctrb}{\EuScript{S}}
\newcommand{\Lap}{\mathcal{L}}
\newcommand{\obsv}{\EuScript{O}}
\newcommand{\realdel}{\text{Re}}
\newcommand{\imagdel}{\text{Im}}
\newcommand{\bC}{\mathbb{C}}
\newcommand{\bR}{\mathbb{R}}
\newcommand{\bmpv}{\begin{minipage}[t]}
\newcommand{\bmps}{\begin{minipage}[t]{45mm}}
\newcommand{\bmpm}{\begin{minipage}[t]{90mm}}
\newcommand{\bmpl}{\begin{minipage}[t]{\textwidth}}
\newcommand{\emp}{\end{minipage}}
\newcommand{\mexp}[1]{\ensuremath{\mathrm{e}^{#1}}}
\newcommand*{\laplaceinv}[1]{\ensuremath{\mathcal{L}^{-1} \left\{#1\right\}}}
\newcommand*{\ztrf}[1]{\ensuremath{\mathcal{Z} \left\{#1\right\}}}

\newcommand{\AxisRotator}[1][rotate=0]{%
    \tikz [x=0.2cm,y=0.60cm,line width=.1ex,-stealth,#1] \draw (0,0) arc (-150:150:1 and 1);%
}

\newcommand{\shift}{\ensuremath{\operatorname{q}}}
%\addtolength{\topmargin}{-1cm}
%\textheight 22.5cm
%\oddsidemargin 1.3cm
%\evensidemargin 1.3cm

\makeatletter
\newcommand*{\rom}[1]{\expandafter\@slowromancap\romannumeral #1@}
\makeatother

\newcommand*\circled[1]{\tikz[baseline=(char.base)]{
            \node[shape=circle,draw,inner sep=2pt] (char) {#1};}}

\pgfplotstableread[col sep=comma]{inputs.dat}\inputtable
\pgfplotstableread[col sep=comma]{responses.dat}\outputtable

\title{Computerized Control partial exam 1 (18\%)}
\author{Kjartan Halvorsen}
\date{}

\begin{document}

\maketitle

\begin{description}
\item[Time] September 12 19:05-20.35
\item[Place] 4203
\item[Permitted aids] The single colored page with your own notes, table of Laplace transforms, calculator
\end{description}

All answers should be readable and well motivated (if nothing else is written). Solutions/motivations should be written on the provided spaces in this exam. Use the last page if more space is needed.

\begin{center}
{\Large Good luck!} \\
\end{center}

\noindent
\fbox{
\bmpl
{\bf Matricula and name:}\\
\vspace*{14mm}
\emp}

%\clearpage

%-----------------------------------------------------------------

\subsection*{Control of a frictionless mechanical system}
Friction is ubiquous in mechanical systems, but can sometimes be neglected in a model. The textbook gives one such example: Control of the position of the arm of a hard disk drive. With the input signal $u(t)$ being the torque applied to the arm, $y(t)$ the angular position of the arm and $J$ its moment of inertia, the system is described by the differential equation
\begin{equation}
 J\ddot{y}(t) = u(t).
\label{eq:ode}
\end{equation}

\begin{center}
  \begin{tikzpicture}[node distance = 2cm]
    \node (image) {\includegraphics[width=0.36\textwidth]{../../figures/hard-drive.png}};

    \node[coordinate, right of=image, node distance=5cm] (input) {};
    \node[draw, right of=input] (block) {$G(s) = \frac{1}{Js^2}$};
    \node[coordinate, right of=block] (output) {};

    \draw[->] (input) -- node[above] {$u(t)$} (block);
    \draw[->] (block) -- node[above] {$y(t)$} (output);
  \end{tikzpicture}
\end{center}

\begin{exercise}

\abc
Show that zero-order-hold sampling of the model \eqref{eq:ode} gives the pulse-transfer function
\[ H(z) = \frac{\frac{h^2}{2J}(z+1)}{(z-1)^2}. \]

\noindent
\fbox{
\bmpl
{\bf Calculations:}\\
\vspace*{135mm}
\emp}

\abc State as a mathematical expression how the continuous-time poles (in the s-plane) and the corresponding discrete-time poles (in the z-plane) are related, and verify that the relationship holds in this particular case.

\noindent
\fbox{
\bmpl
{\bf Answer:}\\
\vspace*{30mm}
\emp}

\end{exercise}

\begin{exercise} % Lead filter
In the rest of the exam, consider the sampled system obtained with $J=0.5$ and sampling time $h=1$ (the time unit is \unit{100}{\micro\second}).
\[ H(z) = \frac{z+1}{(z-1)^2}. \]
The system is being controlled by the discrete-time controller
\begin{equation}
  U(z) = F(z)E(z) = 0.4\frac{z-0.8}{z-0.2}\big( Y_{ref}(z) - Y(z) \big).
  \label{eq:controller}
\end{equation}

\abc Draw a block-diagram of the closed-loop system

\noindent
\fbox{
\bmpl
{\bf Block diagram:}\\
\vspace*{40mm}
\emp}

\abc Show that the closed-loop pulse-transfer function from the reference signal $y_{ref}(k)$ to the control error $e(k)$ is
\begin{equation}
H_{e}(z) = \frac{(z-1)^2(z-0.2)}{(z-0.2)(z-1)^2 + 0.4(z-0.8)(z+1)}.
\label{eq:closedloop}
\end{equation}

\noindent
\fbox{
\bmpl
{\bf Calculations:}\\
\vspace*{80mm}
\emp}

\abc What is the gain of the pulse-transfer function $H_{e}(z)$ for constant signals? Explain what this means for the response of the system to a step change in $y_{ref}(k)$.

\noindent
\fbox{
\bmpl
{\bf Answer:}\\
\vspace*{40mm}
\emp}

\abc Write the control law \eqref{eq:controller} as a difference equation.

\noindent
\fbox{
\bmpl
{\bf Calculations:}\\
\vspace*{60mm}
\emp}

\end{exercise}

\begin{exercise}

\tikzset{plttype/.style={ycomb, thick, mark=*, mark options={red!60!black}}}
%\tikzset{plttype/.style={const plot, no marks, ultra thick}}

The closed-loop system with pulse-transfer function \eqref{eq:closedloop} has pulse-response as shown below
\begin{center}
\begin{tikzpicture}
\begin{axis}[
  width=14cm,
  height=6cm,
  xlabel={$k$},
  ylabel={$h_{e}(k)$},
  %axis lines=middle,
  %xmin=-.5,
  %xmax=6.5,
  %ymin = -2.5, ymax = 2.5,
  %xtick = {1,2,3,4,5,6},
]

\addplot[plttype] table[y = 5] from \outputtable;
\end{axis}
\end{tikzpicture}
\end{center}
Which of the responses in figure \ref{fig:responses}  is the reponse of the system when the reference signal $y_{ref}(k)$ is as shown below? \textbf{Motivate!}
\begin{center}
\begin{tikzpicture}
\begin{axis}[
  width=12cm,
  height=4cm,
  xlabel={$k$},
  ylabel={$y_{ref}(k)$},
  %axis lines=middle,
  %xmin=-.5,
  %xmax=6.5,
  %ymin = -2.5, ymax = 2.5,
  %xtick = {1,2,3,4,5,6},
]

\addplot[plttype] table[y = 1] from \inputtable;
\end{axis}
\end{tikzpicture}
\end{center}

\begin{figure}[h]
\begin{center}
\begin{tikzpicture}[node distance=2cm]

\begin{groupplot} [
    group style={
      group name=timeplot,
      group size=2 by 2,
      xlabels at=all,
      horizontal sep=2cm,
      vertical sep=2cm,
    },
    clip=false,
    height=4.3cm, width=8.3cm,
    axis line style={->},
    axis lines=left,
    xlabel={$k$ },
    ylabel={$e(k)$},
      %grid=both,
      % xtick=\empty,
      % ytick=\XNOLL,
      % yticklabel=$x_0$,
      ]
      \nextgroupplot
      \addplot[plttype] table[y = 3] from \outputtable ;
 \nextgroupplot
\addplot[plttype] table[y = 1] from \outputtable;
 \nextgroupplot
\addplot[plttype] table[y = 2] from \outputtable ;
 \nextgroupplot
\addplot[plttype] table[y = 4] from \outputtable ;
\end{groupplot}

\node[red!80!black!90] at ($ (timeplot c1r1.north) + (5mm, -5mm) $) {\huge \rom{1}};
\node[red!80!black!90] at ($ (timeplot c1r2.north) + (5mm, -5mm) $) {\huge \rom{2}};
\node[red!80!black!90] at ($ (timeplot c2r1.north) + (5mm, -5mm) $) {\huge \rom{3}};
\node[red!80!black!90] at ($ (timeplot c2r2.north) + (5mm, -5mm) $) {\huge \rom{4}};

  \end{tikzpicture}
  \caption{Responses to the closed-loop system.}
  \label{fig:responses}
\end{center}

\end{figure}

\noindent
\fbox{
\bmpl
{\bf Motivation:}\\
\vspace*{60mm}
\emp}

\end{exercise}

\cleardoublepage
%\end{document}

\section*{Solutions}
\setcounter{exerctr}{0}

\begin{exercise}
\abc The idea with zero-order-hold sampling (a.k.a~step-invariant sampling) is to solve the continuous-time system for a step input to obtain $y(t)$, then sample this signal and apply the z-transform to obtain $Y(z)$. Since the input signal (the step) has z-transform $U(z) = \frac{z}{z-1}$, we obtain the pulse-transfer function for the sampled system as $H(z) = \frac{Y(z)}{U(z)} = \frac{z-1}{z}Y(z)$.
\[ y(t) = \laplaceinv{\frac{1}{Js^3}} = \frac{1}{2J} t^2, \]
\[ Y(z) = \ztrf{y(kh)} = \ztrf{\frac{h^2}{2J}k^2} = \frac{h^2}{2J}\cdot \frac{z(z+1)}{(z-1)^3},\]
hence
\[ H(z) = \frac{Y(z)}{U(z)} = \frac{z-1}{z}\frac{h^2}{2J}\frac{z(z+1)}{(z-1)^3} = \frac{\frac{h^2}{2J}(z+1)}{(z-1)^2}.\]

\abc A pole $\lambda$ in the s-plane will be mapped to the pole $p=\mathrm{e}^{\lambda h}$ in the z-plane. Here we have two poles in the origin in the s-plane, $\lambda=0$, and so both the poles are mapped to the point $p=\mathrm{e}^{0h}=1$ in the z-plane.

\end{exercise}

\begin{exercise}

\abc
\begin{center}
  \begin{tikzpicture}[node distance = 2cm]
    \node[coordinate, ] (refinput) {};
    \node[circle, draw, inner sep=1pt, right of=refinput] (sum) {\small $\Sigma$};
    \node[draw, right of=sum, minimum height=12mm, minimum width=16mm] (controller) {$F(z)$};
    \node[draw, right of=controller, minimum height=12mm, minimum width=16mm, node distance=3cm] (plant) {$H(z)$};
    \node[coordinate, right of=plant] (measure) {};
    \node[coordinate, right of=measure,  node distance=14mm] (output) {};

    \draw[->] (refinput) -- node[above, near start] {$y_{ref}$} (sum);
    \draw[->] (controller) -- node[above] {$u$} (plant);
    \draw[->] (sum) -- node[above] {$e$} (controller);
    \draw[->] (plant) -- node[above, near end] {$y$} (output);
    \draw[->] (measure) -- ++(0cm, -15mm) -| node[left, pos=0.95] {$-$} (sum);

  \end{tikzpicture}
\end{center}

\abc
Using Mason's rule we get
\[ H_e(z) = \frac{1}{1 + H(z)F(z)} = \frac{1}{1 + 0.4\frac{z-0.8}{z-0.2}\frac{z+1}{(z-1)^2}} = \frac{(z-0.2)(z-1)^2}{(z-0.2)(z-1)^2 + 0.4(z-0.8)(z+1)}.\]

\abc
The static gain is $H_e(1) = 0$. So a step-change in $y_{ref}$ will give no steady-state error.

\abc
Using the shift operator \shift, we can write the control law as
\[ u(k) = 0.4\frac{\shift-0.8}{\shift-0.2}e(k)\]
\[ (\shift -0.2) u(k) = 0.4(\shift -0.8) e(k)\]
\[ u(k+1) - 0.2u(k) = 0.4e(k+1) - 0.32e(k)\]
\[ u(k+1) = 0.2u(k) + 0.4e(k+1) - 0.32e(k),\]
with $e(k) = y_{ref}(k) - y(k)$.

\end{exercise}

\begin{exercise}
The correct response is \textbf{III}. The reference signal is a sum of two delayed and scaled pulses, and can be written $y_{ref}(k) = \delta(k-4) + 0.3\delta(k-14)$. Correspondingly, the output should look like the superposition of two delayed and scaled pulse-responses. Responses I and IV starts at the wrong time, and can be excluded. Response II starts at $k=4$, and starts out looking correct. However, the superposed pulse response starting at $k=14$ is negative. This leaves response III as the correct response.

\end{exercise}

\end{document}


text:
\chapter{Nilpotent Groups and Frattini Subgroup}
\section{Series}
{\bf Definition of lower central series:} $G^{(0)}=G$, $G^{(n+1)} = [G^{(n)},G]$.
\\
\\
{\bf Definition 1:} $G$ is {\bf nilpotent} if
$G^{(n)}=1$ for some $n$.  Note $G^{(n)}/G^{(n+1)} \subseteq {\mathbb Z}(G/G^{(n+1)})$.
\\
\\
{\bf Definition of upper central series:}
$G^{[0]}=1$. Define $G^{[n+1]}= $ preimage of ${\mathbb Z}(G/G^{[n]})$.
\\
\\
{\bf Definition 2:}
A normal series, $N_k \subseteq N_{k-1} \subseteq  \ldots \subseteq N_1 = G$,
is \emph{central} if $[N_i , G] \subseteq N_{i+1}$.
\\
\\
{\bf Theorem 1:}  Let $G$ be a finite group, the following are equivalent:
(1) $G$ has a central series which reaches $1$;
(2) $G^{(n)} = 1$ for some $n$;
(3) $G^{[n]} = G$ for some $n$;
(4) $N_G(H) > H$ if $H \ne G$;
(5) Every maximal subgroup of $G$ is normal in $G$ and the quotient group has index $p$;
(6) Every Sylow subgroup of $G$ is normal in $G$.  When these hold, we say $G$ is
\emph {nilpotent}.
\begin{quote}
\emph{Proof $1 \rightarrow 2$:}
Let $G=N_0 \supseteq N_1 \supseteq \ldots \supseteq N_n$ with $[G, N_i] \subseteq N_{i+1}$.
$G^{(0)} \subseteq N_0$ and $G^{(i+1)}= [G^{(i)}, G] \subseteq [N_i, G] \subseteq N_{i+1}$
so $G^{(n)}=1$.
\\
\\
\emph{Proof $2 \rightarrow 3$:}
We prove that $G^{[n-i]} \supseteq G^{(i)}$, $G^{(0)}=G=G^{[n]}$ and $G^{(n)}=1=G^{[0]}$.
\\
\\
\emph{Proof $3 \rightarrow 4$:}
$\exists i$ such that $G^{[i]} \subseteq H$ and $G^{[i+1]} \nsubseteq H$.  Then
$G^{[i+1]}, G] \subseteq G^{[i]} \subseteq H$ and there is a $x \in G^{[i+1]}$,
$x \notin H$ with $xHx^{-1}=H$.
\\
\\
\emph{Proof $4 \rightarrow 5$:}
Let $M$ be a maximal subgroup.  $N_G(M) > M$ so $G= N_G(M)$.
\\
\\
\emph{Proof $5 \rightarrow 6$:}
Let $M$ be a maximal subgroup containing $N_G(P)$, $P \in S_p(G)$ then $M \lhd G$ and
by Frattini, $G= M N_G(P)= N_G(P)$.
\\
\\
\emph{Proof $6 \rightarrow 1$:}
Let $P_1, P_2, \ldots, P_n$ be the Sylow subgroups and put $H= P_1 P_2 \ldots P_n$,
$H \lhd G$.  Put $G^*= [P_1, G]= [P_1, P_1] \ne P_1$ and consider
$G \supseteq G^*$.  $G^*$ has a central series by induction.
\end{quote}
{\bf Corrollary:}  If $G$ is nilpotent, $G= \bigoplus_{p \mid |G|} O_p(G)$ and
$O_p(G)$ is a Sylow subgroup of $G$.
\section{Frattini Subgroup}
{\bf Lemma:} Let $1 \ne H \lhd G$ and $J$, a $p$-group in $H$.  If $|H| \neq 1 \jmod{p}$ then
$H \cap C_G(J) \neq 1$.
\begin{quote}
\end{quote}
{\bf Theorem 2:} If $G$ is nilpotent and $1 \ne H \lhd G$ then (1) $[H,G] \nsubseteq H$ and
(2) $1 \ne H \cap {\mathbb Z}(G)$.
\begin{quote}
\emph{Proof:} (1) If $[H,G]=H$ then $[H, G, G, \ldots, G]=H$. (2) Count!
\end{quote}
{\bf Definition 3:} $\Phi(G)= \bigcap_{M \in {\cal M}(G)} M$ where ${\cal M}(G)$ is the set of
maximal subgroups of $G$.
It is called the \emph {Frattini subgroup} of $G$.
\\
\\
{\bf Theorem 3:}
$\Phi(G) \; char \; G$; further,
(1) $\Phi(G)$ is nilpotent. (2)
$F(G)/\Phi(G)= F(G/\Phi(G))$.
\begin{quote}
\emph{Proof:}
Automorphisms, $\phi$, and their inverses take maximal subgroups in $G$ so
$ \bigcap_{M \in {\cal M}} M = \bigcap_{M \in {\cal M}} \phi(M)= \Phi(G)$.
Let $P \in S_p(\Phi(G))$.  Since $\Phi(G) \lhd G$, $G= \langle \Phi(G), N_G(P) \rangle = N_G(P)$ and so
$P \lhd G$ so $\Phi(G)$ is nilpotent.  (2) follows from (1).
\end{quote}
{\bf Theorem 4:} If $G$ is nilpotent, $G' \subseteq \Phi(G)$.
\begin{quote}
\emph{Proof:}  Suppose $G$ is nilpotent and $M$ is a maximal subgroup of $G$.
$N_G(M)>M$ so $M \lhd G$.  If $1 \ne a \in G/M$, $ \langle a, M \rangle = G$ so $G/M$ is cyclic and
$G' \subseteq M$.  This is true for every $M$ so $G' \subseteq \Phi(G)$.
\end{quote}
{\bf Theorem 4:} $G$ is nilpotent iff it is solvable and $p$-closed $\forall p$.
\begin{quote}
\emph{Proof:} If $G$ is nilpotent, $O_p(G) = P \in S_p(G)$ and $G= \bigotimes_{p \mid |G|} O_{p_i}(G)$ and the result follows.
The reverse inclusion goes by induction $G$ is solvable, $O_p(G) \neq 1$, some $p$, applying induction to ${\overline G}=
G/O_p(G)$ gives the result.
\end{quote}
{\bf Theorem 5:} If $\Phi(G)$ and ${\overline G}= G/\Phi(G)$ are nilpotent then so is $G$.
\begin{quote}
\emph{Proof:} Let ${\overline P} \in S_p({\overline G})$ then ${\overline P} \lhd {\overline G}$.
Put $N= P \Phi(G) \lhd G$.
By Frattini, $P \in S_p(G) \rightarrow N_G(P)N= N_G(P) \Phi(G)= N_G(P)$.
\end{quote}
{\bf Theorem 6:} $\Phi(G) \subseteq F(G)$.
\begin{quote}
\emph{Proof:} $\Phi(G)$ is nilpotent and so is $F(G)$ and so is their product.  Since
$F(G)$ is maximal, this product is in $F(G)$.
\end{quote}
{\bf Theorem 7:} If $P$ is a $p$-group then ${\overline P}= P/\Phi(P)$ is elementary abelian.  It
is the smallest such subgroup with this property.
\begin{quote}
\emph{Proof:}  Suppose $M$ is maximal in $P$.  As above, $M \lhd P$ and $P' \subseteq M$.
Suppose ${\overline x} \in {\overline P}$.  $|x|= p^m$ and there is a the characteristic
subgroup $N$ of $P$ with index $p$ must be in $M$ (otherwise $P=NM$).
Thus $xM$ has order $p$.  This is
true for all $M$ so ${\overline x}$ has order $p$ and as noted ${\overline P}$ is abelian so
it is elemenetary abelian.
\end{quote}
{\bf Theorem 8:} $\Phi(G/N)= \Phi(G)N/N$.
\begin{quote}
\emph{Proof:} Let ${\overline A}= A/N$, $N \lhd G$.  Maximal subgroups of ${\overline G}$ are
the maximal subgroups of $G$ containing $N$.
\end{quote}
{\bf Theorem 9:} If $S \subseteq G$ and $ \langle S, \Phi(G) \rangle =G$ then $ \langle S \rangle
=G$.
\begin{quote}
\emph{Proof:}  Suppose $ \langle S \rangle
=H < G$. Let  $M$ be a maximal subgroup containing $H$.
$\Phi(G) \subseteq M$, so $ \langle \Phi(G), S \rangle \subseteq H \ne G$.  Contradiction.
\end{quote}


text:
\chapter{Dual Ascent}\label{ch:dualascent}

The dual ascent algorithm is the dual version for the problem of the minimum
\emph{Steiner} tree, which tries to find a directed subtree that connects a root
node to a selected subset of existing nodes called \emph{target} nodes. While in
the Steiner tree the purpose is to minimize the total cost of the links used in
the resulting broadcast tree, in the dual ascent version the goal is to maximize
the flow, which is flowing from node 1 to all other nodes. Both versions find
the same lower bound for the optimal solution, according to the mathematical
definition of a dual problem.

The minimum Steiner tree problem is defined as in \eqref{eq:primalproblem}.

\begin{equation}\label{eq:primalproblem}
	\begin{cases}
		\min\sum\limits_{(i,j) \in E} c_{ij}y_{ij}\\[10pt]
		\sum\limits_{h \in N} x_{ih}^k - \sum\limits_{j \in N} x_{ji}^k
		=
		\begin{cases}
			1 & i = 1\\
			-1 & i = k\\
			0 & i \neq 1,k\\
		\end{cases}\\[10pt]
		x_{ij}^k \leq y_{ij}\\[10pt]
		x_{ij}^k \geq 0 \qquad \forall (i,j) \in E, \forall k \in
		V\\[10pt]
		y_{ij} \in \{0, 1\}
	\end{cases}
\end{equation}
%\begin{equation}\label{eq:primalproblem}
%	\begin{cases}
%		\min\sum\limits_{(i,j) \in E} c_{ij}y_{ij}\\
%		\sum\limits_{i \in N_1} \sum\limits_{j \in \overline{N_1}}
%		y_{ij} \geq 1 & \forall N_1 \subseteq N : 1 \in N_1\
%		\mathrm{and}\ N_1 \cap V \neq \emptyset\\
%		y_{ij} \in \{0, 1\}
%	\end{cases}
%\end{equation}

Where \(E\) is the set of links; \(c_{ij}\) are the costs of the complete graph
for the link that goes from the node i to the node j; \(y_{ij}\) is a binary
variable which tells if the arc (i, j) is taken into the solution; \(x_{ij}^k\)
is a variable represents the amount of flow between node 1 and node k that flows
on the (i, j) arc; \(N\) is the whole set of nodes; \(V\) is the set of target
nodes.

From linear programming, we can derive the dual of the problem in
\eqref{eq:primalproblem}. This is shown in \eqref{eq:dualproblem}.

\begin{equation}\label{eq:dualproblem}
	\begin{cases}
		\max\sum\limits_{k \in V} R_k^k\\[10pt]
		R_j^k - R_i^k - w_{ij}^k \leq 0 & k \in V\\[10pt]
		\sum\limits_{k \in V} w_{ij}^k \leq c_{ij} & (i, j) \in
		E\\[10pt]
		w_{ij}^k \geq 0
	\end{cases}
\end{equation}

Where \(R_i^k\) is the dual flow value computed as the flow that starts from
node 1 to node k passing through node i, selecting the node k as one of the root
component nodes (\(R_1^k\) is set to 0 because otherwise there is one redundant
equation) and \(w_{ij}^k\) is the maximum slack between the node i and the node
j. The slack value is initialized by computing the difference between the (i, j)
arc cost (\(c_{ij}\)) and the \(w_{ij}^k\) value, which is initialized to 0, so
it's the (i, j) arc cost. The slack value is updated in each algorithm's step by
decreasing it by the amount of slack on the arc with the minimum cost.

The dual ascent algorithm aims to solve the dual of the Steiner tree problem.

\input{dualascent/comparison}
\input{dualascent/algorithm}

max_stars_repo_name: SpeedJack/anaws

max_issues_repo_name: SpeedJack/anaws

max_forks_repo_name: SpeedJack/anaws


text:
\section{Tips and Hints}
\label{sec:tips:hints}

\subsection{Tips and Hints For Running PyLith}
\begin{itemize}
\item Examine the examples for a problem similar to the one you want to
run and dissect it in detail.
\item Start with a uniform-resolution coarse mesh to debug the problem setup.
Increase the resolution as necessary to resolve the solution fields
of interest (resolving stresses/strains may require a higher resolution
than that for resolving displacements).
\item Merge materials using the same material model. This will result in
only one VTK or HDF5 file for each material model rather than several
files.
\item The rate of convergence in quasi-static (implicit) problems can sometimes
be improved by renumbering the vertices in the finite-element mesh
to reduce the bandwidth of the sparse matrix. PyLith can use the reverse
Cuthill-McKee algorithm to reorder the vertices and cells.
\item If you encounter errors or warnings, run \filename{pylithinfo} or use
the \commandline{-{}-help}, \commandline{-{}-help-components}, and \commandline{-{}-help-properties}
command-line arguments when running PyLith to check the parameters
to make sure PyLith is using the parameters you intended.
\item Use the \commandline{-{}-petsc.log\_}view, \commandline{-{}-petsc.ksp\_monitor},
\commandline{-{}-petsc.ksp\_view}, \commandline{-{}-petsc.ksp\_converged\_reason}, and \commandline{-{}-petsc.snes\_converged\_reason}
command-line arguments (or set them in a parameter file) to view PyLith
performance and monitor the convergence.
\item Turn on the journals (see the examples) to monitor the progress of
the code.
\end{itemize}

\subsection{Troubleshooting}
\label{sec:Troubleshooting}

Consult the PyLith FAQ webpage (\url{https://wiki.geodynamics.org/software:pylith:help:hints})
which contains a growing list of common problems and their corresponding
solutions.

\subsubsection{Import Error and Missing Library}
\begin{shell}
ImportError: liblapack.so.2: cannot open shared object file: No such file or directory
\end{shell}

PyLith cannot find one of the libraries. You need to set up your environment
variables (e.g., PATH, PYTHONPATH, and LD\_LIBRARY\_PATH) to match
your installation. If you are using the PyLith binary on Linux or
Mac OS X, run the command \filename{source setup.sh }in the directory
where you unpacked the distribution. This will set up your environment
variables for you. If you are building PyLith from source, please
consult the instructions for building from source.

\subsubsection{Unrecognized Property 'p4wd'}

\begin{shell}
-- pyre.inventory(error) } \\
-- p4wd <- 'true' } \\
-- unrecognized property 'p4wd' } \\
>> command line:: } \\
-- pyre.inventory(error) } \\
-- p4pg <- 'true' } \\
-- unrecognized property ' p4pg'}
\end{shell}
Verify that the filename{mpirun} command included in the PyLith package is
the first one on your PATH: \filename{which mpirun}. If it is not, adjust your PATH environment variable accordingly.

\subsubsection{Detected zero pivor in LU factorization}

\begin{shell}
-- Solving equations.
[0] PETSC ERROR: ----------------
Error Message -------------------------------
[0] PETSC ERROR: Detected zero pivot in LU factorization
see http://www.mcs.anl.gov/petsc/petsc-as/documentation/faq.html\#ZeroPivot!
\end{shell}

This usually occurs when the null space of the system Jacobian is
nonzero, such as the case of a problem without Dirichlet boundary
conditions on any boundary. If this arises when using the split fields
and algebraic multigrid preconditioning, and no additional Dirichlet
boundary conditions are desired, then the workaround is to revert
to using the Additive Schwarz preconditioning without split fields
as discussed in Section \vref{sec:petsc:options}.

\subsubsection{Bus Error}

This often indicates that PyLith is using incompatible versions of
libraries. This can result from changing your environment variables
after configuring or installing PyLith (when building from source) or
from errors in setting the environment variables (\filename{PATH},
\filename{LD\_LIBRARY\_PATH}, and \filename{PYTHONPATH}). If the
former case, simply reconfigure and rebuild PyLith. In the latter
case, check your environment variables (order matters!) to make sure
PyLith finds the desired directories before system directories.

\subsubsection{Segmentation Fault}

A segmentation fault usually results from an invalid read/write to
memory. It might be caused by an error that wasn't trapped or a bug in
the code. Please report these cases so that we can fix these problems
(either trap the error and provide the user with an informative error
message, or fix the bug). If this occurs with any of the problems
distributed with PyLith, simply submit a bug report (see Section
\vref{sec:help}) indicating which problem you ran and your
platform. If the crash occurs for a problem you created, it is a great
help if you can try to reproduce the crash with a very simple problem
(e.g., adjust the boundary conditions or other parameters of one of
the examples to reproduce the segmentation fault). Submit a bug report
along with log files showing the backtrace from a debugger (e.g., gdb)
and the valgrind log file (only available on Linux platforms).  You
can generate a backtrace using the debugger by using the
\commandline{-{}-petsc.start\_in\_debugger} command-line argument:
\begin{shell}
$ pylith [..args..] --petsc.start_in_debugger
(gdb) continue
(gdb) backtrace
\end{shell}

To use valgrind to detect the memory error, first go to your working
directory and run the problem with \commandline{-{}-launcher.dry}:
\begin{shell}
$ pylith [..args..] --launcher.dry
\end{shell}

Instead of actually running the problem, this causes PyLith to dump
the mpirun/mpiexec command it will execute. Copy and paste this command
into your shell so you can run it directly. Insert the full path to
valgrind before the full path to mpinemesis and tell valgrind to use
a log file:
\begin{shell}
$ mpirun /path/to/valgrind --log-file=valgrind-log /path/to/mpinemesis --pyre-start
  [..lots of junk..]
\end{shell}

% End of file

max_stars_repo_name: joegeisz/pylith

max_issues_repo_name: joegeisz/pylith

max_forks_repo_name: joegeisz/pylith


text:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                                 %
%  GEANT manual in LaTeX form                              %
%                                                                 %
%  Michel Goossens (for translation into LaTeX)                   %
%  Version 1.00                                                   %
%  Last Mod. Jan 24 1991  1300   MG + IB                          %
%                                                                 %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\Origin{M. Hansroul}
\Version{Geant 3.16}\Routid{PHYS410}
\Submitted{01.09.76}    \Revised{16.12.93}
\Makehead{Rotations and Lorentz transformation}
\section{Subroutines}
\Shubr{GLOREN}{(BETA,PA,PB*)}
{\tt GLOREN} transforms the momentum and the energy from one
Lorentz frame (A) to another (B). It uses the following input and output:

\begin{DLtt}{MMMMMMMM}
\item[BETA(4)] ({\tt REAL}) velocity components in light units
of frame B in frame A,
{\tt BETA(1$\ldots$3) $ = \vec{\beta}$, BETA(4)$=(1-\beta^2)^{-1/2} =
\gamma$};
\item[PA(4)] ({\tt REAL}) momentum components in the frame (A);
\item[PB(4)] ({\tt REAL}) momentum components in the frame (B).
\end{DLtt}

{\tt GLOREN} is called from the routine {\tt GDECAY}.
The momentum $\vec{p}_A$ and energy $E_A$  in reference frame A are
transformed into the momentum $\vec{p}_B$ and energy $E_B$ in reference
frame B which translates with velocity $\vec{\beta}$ with respect
to A:
\begin{eqnarray*}
E_B        & = &\gamma (E_A - \vec{\beta}\cdot \vec{p}_A)\\
\vec{p}_B & = & \vec{p}_A +
\gamma \vec{\beta} \left(\frac{ \gamma \vec{\beta} \cdot \vec{p}_A}
{\gamma+1} - E_A \right)
\end{eqnarray*}

\Shubr{GDROT}{(P*,COSTH,SINTH,COSPH,SINPH)}
{\tt GDROT} rotates a vector from one reference system to another.

\begin{DLtt}{MMMMMMMM}
\item[P(3)] ({\tt REAL}) vector to rotate, overwritten on output;
\item[COSTH] ({\tt REAL}) cosine of the polar angle;
\item[SINTH] ({\tt REAL}) sine of the polar angle;
\item[COSPH] ({\tt REAL}) cosine of the azimuthal angle;
\item[SINPH] ({\tt REAL}) sine of the azimuthal angle;
\end{DLtt}

{\tt GDROT} is called from several routines to rotate a particle from
in the center-of-mass system to the {\tt GEANT} (laboratory) system.
The following rotation matrix is used:
\[ \left( \begin{array}{ccc}
\cos \theta \cos \phi & -\sin \phi   & \sin \theta \cos \phi \\
\cos \theta \sin \phi & \cos \phi    & \sin \theta \sin \phi \\
- \sin \theta         &  0           & \cos \theta
\end{array}  \right )
=
\underbrace{
\left( \begin{array}{ccc}
\cos \phi & -\sin \phi & 0 \\
\sin \phi & \cos \phi  & 0 \\
0         &      0     & 1
\end{array}  \right )}_{\Dstm R_\phi}
\underbrace{
\left( \begin{array}{ccc}
\cos \theta  & 0 & \sin \theta \\
0            & 1 & 0           \\
-\sin \theta & 0 & \cos \theta
\end{array}  \right )}_{\Dstm R_\theta} \]
$R_\theta$ is a counterclockwise rotation around axis $y$ by an angle $\theta$,
and $R_\phi$ is a counterclockwise rotation around axis $z'$ (rotated by an
angle $\theta$ from the initial position) by an angle $\phi$.

\Shubr{GFANG}{(P,COSTH*,SINTH*,COSPH*,SINPH*,ROTATE*)}
\begin{DLtt}{MMMMMMMM}
\item[P(3)] ({\tt REAL}) input direction;
\item[COSTH] ({\tt REAL}) cosine of the polar angle;
\item[SINTH] ({\tt REAL}) sine of the polar angle;
\item[COSPH] ({\tt REAL}) cosine of the azimuthal angle;
\item[SINPH] ({\tt REAL}) sine of the azimuthal angle;
\item[ROTATE] ({\tt LOGICAL}) rotation flag, the rotation matrix is the unit
matrix if {\tt ROTATE=.FALSE.}, i.e. no rotation is needed;
\end{DLtt}

Find the sine and cosine of the polar and azimuthal angle of the direction
defined by the vector {\tt P}. If {\tt P} is along the $z$ axis,
{\tt ROTATE=.FALSE.}.

\Shubr{GVROT}{(DCOSIN,PART*)}
\begin{DLtt}{MMMMMMMM}
\item[PART(3)] ({\tt REAL}) direction to be rotated, overwritten on output;
\item[DCOSIN(3)] ({\tt REAL}) direction of the new $z$ axis;
\end{DLtt}

Given the direction {\tt PART} in a system of reference $O$, it returns the
same direction in the system of reference where the $z$ axis of $O$ is
along {\tt DCOSIN}. This routine is very useful when the $\theta$
angle of a secondary particle is sampled in a reference frame where the
parent particle moves along the $z$ axis. Then the direction of the
secondary product in the {\tt MRS} is returned by \Rind{GVROT} if
{\tt DCOSIN} is the direction of the parent particle.

A call to \Rind{GVROT} is equivalent to the following code:
\begin{verbatim}
      DIMENSION PART(3), DCOSIN(3)
      LOGICAL ROTATE
      .
      .
      .
      CALL GFANG(DCOSIN,COSTH,SINTH,COSPH,SINPH,ROTATE)
      IF(ROTATE) CALL GDROT(PART,COSTH,SINTH,COSPH,SINPH)
\end{verbatim}

with the advantage that inside \Rind{GVROT} all calculations are performed
in double precision.

max_stars_repo_name: berghaus/cernlib-docs

max_issues_repo_name: berghaus/cernlib-docs

max_forks_repo_name: berghaus/cernlib-docs