| 257 |      1 | % !TEX program = xelatex
 | 
| 6 |      2 | \documentclass{article}
 | 
| 62 |      3 | \usepackage{../style}
 | 
| 78 |      4 | \usepackage{../langs}
 | 
| 218 |      5 | \usepackage{disclaimer}
 | 
|  |      6 | \usepackage{tikz}
 | 
|  |      7 | \usepackage{pgf}
 | 
|  |      8 | \usepackage{pgfplots}
 | 
|  |      9 | \usepackage{stackengine}
 | 
|  |     10 | %% \usepackage{accents}
 | 
|  |     11 | \newcommand\barbelow[1]{\stackunder[1.2pt]{#1}{\raisebox{-4mm}{\boldmath$\uparrow$}}}
 | 
|  |     12 | 
 | 
| 6 |     13 | 
 | 
|  |     14 | \begin{document}
 | 
|  |     15 | 
 | 
| 218 |     16 | % BF IDE
 | 
|  |     17 | % https://www.microsoft.com/en-us/p/brainf-ck/9nblgggzhvq5
 | 
|  |     18 |   
 | 
| 356 |     19 | \section*{Preliminary Part 3 (Scala, 3 Marks)}
 | 
| 6 |     20 | 
 | 
| 275 |     21 | \mbox{}\hfill\textit{``[Google’s MapReduce] abstraction is inspired by the}\\
 | 
|  |     22 | \mbox{}\hfill\textit{map and reduce primitives present in Lisp and many}\\
 | 
| 347 |     23 | \mbox{}\hfill\textit{other functional languages.''}\smallskip\\
 | 
| 284 |     24 | \mbox{}\hfill\textit{ --- Dean and Ghemawat, who designed this concept at Google}
 | 
| 347 |     25 | \bigskip
 | 
| 275 |     26 | 
 | 
| 347 |     27 | \IMPORTANT{This part is about the shunting yard algorithm by Dijkstra.
 | 
| 355 |     28 |   The preliminary part is due on \cwEIGHT{} at 5pm and worth 3\%.
 | 
|  |     29 |   Any 1\% you achieve in the preliminary part counts as your
 | 
|  |     30 |   ``weekly engagement''.}
 | 
| 62 |     31 | 
 | 
|  |     32 | \noindent
 | 
| 218 |     33 | Also note that the running time of each part will be restricted to a
 | 
| 257 |     34 | maximum of 30 seconds on my laptop.  
 | 
| 218 |     35 | 
 | 
|  |     36 | \DISCLAIMER{}
 | 
| 86 |     37 | 
 | 
| 221 |     38 | \subsection*{Reference Implementation}
 | 
|  |     39 | 
 | 
| 347 |     40 | This Scala assignment comes with two reference implementations in
 | 
|  |     41 | form of \texttt{jar}-files. This allows
 | 
|  |     42 | you to run any test cases on your own computer. For example you can
 | 
|  |     43 | call Scala on the command line with the option \texttt{-cp
 | 
|  |     44 |   postfix.jar} and then query any function from the
 | 
|  |     45 | \texttt{postfix.scala} file (similarly for file \texttt{postfix2.scala}). As
 | 
|  |     46 | usual you have to prefix the calls with \texttt{CW8a} and
 | 
|  |     47 | \texttt{CW8b}, respectively.
 | 
| 221 |     48 | 
 | 
|  |     49 | 
 | 
| 245 |     50 | \begin{lstlisting}[xleftmargin=1mm,numbers=none,basicstyle=\ttfamily\small]
 | 
| 347 |     51 | $ scala -cp postfix.jar
 | 
|  |     52 | 
 | 
|  |     53 | scala> CW8a.syard(CW8a.split("( 5 + 7 ) * 2"))
 | 
|  |     54 | val res0: CW8a.Toks = List(5, 7, +, 2, *)
 | 
| 221 |     55 | \end{lstlisting}%$
 | 
|  |     56 | 
 | 
| 6 |     57 | 
 | 
| 367 |     58 | \subsection*{Hints}
 | 
|  |     59 | 
 | 
|  |     60 | \noindent
 | 
|  |     61 | \textbf{For the Preliminary Part:} useful operations for determining
 | 
|  |     62 | whether a string is a number are \texttt{.forall} and \texttt{.isDigit}.
 | 
|  |     63 | One way to calculate the the power operation is to use \texttt{.pow}
 | 
|  |     64 | on \texttt{BigInt}s, like \texttt{BigInt(n).pow(m).toInt}.
 | 
|  |     65 | \bigskip
 | 
|  |     66 | 
 | 
|  |     67 | 
 | 
| 347 |     68 | \subsection*{Preliminary Part (3 Marks, files postfix.scala, postfix2.scala)}
 | 
| 284 |     69 | 
 | 
|  |     70 | The \emph{Shunting Yard Algorithm} has been developed by Edsger Dijkstra,
 | 
|  |     71 | an influential computer scientist who developed many well-known
 | 
|  |     72 | algorithms. This algorithm transforms the usual infix notation of
 | 
|  |     73 | arithmetic expressions into the postfix notation, sometimes also
 | 
|  |     74 | called reverse Polish notation.
 | 
|  |     75 | 
 | 
|  |     76 | Why on Earth do people use the postfix notation? It is much more
 | 
|  |     77 | convenient to work with the usual infix notation for arithmetic
 | 
| 347 |     78 | expressions. Most modern pocket calculators (as opposed to the ones used 20
 | 
| 284 |     79 | years ago) understand infix notation. So why on Earth? \ldots{}Well,
 | 
|  |     80 | many computers under the hood, even nowadays, use postfix notation
 | 
|  |     81 | extensively. For example if you give to the Java compiler the
 | 
|  |     82 | expression $1 + ((2 * 3) + (4 - 3))$, it will generate the Java Byte
 | 
|  |     83 | code
 | 
|  |     84 | 
 | 
|  |     85 | \begin{lstlisting}[language=JVMIS,numbers=none]
 | 
|  |     86 | ldc 1 
 | 
|  |     87 | ldc 2 
 | 
|  |     88 | ldc 3 
 | 
|  |     89 | imul 
 | 
|  |     90 | ldc 4 
 | 
|  |     91 | ldc 3 
 | 
|  |     92 | isub 
 | 
|  |     93 | iadd 
 | 
|  |     94 | iadd
 | 
|  |     95 | \end{lstlisting}
 | 
|  |     96 | 
 | 
|  |     97 | \noindent
 | 
|  |     98 | where the command \texttt{ldc} loads a constant onto the stack, and \texttt{imul},
 | 
|  |     99 | \texttt{isub} and \texttt{iadd} are commands acting on the stack. Clearly this
 | 
|  |    100 | is the arithmetic expression in postfix notation.\bigskip
 | 
|  |    101 | 
 | 
|  |    102 | \noindent
 | 
|  |    103 | The shunting yard algorithm processes an input token list using an
 | 
|  |    104 | operator stack and an output list. The input consists of numbers,
 | 
|  |    105 | operators ($+$, $-$, $*$, $/$) and parentheses, and for the purpose of
 | 
|  |    106 | the assignment we assume the input is always a well-formed expression
 | 
|  |    107 | in infix notation.  The calculation in the shunting yard algorithm uses
 | 
|  |    108 | information about the
 | 
|  |    109 | precedences of the operators (given in the template file). The
 | 
|  |    110 | algorithm processes the input token list as follows:
 | 
|  |    111 | 
 | 
|  |    112 | \begin{itemize}
 | 
|  |    113 | \item If there is a number as input token, then this token is
 | 
|  |    114 |   transferred directly to the output list. Then the rest of the input is
 | 
|  |    115 |   processed.
 | 
|  |    116 | \item If there is an operator as input token, then you need to check
 | 
|  |    117 |   what is on top of the operator stack. If there are operators with
 | 
|  |    118 |   a higher or equal precedence, these operators are first popped off
 | 
|  |    119 |   from the stack and moved to the output list. Then the operator from the input
 | 
|  |    120 |   is pushed onto the stack and the rest of the input is processed.
 | 
|  |    121 | \item If the input is a left-parenthesis, you push it on to the stack
 | 
|  |    122 |   and continue processing the input.
 | 
|  |    123 | \item If the input is a right-parenthesis, then you pop off all operators
 | 
|  |    124 |   from the stack to the output list until you reach the left-parenthesis.
 | 
|  |    125 |   Then you discharge the $($ and $)$ from the input and stack, and continue
 | 
|  |    126 |   processing the input list.
 | 
|  |    127 | \item If the input is empty, then you move all remaining operators
 | 
|  |    128 |   from the stack to the output list.  
 | 
|  |    129 | \end{itemize}  
 | 
|  |    130 | 
 | 
|  |    131 | \subsubsection*{Tasks (file postfix.scala)}
 | 
|  |    132 | 
 | 
|  |    133 | \begin{itemize}
 | 
|  |    134 | \item[(1)] Implement the shunting yard algorithm described above. The
 | 
|  |    135 |   function, called \texttt{syard}, takes a list of tokens as first
 | 
|  |    136 |   argument. The second and third arguments are the stack and output
 | 
|  |    137 |   list represented as Scala lists. The most convenient way to
 | 
|  |    138 |   implement this algorithm is to analyse what the input list, stack
 | 
|  |    139 |   and output list look like in each step using pattern-matching. The
 | 
|  |    140 |   algorithm transforms for example the input
 | 
|  |    141 | 
 | 
|  |    142 |   \[
 | 
|  |    143 |   \texttt{List(3, +, 4, *, (, 2, -, 1, ))}
 | 
|  |    144 |   \]
 | 
|  |    145 | 
 | 
|  |    146 |   into the postfix output
 | 
|  |    147 | 
 | 
|  |    148 |   \[
 | 
|  |    149 |   \texttt{List(3, 4, 2, 1, -, *, +)}
 | 
|  |    150 |   \]  
 | 
|  |    151 |   
 | 
|  |    152 |   You can assume the input list is always a  list representing
 | 
|  |    153 |   a well-formed infix arithmetic expression.\hfill[1 Mark]
 | 
|  |    154 | 
 | 
|  |    155 | \item[(2)] Implement a compute function that takes a postfix expression
 | 
|  |    156 |   as argument and evaluates it generating an integer as result. It uses a
 | 
|  |    157 |   stack to evaluate the postfix expression. The operators $+$, $-$, $*$
 | 
|  |    158 |   are as usual; $/$ is division on integers, for example $7 / 3 = 2$.
 | 
|  |    159 |   \hfill[1 Mark]
 | 
|  |    160 | \end{itemize}
 | 
|  |    161 | 
 | 
|  |    162 | \subsubsection*{Task (file postfix2.scala)}
 | 
|  |    163 | 
 | 
|  |    164 | \begin{itemize}
 | 
| 347 |    165 | \item[(3/4)] Extend the code in (1) and (2) to include the power
 | 
| 284 |    166 |   operator.  This requires proper account of associativity of
 | 
|  |    167 |   the operators. The power operator is right-associative, whereas the
 | 
|  |    168 |   other operators are left-associative.  Left-associative operators
 | 
|  |    169 |   are popped off if the precedence is bigger or equal, while
 | 
|  |    170 |   right-associative operators are only popped off if the precedence is
 | 
| 347 |    171 |   bigger.\hfill[1 Marks]
 | 
| 284 |    172 | \end{itemize}
 | 
|  |    173 | 
 | 
| 6 |    174 | \end{document}
 | 
|  |    175 | 
 | 
| 68 |    176 | 
 | 
| 6 |    177 | %%% Local Variables: 
 | 
|  |    178 | %%% mode: latex
 | 
|  |    179 | %%% TeX-master: t
 | 
|  |    180 | %%% End: 
 |