| author | Christian Urban <urbanc@in.tum.de> | 
| Fri, 24 Nov 2017 01:26:01 +0000 | |
| changeset 154 | e7f8e3d2e09a | 
| parent 153 | 316f9c6cc2ff | 
| child 155 | eccf17f56922 | 
| permissions | -rw-r--r-- | 
| 6 | 1  | 
\documentclass{article}
 | 
| 62 | 2  | 
\usepackage{../style}
 | 
| 78 | 3  | 
\usepackage{../langs}
 | 
| 153 | 4  | 
\usepackage{tikz}
 | 
5  | 
\usepackage{pgf}
 | 
|
6  | 
\usepackage{pgfplots}
 | 
|
| 154 | 7  | 
\usepackage{stackengine}
 | 
8  | 
%%\usepackage{accents}
 | 
|
9  | 
\newcommand\barbelow[1]{\stackunder[1.2pt]{#1}{\raisebox{-4mm}{\boldmath$\uparrow$}}}
 | 
|
| 153 | 10  | 
|
11  | 
\begin{filecontents}{re-python2.data}
 | 
|
12  | 
1 0.033  | 
|
13  | 
5 0.036  | 
|
14  | 
10 0.034  | 
|
15  | 
15 0.036  | 
|
16  | 
18 0.059  | 
|
17  | 
19 0.084  | 
|
18  | 
20 0.141  | 
|
19  | 
21 0.248  | 
|
20  | 
22 0.485  | 
|
21  | 
23 0.878  | 
|
22  | 
24 1.71  | 
|
23  | 
25 3.40  | 
|
24  | 
26 7.08  | 
|
25  | 
27 14.12  | 
|
26  | 
28 26.69  | 
|
27  | 
\end{filecontents}
 | 
|
28  | 
||
29  | 
\begin{filecontents}{re-java.data}
 | 
|
30  | 
5 0.00298  | 
|
31  | 
10 0.00418  | 
|
32  | 
15 0.00996  | 
|
33  | 
16 0.01710  | 
|
34  | 
17 0.03492  | 
|
35  | 
18 0.03303  | 
|
36  | 
19 0.05084  | 
|
37  | 
20 0.10177  | 
|
38  | 
21 0.19960  | 
|
39  | 
22 0.41159  | 
|
40  | 
23 0.82234  | 
|
41  | 
24 1.70251  | 
|
42  | 
25 3.36112  | 
|
43  | 
26 6.63998  | 
|
44  | 
27 13.35120  | 
|
45  | 
28 29.81185  | 
|
46  | 
\end{filecontents}
 | 
|
47  | 
||
| 6 | 48  | 
|
49  | 
\begin{document}
 | 
|
50  | 
||
| 154 | 51  | 
|
52  | 
\section*{Coursework 8 (Regular Expressions and Brainf***)}
 | 
|
| 6 | 53  | 
|
| 79 | 54  | 
This coursework is worth 10\%. It is about regular expressions,  | 
| 153 | 55  | 
pattern matching and an interpreter. The first part is due on 30  | 
| 152 | 56  | 
November at 11pm; the second, more advanced part, is due on 21  | 
| 153 | 57  | 
December at 11pm. In the first part, you are asked to implement a  | 
58  | 
regular expression matcher based on derivatives of regular  | 
|
59  | 
expressions. The reason is that regular expression matching in Java  | 
|
60  | 
can sometimes be extremely slow. The advanced part is about an  | 
|
61  | 
interpreter for a very simple programming language.\bigskip  | 
|
| 62 | 62  | 
|
63  | 
\noindent  | 
|
| 152 | 64  | 
\textbf{Important:}
 | 
65  | 
||
66  | 
\begin{itemize}
 | 
|
67  | 
\item Make sure the files you submit can be processed by just calling\\  | 
|
68  | 
  \mbox{\texttt{scala <<filename.scala>>}} on the commandline. Use the
 | 
|
69  | 
template files provided and do not make any changes to arguments of  | 
|
70  | 
functions or to any types. You are free to implement any auxiliary  | 
|
71  | 
function you might need.  | 
|
72  | 
||
73  | 
\item Do not use any mutable data structures in your  | 
|
74  | 
submissions! They are not needed. This means you cannot create new  | 
|
75  | 
\texttt{Array}s or \texttt{ListBuffer}s, for example. 
 | 
|
| 86 | 76  | 
|
| 152 | 77  | 
\item Do not use \texttt{return} in your code! It has a different
 | 
78  | 
meaning in Scala, than in Java.  | 
|
79  | 
||
80  | 
\item Do not use \texttt{var}! This declares a mutable variable. Only
 | 
|
81  | 
  use \texttt{val}!
 | 
|
82  | 
||
83  | 
\item Do not use any parallel collections! No \texttt{.par} therefore!
 | 
|
84  | 
Our testing and marking infrastructure is not set up for it.  | 
|
85  | 
\end{itemize}
 | 
|
86  | 
||
87  | 
\noindent  | 
|
88  | 
Also note that the running time of each part will be restricted to a  | 
|
89  | 
maximum of 360 seconds on my laptop  | 
|
| 6 | 90  | 
|
91  | 
||
| 110 | 92  | 
\subsection*{Disclaimer}
 | 
| 6 | 93  | 
|
94  | 
It should be understood that the work you submit represents  | 
|
| 68 | 95  | 
your own effort! You have not copied from anyone else. An  | 
| 6 | 96  | 
exception is the Scala code I showed during the lectures or  | 
97  | 
uploaded to KEATS, which you can freely use.\bigskip  | 
|
98  | 
||
99  | 
||
| 68 | 100  | 
\subsection*{Part 1 (6 Marks)}
 | 
| 6 | 101  | 
|
| 69 | 102  | 
The task is to implement a regular expression matcher that is based on  | 
| 153 | 103  | 
derivatives of regular expressions. Most of the functions are defined by  | 
104  | 
recursion over regular expressions and can be elegantly implemented  | 
|
105  | 
using Scala's pattern-matching. The implementation should deal with the  | 
|
106  | 
following regular expressions, which have been predefined in the file  | 
|
107  | 
\texttt{re.scala}:
 | 
|
| 6 | 108  | 
|
109  | 
\begin{center}
 | 
|
110  | 
\begin{tabular}{lcll}
 | 
|
111  | 
$r$ & $::=$ & $\ZERO$ & cannot match anything\\  | 
|
112  | 
& $|$ & $\ONE$ & can only match the empty string\\  | 
|
| 68 | 113  | 
& $|$ & $c$ & can match a character (in this case $c$)\\  | 
114  | 
& $|$ & $r_1 + r_2$ & can match a string either with $r_1$ or with $r_2$\\  | 
|
115  | 
& $|$ & $r_1\cdot r_2$ & can match the first part of a string with $r_1$ and\\  | 
|
116  | 
& & & then the second part with $r_2$\\  | 
|
| 6 | 117  | 
& $|$ & $r^*$ & can match zero or more times $r$\\  | 
118  | 
\end{tabular}
 | 
|
119  | 
\end{center}
 | 
|
120  | 
||
| 68 | 121  | 
\noindent  | 
| 152 | 122  | 
Why? Knowing how to match regular expressions and strings will let you  | 
123  | 
solve a lot of problems that vex other humans. Regular expressions are  | 
|
124  | 
one of the fastest and simplest ways to match patterns in text, and  | 
|
125  | 
are endlessly useful for searching, editing and analysing data in all  | 
|
126  | 
sorts of places (for example analysing network traffic in order to  | 
|
127  | 
detect security breaches). However, you need to be fast, otherwise you  | 
|
128  | 
will stumble over problems such as recently reported at  | 
|
| 68 | 129  | 
|
130  | 
{\small
 | 
|
131  | 
\begin{itemize}
 | 
|
132  | 
\item[$\bullet$] \url{http://stackstatus.net/post/147710624694/outage-postmortem-july-20-2016}
 | 
|
133  | 
\item[$\bullet$] \url{https://vimeo.com/112065252}
 | 
|
134  | 
\item[$\bullet$] \url{http://davidvgalbraith.com/how-i-fixed-atom/}  
 | 
|
135  | 
\end{itemize}}
 | 
|
136  | 
||
| 79 | 137  | 
\subsubsection*{Tasks (file re.scala)}
 | 
| 68 | 138  | 
|
139  | 
\begin{itemize}
 | 
|
| 152 | 140  | 
\item[(1a)] Implement a function, called \textit{nullable}, by
 | 
141  | 
recursion over regular expressions. This function tests whether a  | 
|
| 153 | 142  | 
regular expression can match the empty string. This means given a  | 
| 152 | 143  | 
regular expression it either returns true or false.  | 
| 6 | 144  | 
|
145  | 
\begin{center}
 | 
|
146  | 
\begin{tabular}{lcl}
 | 
|
147  | 
$\textit{nullable}(\ZERO)$ & $\dn$ & $\textit{false}$\\
 | 
|
148  | 
$\textit{nullable}(\ONE)$  & $\dn$ & $\textit{true}$\\
 | 
|
149  | 
$\textit{nullable}(c)$     & $\dn$ & $\textit{false}$\\
 | 
|
150  | 
$\textit{nullable}(r_1 + r_2)$ & $\dn$ & $\textit{nullable}(r_1) \vee \textit{nullable}(r_2)$\\
 | 
|
151  | 
$\textit{nullable}(r_1 \cdot r_2)$ & $\dn$ & $\textit{nullable}(r_1) \wedge \textit{nullable}(r_2)$\\
 | 
|
152  | 
$\textit{nullable}(r^*)$ & $\dn$ & $\textit{true}$\\
 | 
|
153  | 
\end{tabular}
 | 
|
| 68 | 154  | 
\end{center}\hfill[1 Mark]
 | 
155  | 
||
156  | 
\item[(1b)] Implement a function, called \textit{der}, by recursion over
 | 
|
157  | 
regular expressions. It takes a character and a regular expression  | 
|
| 69 | 158  | 
as arguments and calculates the derivative regular expression according  | 
159  | 
to the rules:  | 
|
| 6 | 160  | 
|
161  | 
\begin{center}
 | 
|
162  | 
\begin{tabular}{lcl}
 | 
|
163  | 
$\textit{der}\;c\;(\ZERO)$ & $\dn$ & $\ZERO$\\
 | 
|
164  | 
$\textit{der}\;c\;(\ONE)$  & $\dn$ & $\ZERO$\\
 | 
|
165  | 
$\textit{der}\;c\;(d)$     & $\dn$ & $\textit{if}\; c = d\;\textit{then} \;\ONE \; \textit{else} \;\ZERO$\\
 | 
|
166  | 
$\textit{der}\;c\;(r_1 + r_2)$ & $\dn$ & $(\textit{der}\;c\;r_1) + (\textit{der}\;c\;r_2)$\\
 | 
|
167  | 
$\textit{der}\;c\;(r_1 \cdot r_2)$ & $\dn$ & $\textit{if}\;\textit{nullable}(r_1)$\\
 | 
|
168  | 
      & & $\textit{then}\;((\textit{der}\;c\;r_1)\cdot r_2) + (\textit{der}\;c\;r_2)$\\
 | 
|
169  | 
      & & $\textit{else}\;(\textit{der}\;c\;r_1)\cdot r_2$\\
 | 
|
170  | 
$\textit{der}\;c\;(r^*)$ & $\dn$ & $(\textit{der}\;c\;r)\cdot (r^*)$\\
 | 
|
171  | 
\end{tabular}
 | 
|
| 69 | 172  | 
\end{center}
 | 
173  | 
||
174  | 
For example given the regular expression $r = (a \cdot b) \cdot c$, the derivatives  | 
|
175  | 
w.r.t.~the characters $a$, $b$ and $c$ are  | 
|
176  | 
||
177  | 
\begin{center}
 | 
|
178  | 
  \begin{tabular}{lcll}
 | 
|
179  | 
    $\textit{der}\;a\;r$ & $=$ & $(\ONE \cdot b)\cdot c$ & ($= r'$)\\
 | 
|
180  | 
    $\textit{der}\;b\;r$ & $=$ & $(\ZERO \cdot b)\cdot c$\\
 | 
|
181  | 
    $\textit{der}\;c\;r$ & $=$ & $(\ZERO \cdot b)\cdot c$
 | 
|
182  | 
  \end{tabular}
 | 
|
183  | 
\end{center}
 | 
|
184  | 
||
185  | 
Let $r'$ stand for the first derivative, then taking the derivatives of $r'$  | 
|
186  | 
w.r.t.~the characters $a$, $b$ and $c$ gives  | 
|
187  | 
||
188  | 
\begin{center}
 | 
|
189  | 
  \begin{tabular}{lcll}
 | 
|
190  | 
    $\textit{der}\;a\;r'$ & $=$ & $((\ZERO \cdot b) + \ZERO)\cdot c$ \\
 | 
|
191  | 
    $\textit{der}\;b\;r'$ & $=$ & $((\ZERO \cdot b) + \ONE)\cdot c$ & ($= r''$)\\
 | 
|
192  | 
    $\textit{der}\;c\;r'$ & $=$ & $((\ZERO \cdot b) + \ZERO)\cdot c$
 | 
|
193  | 
  \end{tabular}
 | 
|
194  | 
\end{center}
 | 
|
195  | 
||
196  | 
One more example: Let $r''$ stand for the second derivative above,  | 
|
197  | 
then taking the derivatives of $r''$ w.r.t.~the characters $a$, $b$  | 
|
198  | 
and $c$ gives  | 
|
199  | 
||
200  | 
\begin{center}
 | 
|
201  | 
  \begin{tabular}{lcll}
 | 
|
202  | 
    $\textit{der}\;a\;r''$ & $=$ & $((\ZERO \cdot b) + \ZERO) \cdot c + \ZERO$ \\
 | 
|
203  | 
    $\textit{der}\;b\;r''$ & $=$ & $((\ZERO \cdot b) + \ZERO) \cdot c + \ZERO$\\
 | 
|
| 152 | 204  | 
    $\textit{der}\;c\;r''$ & $=$ & $((\ZERO \cdot b) + \ZERO) \cdot c + \ONE$ &
 | 
205  | 
    (is $\textit{nullable}$)                      
 | 
|
| 69 | 206  | 
  \end{tabular}
 | 
207  | 
\end{center}
 | 
|
208  | 
||
209  | 
Note, the last derivative can match the empty string, that is it is \textit{nullable}.\\
 | 
|
210  | 
\mbox{}\hfill\mbox{[1 Mark]}
 | 
|
| 6 | 211  | 
|
| 68 | 212  | 
\item[(1c)] Implement the function \textit{simp}, which recursively
 | 
| 69 | 213  | 
traverses a regular expression from the inside to the outside, and  | 
| 153 | 214  | 
on the way simplifies every regular expression on the left (see  | 
215  | 
below) to the regular expression on the right, except it does not  | 
|
216  | 
  simplify inside ${}^*$-regular expressions.
 | 
|
| 6 | 217  | 
|
| 68 | 218  | 
  \begin{center}
 | 
| 69 | 219  | 
\begin{tabular}{l@{\hspace{4mm}}c@{\hspace{4mm}}ll}
 | 
| 6 | 220  | 
$r \cdot \ZERO$ & $\mapsto$ & $\ZERO$\\  | 
221  | 
$\ZERO \cdot r$ & $\mapsto$ & $\ZERO$\\  | 
|
222  | 
$r \cdot \ONE$ & $\mapsto$ & $r$\\  | 
|
223  | 
$\ONE \cdot r$ & $\mapsto$ & $r$\\  | 
|
224  | 
$r + \ZERO$ & $\mapsto$ & $r$\\  | 
|
225  | 
$\ZERO + r$ & $\mapsto$ & $r$\\  | 
|
226  | 
$r + r$ & $\mapsto$ & $r$\\  | 
|
227  | 
\end{tabular}
 | 
|
| 68 | 228  | 
  \end{center}
 | 
229  | 
||
| 69 | 230  | 
For example the regular expression  | 
| 68 | 231  | 
\[(r_1 + \ZERO) \cdot \ONE + ((\ONE + r_2) + r_3) \cdot (r_4 \cdot \ZERO)\]  | 
232  | 
||
| 153 | 233  | 
  simplifies to just $r_1$. \textbf{Hint:} Regular expressions can be
 | 
| 79 | 234  | 
seen as trees and there are several methods for traversing  | 
| 153 | 235  | 
trees. One of them corresponds to the inside-out traversal, which is  | 
236  | 
sometimes also called post-order traversal. Furthermore,  | 
|
237  | 
remember numerical expressions from school times: there you had expressions  | 
|
| 152 | 238  | 
like $u + \ldots + (1 \cdot x) - \ldots (z + (y \cdot 0)) \ldots$  | 
| 79 | 239  | 
and simplification rules that looked very similar to rules  | 
240  | 
above. You would simplify such numerical expressions by replacing  | 
|
241  | 
for example the $y \cdot 0$ by $0$, or $1\cdot x$ by $x$, and then  | 
|
| 152 | 242  | 
look whether more rules are applicable. If you organise the  | 
| 79 | 243  | 
simplification in an inside-out fashion, it is always clear which  | 
| 153 | 244  | 
rule should be applied next.\hfill[2 Marks]  | 
| 68 | 245  | 
|
246  | 
\item[(1d)] Implement two functions: The first, called \textit{ders},
 | 
|
| 69 | 247  | 
takes a list of characters and a regular expression as arguments, and  | 
248  | 
builds the derivative w.r.t.~the list as follows:  | 
|
| 68 | 249  | 
|
250  | 
\begin{center}
 | 
|
251  | 
\begin{tabular}{lcl}
 | 
|
| 69 | 252  | 
$\textit{ders}\;(Nil)\;r$ & $\dn$ & $r$\\
 | 
253  | 
  $\textit{ders}\;(c::cs)\;r$  & $\dn$ &
 | 
|
| 68 | 254  | 
    $\textit{ders}\;cs\;(\textit{simp}(\textit{der}\;c\;r))$\\
 | 
255  | 
\end{tabular}
 | 
|
| 6 | 256  | 
\end{center}
 | 
257  | 
||
| 78 | 258  | 
Note that this function is different from \textit{der}, which only
 | 
259  | 
takes a single character.  | 
|
260  | 
||
261  | 
The second function, called \textit{matcher}, takes a string and a
 | 
|
262  | 
regular expression as arguments. It builds first the derivatives  | 
|
263  | 
according to \textit{ders} and after that tests whether the resulting
 | 
|
264  | 
derivative regular expression can match the empty string (using  | 
|
265  | 
\textit{nullable}).  For example the \textit{matcher} will produce
 | 
|
| 153 | 266  | 
true for the regular expression $(a\cdot b)\cdot c$ and the string  | 
267  | 
$abc$, but false if you give it the string $ab$. \hfill[1 Mark]  | 
|
| 78 | 268  | 
|
| 153 | 269  | 
\item[(1e)] Implement a function, called \textit{size}, by recursion
 | 
| 78 | 270  | 
over regular expressions. If a regular expression is seen as a tree,  | 
271  | 
  then \textit{size} should return the number of nodes in such a
 | 
|
272  | 
tree. Therefore this function is defined as follows:  | 
|
273  | 
||
274  | 
\begin{center}
 | 
|
275  | 
\begin{tabular}{lcl}
 | 
|
276  | 
$\textit{size}(\ZERO)$ & $\dn$ & $1$\\
 | 
|
277  | 
$\textit{size}(\ONE)$  & $\dn$ & $1$\\
 | 
|
278  | 
$\textit{size}(c)$     & $\dn$ & $1$\\
 | 
|
279  | 
$\textit{size}(r_1 + r_2)$ & $\dn$ & $1 + \textit{size}(r_1) + \textit{size}(r_2)$\\
 | 
|
280  | 
$\textit{size}(r_1 \cdot r_2)$ & $\dn$ & $1 + \textit{size}(r_1) + \textit{size}(r_2)$\\
 | 
|
281  | 
$\textit{size}(r^*)$ & $\dn$ & $1 + \textit{size}(r)$\\
 | 
|
282  | 
\end{tabular}
 | 
|
283  | 
\end{center}
 | 
|
284  | 
||
| 153 | 285  | 
You can use \textit{size} in order to test how much the `evil' regular
 | 
286  | 
expression $(a^*)^* \cdot b$ grows when taking successive derivatives  | 
|
287  | 
according the letter $a$ without simplification and then compare it to  | 
|
288  | 
taking the derivative, but simplify the result. The sizes  | 
|
289  | 
are given in \texttt{re.scala}. \hfill[1 Mark]
 | 
|
290  | 
\end{itemize}
 | 
|
| 78 | 291  | 
|
| 
94
 
ae4708c851ee
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
86 
diff
changeset
 | 
292  | 
\subsection*{Background}
 | 
| 78 | 293  | 
|
| 
94
 
ae4708c851ee
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
86 
diff
changeset
 | 
294  | 
Although easily implementable in Scala, the idea behind the derivative  | 
| 
 
ae4708c851ee
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
86 
diff
changeset
 | 
295  | 
function might not so easy to be seen. To understand its purpose  | 
| 
 
ae4708c851ee
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
86 
diff
changeset
 | 
296  | 
better, assume a regular expression $r$ can match strings of the form  | 
| 152 | 297  | 
$c\!::\!cs$ (that means strings which start with a character $c$ and have  | 
| 153 | 298  | 
some rest, or tail, $cs$). If you take the derivative of $r$ with  | 
299  | 
respect to the character $c$, then you obtain a regular expression  | 
|
| 
94
 
ae4708c851ee
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
86 
diff
changeset
 | 
300  | 
that can match all the strings $cs$. In other words, the regular  | 
| 153 | 301  | 
expression $\textit{der}\;c\;r$ can match the same strings $c\!::\!cs$
 | 
| 
94
 
ae4708c851ee
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
86 
diff
changeset
 | 
302  | 
that can be matched by $r$, except that the $c$ is chopped off.  | 
| 75 | 303  | 
|
304  | 
Assume now $r$ can match the string $abc$. If you take the derivative  | 
|
305  | 
according to $a$ then you obtain a regular expression that can match  | 
|
306  | 
$bc$ (it is $abc$ where the $a$ has been chopped off). If you now  | 
|
| 153 | 307  | 
build the derivative $\textit{der}\;b\;(\textit{der}\;a\;r)$ you
 | 
| 78 | 308  | 
obtain a regular expression that can match the string $c$ (it is $bc$  | 
309  | 
where $b$ is chopped off). If you finally build the derivative of this  | 
|
310  | 
according $c$, that is  | 
|
| 153 | 311  | 
$\textit{der}\;c\;(\textit{der}\;b\;(\textit{der}\;a\;r))$, you obtain
 | 
312  | 
a regular expression that can match the empty string. You can test  | 
|
313  | 
whether this is indeed the case using the function nullable, which is  | 
|
314  | 
what your matcher is doing.  | 
|
| 75 | 315  | 
|
| 153 | 316  | 
The purpose of the $\textit{simp}$ function is to keep the regular
 | 
317  | 
expression small. Normally the derivative function makes the regular  | 
|
318  | 
expression bigger (see the SEQ case and the example in (1b)) and the  | 
|
319  | 
algorithm would be slower and slower over time. The $\textit{simp}$
 | 
|
320  | 
function counters this increase in size and the result is that the  | 
|
321  | 
algorithm is fast throughout. By the way, this algorithm is by Janusz  | 
|
322  | 
Brzozowski who came up with the idea of derivatives in 1964 in his PhD  | 
|
323  | 
thesis.  | 
|
| 75 | 324  | 
|
| 78 | 325  | 
\begin{center}\small
 | 
326  | 
\url{https://en.wikipedia.org/wiki/Janusz_Brzozowski_(computer_scientist)}
 | 
|
327  | 
\end{center}
 | 
|
| 6 | 328  | 
|
| 153 | 329  | 
|
330  | 
If you want to see how badly the regular expression matchers do in  | 
|
331  | 
Java and Python with the `evil' regular expression, then have a look  | 
|
332  | 
at the graphs below (you can try it out for yourself: have a look at  | 
|
333  | 
the file \texttt{catastrophic.java} on KEATS). Compare this with the
 | 
|
334  | 
matcher you have implemented. How long can the string of $a$'s be  | 
|
| 154 | 335  | 
in your matcher and still stay within the 30 seconds time limit?  | 
| 153 | 336  | 
|
337  | 
\begin{center}
 | 
|
338  | 
\begin{tikzpicture}
 | 
|
339  | 
\begin{axis}[
 | 
|
340  | 
    title={Graph: $(a^*)^*\cdot b$ and strings 
 | 
|
341  | 
           $\underbrace{a\ldots a}_{n}$},
 | 
|
342  | 
    xlabel={$n$},
 | 
|
343  | 
    x label style={at={(1.05,0.0)}},
 | 
|
344  | 
    ylabel={time in secs},
 | 
|
345  | 
enlargelimits=false,  | 
|
346  | 
    xtick={0,5,...,30},
 | 
|
347  | 
xmax=33,  | 
|
348  | 
ymax=35,  | 
|
349  | 
    ytick={0,5,...,30},
 | 
|
350  | 
scaled ticks=false,  | 
|
351  | 
axis lines=left,  | 
|
352  | 
width=6cm,  | 
|
353  | 
height=5.0cm,  | 
|
354  | 
    legend entries={Python, Java},  
 | 
|
355  | 
legend pos=outer north east]  | 
|
356  | 
\addplot[blue,mark=*, mark options={fill=white}] table {re-python2.data};
 | 
|
357  | 
\addplot[cyan,mark=*, mark options={fill=white}] table {re-java.data};
 | 
|
358  | 
\end{axis}
 | 
|
359  | 
\end{tikzpicture}
 | 
|
360  | 
\end{center}
 | 
|
361  | 
\newpage  | 
|
362  | 
||
363  | 
\subsection*{Part 2 (4 Marks)}
 | 
|
364  | 
||
| 154 | 365  | 
Coming from Java or C++, you might think Scala is a quite esoteric  | 
366  | 
programming language. But remember, some serious companies have built  | 
|
367  | 
their business on  | 
|
368  | 
Scala.\footnote{\url{https://en.wikipedia.org/wiki/Scala_(programming_language)\#Companies}}
 | 
|
369  | 
And there are far more esoteric languages out there. One is called  | 
|
370  | 
\emph{brainf***}. You are asked in this part to implement an
 | 
|
371  | 
interpreter for this language.  | 
|
372  | 
||
373  | 
Urban M\"uller developed brainf*** in 1993. A close relative of this  | 
|
374  | 
language was already introduced in 1964 by Corado B\"ohm, an Italian  | 
|
375  | 
computer pioneer, who unfortunately died a few months ago. The main  | 
|
376  | 
feature of brainf*** is its minimalistic set of instructions---just 8  | 
|
377  | 
instructions in total and all of which are single characters. Despite  | 
|
378  | 
the minimalism, this language has been shown to be Turing  | 
|
379  | 
complete\ldots{}if this doesn't ring any bell with you: it roughly
 | 
|
380  | 
means every algorithm we know can, in principle, be implemented in  | 
|
381  | 
brainf***. It just takes a lot of determination and quite a lot of  | 
|
382  | 
memory resources. Some relatively sophisticated example programs in  | 
|
383  | 
brainf*** are given in the file \texttt{bf.scala}.\bigskip
 | 
|
| 153 | 384  | 
|
| 154 | 385  | 
\noindent  | 
386  | 
As mentioned above, brainf*** has 8 single-character commands, namely  | 
|
387  | 
\texttt{'>'}, \texttt{'<'}, \texttt{'+'}, \texttt{'-'}, \texttt{'.'},
 | 
|
388  | 
\texttt{','}, \texttt{'['} and \texttt{']'}. Every other character is
 | 
|
389  | 
considered a comment. Brainf*** operates on memory cells containing  | 
|
390  | 
integers. For this it uses a single memory pointer that points at each  | 
|
391  | 
stage to one memory cell. This pointer can be moved forward by one  | 
|
392  | 
memory cell by using the command \texttt{'>'}, and backward by using
 | 
|
393  | 
\texttt{'<'}. The commands \texttt{'+'} and \texttt{'-'} increase,
 | 
|
394  | 
respectively decrease, by 1 the content of the memory cell to which  | 
|
395  | 
the memory pointer currently points to. The commands for input/output  | 
|
396  | 
are \texttt{','} and \texttt{'.'}. Output works by reading the content
 | 
|
397  | 
of the memory cell to which the memory pointer points to and printing  | 
|
398  | 
it out as an ASCII character. Input works the other way, taking some  | 
|
399  | 
user input and storing it in the cell to which the memory pointer  | 
|
400  | 
points to. The commands \texttt{'['} and \texttt{']'} are looping
 | 
|
401  | 
constructs. Everything in between \texttt{'['} and \texttt{']'} is
 | 
|
402  | 
repeated until a counter (memory cell) reaches zero. A typical  | 
|
403  | 
program in brainf*** looks as follows:  | 
|
| 153 | 404  | 
|
| 154 | 405  | 
\begin{center}
 | 
406  | 
\begin{verbatim}
 | 
|
407  | 
++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++  | 
|
408  | 
..+++.>>.<-.<.+++.------.--------.>>+.>++.  | 
|
409  | 
\end{verbatim}
 | 
|
410  | 
\end{center}  
 | 
|
411  | 
||
412  | 
\noindent  | 
|
413  | 
This one prints out Hello World\ldots{}obviously. 
 | 
|
| 153 | 414  | 
|
415  | 
\subsubsection*{Tasks (file bf.scala)}
 | 
|
416  | 
||
417  | 
\begin{itemize}
 | 
|
| 154 | 418  | 
\item[(2a)] Brainf*** memory is represented by a \texttt{Map} from
 | 
419  | 
integers to integers. The empty memory is represented by  | 
|
420  | 
  \texttt{Map()}, that is nothing is stored in the
 | 
|
421  | 
  memory. \texttt{Map(0 -> 1, 2 -> 3)} clearly has stored \texttt{1}
 | 
|
422  | 
  at memory location \texttt{0}, at \texttt{2} it stores
 | 
|
423  | 
  \texttt{3}. The convention is that if we query the memory at a
 | 
|
424  | 
  location that is not defined in the \texttt{Map} we return
 | 
|
425  | 
  \texttt{0}. Write a function, \texttt{sread}, that takes a memory (a
 | 
|
426  | 
  \texttt{Map}) and a memory pointer (an \texttt{Int}) as argument,
 | 
|
427  | 
and safely reads the corresponding memory location. If the map is not  | 
|
428  | 
  defined at the memory pointer it returns \texttt{0}.
 | 
|
429  | 
||
430  | 
  Write another function \texttt{write}, which takes a memory, a
 | 
|
431  | 
memory pointer and a integer value as argument and updates the map  | 
|
432  | 
with the value at the given memory location. As usual the map is not  | 
|
433  | 
updated `in-place' but a new map is created with the same data,  | 
|
434  | 
except the value is stored at the given memory pointer.\hfill[1 Mark]  | 
|
435  | 
||
436  | 
\item[(2b)] Write two functions, \texttt{jumpRight} and
 | 
|
437  | 
  \texttt{jumpLeft} that are needed to implement the loop constructs
 | 
|
438  | 
  of brainf***. They take a program (a \texttt{String}) and a program
 | 
|
439  | 
  counter (an \texttt{Int}) as argument and move right (respectively
 | 
|
440  | 
  left) in the string in order to find the \textbf{matching}
 | 
|
441  | 
opening/closing bracket. For example, given the following program  | 
|
442  | 
with the program counter indicated by an arrow:  | 
|
443  | 
||
444  | 
  \begin{center}
 | 
|
445  | 
  \texttt{--[\barbelow{.}.+>--],>,++}
 | 
|
446  | 
  \end{center}
 | 
|
447  | 
||
448  | 
then the matching closing bracket is in 9th position (counting from 0) and  | 
|
449  | 
  \texttt{jumpRight} is supposed to return the position just after this
 | 
|
450  | 
||
451  | 
  \begin{center}
 | 
|
452  | 
  \texttt{--[..+>--]\barbelow{,}>,++}
 | 
|
453  | 
  \end{center}
 | 
|
454  | 
||
455  | 
meaning it jumps after the loop. Similarly, if you in 8th position  | 
|
456  | 
  then \texttt{jumpLeft} is supposed to jump to just after the opening
 | 
|
457  | 
bracket (that is jumping to the beginning of the loop):  | 
|
458  | 
||
459  | 
  \begin{center}
 | 
|
460  | 
    \texttt{--[..+>-\barbelow{-}],>,++}
 | 
|
461  | 
    \qquad$\stackrel{\texttt{jumpLeft}}{\longrightarrow}$\qquad
 | 
|
462  | 
    \texttt{--[\barbelow{.}.+>--],>,++}
 | 
|
463  | 
  \end{center}
 | 
|
464  | 
||
465  | 
Unfortunately we have to take into account that there might be  | 
|
466  | 
another opening and closing bracket on the `way' to find the  | 
|
467  | 
matching bracket. For example in the brainf*** program  | 
|
468  | 
||
469  | 
  \begin{center}
 | 
|
470  | 
  \texttt{--[\barbelow{.}.[+>]--],>,++}
 | 
|
471  | 
  \end{center}
 | 
|
472  | 
||
473  | 
  we do not want to return the index for the \texttt{'-'} in the 9th
 | 
|
474  | 
  position, but the program counter for \texttt{','} in 12th
 | 
|
475  | 
position. The easiest to find out whether a bracket is matched is to  | 
|
476  | 
  use levels (which are the third argument in \texttt{jumpLeft} and
 | 
|
477  | 
  \texttt{jumpLeft}). In case of \texttt{jumpRight} you increase the
 | 
|
478  | 
level by one whenever you find an opening bracket and decrease by  | 
|
479  | 
  one for a closing bracket. Then in \texttt{jumpRight} you are looking
 | 
|
480  | 
  for the closing bracket on level \texttt{0}. For \texttt{jumpLeft} you
 | 
|
481  | 
  do the opposite. In this way you can find \textbf{matching} brackets
 | 
|
482  | 
in strings such as  | 
|
483  | 
||
484  | 
  \begin{center}
 | 
|
485  | 
  \texttt{--[\barbelow{.}.[[-]+>[.]]--],>,++}
 | 
|
486  | 
  \end{center}
 | 
|
487  | 
||
488  | 
  for which \texttt{jumpRight} should produce the position:
 | 
|
489  | 
||
490  | 
  \begin{center}
 | 
|
491  | 
  \texttt{--[..[[-]+>[.]]--]\barbelow{,}>,++}
 | 
|
492  | 
  \end{center}
 | 
|
493  | 
||
494  | 
  It is also possible that the position returned by \texttt{jumpRight} or
 | 
|
495  | 
  \texttt{jumpLeft} is outside the string in cases where there are
 | 
|
496  | 
no matching brackets. For example  | 
|
| 153 | 497  | 
|
| 154 | 498  | 
  \begin{center}
 | 
499  | 
  \texttt{--[\barbelow{.}.[[-]+>[.]]--,>,++}
 | 
|
500  | 
  \qquad$\stackrel{\texttt{jumpRight}}{\longrightarrow}$\qquad
 | 
|
501  | 
  \texttt{--[..[[-]+>[.]]-->,++\barbelow{\;\phantom{+}}}
 | 
|
502  | 
  \end{center}
 | 
|
503  | 
\hfill[1 Mark]  | 
|
504  | 
||
505  | 
||
506  | 
\item[(2c)] Write a recursive function \texttt{run} that executes a
 | 
|
507  | 
brainf*** program. It takes a program, a program counter, a memory  | 
|
508  | 
counter and a memory as arguments. If the program counter is outside  | 
|
509  | 
  the program string, the execution stops and \texttt{run} returns the
 | 
|
510  | 
memory. If the program counter is inside the string, it reads the  | 
|
511  | 
  corresponding character and updates the program counter \texttt{pc}, memory
 | 
|
512  | 
  pointer \texttt{mp} and memory \texttt{mem} according to the rules shown
 | 
|
513  | 
  in Figure~\ref{comms}. It the calls recursively \texttt{run} with the updated
 | 
|
514  | 
data.  | 
|
| 153 | 515  | 
|
| 154 | 516  | 
  Write another function \texttt{start} that calls \texttt{run} with a
 | 
517  | 
given brainfu** program and memory, and the program counter and memory counter  | 
|
518  | 
  set to~$0$. Like \texttt{run} it returns the memory after the execution
 | 
|
519  | 
of the program finishes. You can test your brainf**k interpreter with the  | 
|
520  | 
  Sierpinski triangle or the Hello world programs.\\\mbox{}\hfill[2 Marks]
 | 
|
521  | 
||
522  | 
  \begin{figure}[p]
 | 
|
523  | 
  \begin{center}
 | 
|
524  | 
    \begin{tabular}{|@{}p{0.8cm}|l|}
 | 
|
525  | 
\hline  | 
|
526  | 
      \hfill\texttt{'>'} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|
527  | 
                       $\bullet$ & $\texttt{pc} + 1$\\
 | 
|
528  | 
                       $\bullet$ & $\texttt{mp} + 1$\\
 | 
|
529  | 
                       $\bullet$ & \texttt{mem} unchanged
 | 
|
530  | 
                     \end{tabular}\\\hline   
 | 
|
531  | 
      \hfill\texttt{'<'} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|
532  | 
                       $\bullet$ & $\texttt{pc} + 1$\\
 | 
|
533  | 
                       $\bullet$ & $\texttt{mp} - 1$\\
 | 
|
534  | 
                       $\bullet$ & \texttt{mem} unchanged
 | 
|
535  | 
                     \end{tabular}\\\hline   
 | 
|
536  | 
      \hfill\texttt{'+'} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|
537  | 
                       $\bullet$ & $\texttt{pc} + 1$\\
 | 
|
538  | 
                       $\bullet$ & $\texttt{mp}$ unchanged\\
 | 
|
539  | 
                       $\bullet$ & \texttt{mem} updated with \texttt{mp -> mem(mp) + 1}\\
 | 
|
540  | 
                     \end{tabular}\\\hline   
 | 
|
541  | 
      \hfill\texttt{'-'} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|
542  | 
                       $\bullet$ & $\texttt{pc} + 1$\\
 | 
|
543  | 
                       $\bullet$ & $\texttt{mp}$ unchanged\\
 | 
|
544  | 
                       $\bullet$ & \texttt{mem} updated with \texttt{mp -> mem(mp) - 1}\\
 | 
|
545  | 
                     \end{tabular}\\\hline   
 | 
|
546  | 
      \hfill\texttt{'.'} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|
547  | 
                       $\bullet$ & $\texttt{pc} + 1$\\
 | 
|
548  | 
                       $\bullet$ & $\texttt{mp}$ and \texttt{mem} unchanged\\
 | 
|
549  | 
                       $\bullet$ & print out\texttt{mem(mp)} as a character\\
 | 
|
550  | 
                     \end{tabular}\\\hline   
 | 
|
551  | 
      \hfill\texttt{','} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|
552  | 
                       $\bullet$ & $\texttt{pc} + 1$\\
 | 
|
553  | 
                       $\bullet$ & $\texttt{mp}$ unchanged\\
 | 
|
554  | 
                       $\bullet$ & \texttt{mem} updated with \texttt{mp -> \textrm{input}}\\
 | 
|
555  | 
                       \multicolumn{2}{@{}l}{input given by \texttt{Console.in.read().toByte}}
 | 
|
556  | 
                     \end{tabular}\\\hline   
 | 
|
557  | 
      \hfill\texttt{'['} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|
558  | 
                       \multicolumn{2}{@{}l}{if \texttt{mem(mp) == 0} then}\\
 | 
|
559  | 
                       $\bullet$ & $\texttt{pc = jumpRight(prog, pc + 1, 0)}$\\
 | 
|
560  | 
                       $\bullet$ & $\texttt{mp}$ and \texttt{mem} unchanged\medskip\\
 | 
|
561  | 
                       \multicolumn{2}{@{}l}{otherwise if \texttt{mem(mp) != 0} then}\\
 | 
|
562  | 
                       $\bullet$ & $\texttt{pc} + 1$\\
 | 
|
563  | 
                       $\bullet$ & $\texttt{mp}$ and \texttt{mem} unchanged\\
 | 
|
564  | 
                     \end{tabular}
 | 
|
565  | 
\\\hline  | 
|
566  | 
      \hfill\texttt{']'} & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|
567  | 
                       \multicolumn{2}{@{}l}{if \texttt{mem(mp) != 0} then}\\
 | 
|
568  | 
                       $\bullet$ & $\texttt{pc = jumpLeft(prog, pc - 1 1, 0)}$\\
 | 
|
569  | 
                       $\bullet$ & $\texttt{mp}$ and \texttt{mem} unchanged\medskip\\
 | 
|
570  | 
                       \multicolumn{2}{@{}l}{otherwise if \texttt{mem(mp) == 0} then}\\
 | 
|
571  | 
                       $\bullet$ & $\texttt{pc} + 1$\\
 | 
|
572  | 
                       $\bullet$ & $\texttt{mp}$ and \texttt{mem} unchanged\\
 | 
|
573  | 
                     \end{tabular}\\\hline   
 | 
|
574  | 
      any other char & \begin{tabular}[t]{@{}l@{\hspace{2mm}}l@{}}
 | 
|
575  | 
                         $\bullet$ & $\texttt{pc} + 1$\\
 | 
|
576  | 
                         $\bullet$ & \texttt{mp} and \texttt{mem} unchanged
 | 
|
577  | 
                       \end{tabular}\\
 | 
|
578  | 
\hline  | 
|
579  | 
    \end{tabular}
 | 
|
580  | 
  \end{center}
 | 
|
581  | 
  \caption{The rules for how commands in the brainf*** language update the program counter,
 | 
|
582  | 
    memory counter and memory.\label{comms}}
 | 
|
583  | 
  \end{figure}
 | 
|
| 153 | 584  | 
\end{itemize}\bigskip  
 | 
585  | 
||
586  | 
||
587  | 
||
588  | 
||
| 6 | 589  | 
\end{document}
 | 
590  | 
||
| 68 | 591  | 
|
| 6 | 592  | 
%%% Local Variables:  | 
593  | 
%%% mode: latex  | 
|
594  | 
%%% TeX-master: t  | 
|
595  | 
%%% End:  |