| author | Christian Urban <urbanc@in.tum.de> | 
| Sat, 22 Jun 2019 08:39:52 +0100 | |
| changeset 265 | 2692329287bb | 
| parent 257 | 71e534e28430 | 
| child 275 | d2e28432378f | 
| permissions | -rw-r--r-- | 
| 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  | 
||
13  | 
\begin{filecontents}{re-python2.data}
 | 
|
14  | 
1 0.033  | 
|
15  | 
5 0.036  | 
|
16  | 
10 0.034  | 
|
17  | 
15 0.036  | 
|
18  | 
18 0.059  | 
|
19  | 
19 0.084  | 
|
20  | 
20 0.141  | 
|
21  | 
21 0.248  | 
|
22  | 
22 0.485  | 
|
23  | 
23 0.878  | 
|
24  | 
24 1.71  | 
|
25  | 
25 3.40  | 
|
26  | 
26 7.08  | 
|
27  | 
27 14.12  | 
|
28  | 
28 26.69  | 
|
29  | 
\end{filecontents}
 | 
|
30  | 
||
31  | 
\begin{filecontents}{re-java.data}
 | 
|
32  | 
5 0.00298  | 
|
33  | 
10 0.00418  | 
|
34  | 
15 0.00996  | 
|
35  | 
16 0.01710  | 
|
36  | 
17 0.03492  | 
|
37  | 
18 0.03303  | 
|
38  | 
19 0.05084  | 
|
39  | 
20 0.10177  | 
|
40  | 
21 0.19960  | 
|
41  | 
22 0.41159  | 
|
42  | 
23 0.82234  | 
|
43  | 
24 1.70251  | 
|
44  | 
25 3.36112  | 
|
45  | 
26 6.63998  | 
|
46  | 
27 13.35120  | 
|
47  | 
28 29.81185  | 
|
48  | 
\end{filecontents}
 | 
|
49  | 
||
| 221 | 50  | 
\begin{filecontents}{re-js.data}
 | 
51  | 
5 0.061  | 
|
52  | 
10 0.061  | 
|
53  | 
15 0.061  | 
|
54  | 
20 0.070  | 
|
55  | 
23 0.131  | 
|
56  | 
25 0.308  | 
|
57  | 
26 0.564  | 
|
58  | 
28 1.994  | 
|
59  | 
30 7.648  | 
|
60  | 
31 15.881  | 
|
61  | 
32 32.190  | 
|
62  | 
\end{filecontents}
 | 
|
63  | 
||
| 218 | 64  | 
\begin{filecontents}{re-java9.data}
 | 
65  | 
1000 0.01410  | 
|
66  | 
2000 0.04882  | 
|
67  | 
3000 0.10609  | 
|
68  | 
4000 0.17456  | 
|
69  | 
5000 0.27530  | 
|
70  | 
6000 0.41116  | 
|
71  | 
7000 0.53741  | 
|
72  | 
8000 0.70261  | 
|
73  | 
9000 0.93981  | 
|
74  | 
10000 0.97419  | 
|
75  | 
11000 1.28697  | 
|
76  | 
12000 1.51387  | 
|
77  | 
14000 2.07079  | 
|
78  | 
16000 2.69846  | 
|
79  | 
20000 4.41823  | 
|
80  | 
24000 6.46077  | 
|
81  | 
26000 7.64373  | 
|
82  | 
30000 9.99446  | 
|
83  | 
34000 12.966885  | 
|
84  | 
38000 16.281621  | 
|
85  | 
42000 19.180228  | 
|
86  | 
46000 21.984721  | 
|
87  | 
50000 26.950203  | 
|
88  | 
60000 43.0327746  | 
|
89  | 
\end{filecontents}
 | 
|
90  | 
||
| 6 | 91  | 
|
92  | 
\begin{document}
 | 
|
93  | 
||
| 218 | 94  | 
% BF IDE  | 
95  | 
% https://www.microsoft.com/en-us/p/brainf-ck/9nblgggzhvq5  | 
|
96  | 
||
| 221 | 97  | 
\section*{Coursework 9 (Scala)}
 | 
| 6 | 98  | 
|
| 221 | 99  | 
This coursework is worth 10\%. It is about a regular expression  | 
100  | 
matcher and the shunting yard algorithm by Dijkstra. The first part is  | 
|
| 253 | 101  | 
due on \cwNINE{} at 11pm; the second, more advanced part, is due on
 | 
102  | 
\cwNINEa{} at 11pm. In the first part, you are asked to implement a
 | 
|
| 218 | 103  | 
regular expression matcher based on derivatives of regular  | 
| 253 | 104  | 
expressions. The background is that ``out-of-the-box'' regular  | 
105  | 
expression matching in mainstream languages like Java, JavaScript and  | 
|
106  | 
Python can sometimes be excruciatingly slow. You are supposed to implement  | 
|
| 257 | 107  | 
an regular expression matcher that is much, much faster. The advanced part is  | 
| 253 | 108  | 
about the shunting yard algorithm that transforms the usual infix  | 
109  | 
notation of arithmetic expressions into the postfix notation, which is  | 
|
110  | 
for example used in compilers.\bigskip  | 
|
| 218 | 111  | 
|
112  | 
\IMPORTANT{}
 | 
|
| 62 | 113  | 
|
114  | 
\noindent  | 
|
| 218 | 115  | 
Also note that the running time of each part will be restricted to a  | 
| 257 | 116  | 
maximum of 30 seconds on my laptop.  | 
| 218 | 117  | 
|
118  | 
\DISCLAIMER{}
 | 
|
| 86 | 119  | 
|
| 221 | 120  | 
\subsection*{Reference Implementation}
 | 
121  | 
||
122  | 
This Scala assignment comes with three reference implementations in form of  | 
|
| 224 | 123  | 
\texttt{jar}-files you can download from KEATS. This allows you to run any
 | 
124  | 
test cases on your own  | 
|
| 221 | 125  | 
computer. For example you can call Scala on the command line with the  | 
126  | 
option \texttt{-cp re.jar} and then query any function from the
 | 
|
127  | 
\texttt{re.scala} template file. As usual you have to
 | 
|
128  | 
prefix the calls with \texttt{CW9a}, \texttt{CW9b} and \texttt{CW9c}.
 | 
|
129  | 
Since some tasks are time sensitive, you can check the reference  | 
|
| 224 | 130  | 
implementation as follows: if you want to know, for example, how long it takes  | 
| 221 | 131  | 
to match strings of $a$'s using the regular expression $(a^*)^*\cdot b$  | 
| 245 | 132  | 
you can query as follows:  | 
| 221 | 133  | 
|
134  | 
||
135  | 
||
| 245 | 136  | 
\begin{lstlisting}[xleftmargin=1mm,numbers=none,basicstyle=\ttfamily\small]
 | 
| 221 | 137  | 
$ scala -cp re.jar  | 
138  | 
scala> import CW9a._  | 
|
139  | 
scala> for (i <- 0 to 5000000 by 500000) {
 | 
|
140  | 
| println(i + " " + "%.5f".format(time_needed(2, matcher(EVIL, "a" * i))) + "secs.")  | 
|
141  | 
| }  | 
|
142  | 
0 0.00002 secs.  | 
|
143  | 
500000 0.10608 secs.  | 
|
144  | 
1000000 0.22286 secs.  | 
|
145  | 
1500000 0.35982 secs.  | 
|
146  | 
2000000 0.45828 secs.  | 
|
147  | 
2500000 0.59558 secs.  | 
|
148  | 
3000000 0.73191 secs.  | 
|
149  | 
3500000 0.83499 secs.  | 
|
150  | 
4000000 0.99149 secs.  | 
|
151  | 
4500000 1.15395 secs.  | 
|
152  | 
5000000 1.29659 secs.  | 
|
153  | 
\end{lstlisting}%$
 | 
|
154  | 
||
| 6 | 155  | 
|
| 218 | 156  | 
\subsection*{Part 1 (6 Marks)}
 | 
157  | 
||
158  | 
The task is to implement a regular expression matcher that is based on  | 
|
159  | 
derivatives of regular expressions. Most of the functions are defined by  | 
|
160  | 
recursion over regular expressions and can be elegantly implemented  | 
|
161  | 
using Scala's pattern-matching. The implementation should deal with the  | 
|
162  | 
following regular expressions, which have been predefined in the file  | 
|
163  | 
\texttt{re.scala}:
 | 
|
| 6 | 164  | 
|
| 218 | 165  | 
\begin{center}
 | 
166  | 
\begin{tabular}{lcll}
 | 
|
167  | 
$r$ & $::=$ & $\ZERO$ & cannot match anything\\  | 
|
168  | 
& $|$ & $\ONE$ & can only match the empty string\\  | 
|
169  | 
& $|$ & $c$ & can match a single character (in this case $c$)\\  | 
|
170  | 
& $|$ & $r_1 + r_2$ & can match a string either with $r_1$ or with $r_2$\\  | 
|
171  | 
& $|$ & $r_1\cdot r_2$ & can match the first part of a string with $r_1$ and\\  | 
|
172  | 
& & & then the second part with $r_2$\\  | 
|
| 221 | 173  | 
& $|$ & $r^*$ & can match a string with zero or more copies of $r$\\  | 
| 218 | 174  | 
\end{tabular}
 | 
175  | 
\end{center}
 | 
|
| 6 | 176  | 
|
| 218 | 177  | 
\noindent  | 
| 221 | 178  | 
Why? Regular expressions are  | 
179  | 
one of the simplest ways to match patterns in text, and  | 
|
| 218 | 180  | 
are endlessly useful for searching, editing and analysing data in all  | 
181  | 
sorts of places (for example analysing network traffic in order to  | 
|
182  | 
detect security breaches). However, you need to be fast, otherwise you  | 
|
183  | 
will stumble over problems such as recently reported at  | 
|
184  | 
||
185  | 
{\small
 | 
|
186  | 
\begin{itemize}
 | 
|
187  | 
\item[$\bullet$] \url{http://stackstatus.net/post/147710624694/outage-postmortem-july-20-2016}
 | 
|
188  | 
\item[$\bullet$] \url{https://vimeo.com/112065252}
 | 
|
189  | 
\item[$\bullet$] \url{http://davidvgalbraith.com/how-i-fixed-atom/}  
 | 
|
190  | 
\end{itemize}}
 | 
|
191  | 
||
| 221 | 192  | 
% Knowing how to match regular expressions and strings will let you  | 
193  | 
% solve a lot of problems that vex other humans.  | 
|
194  | 
||
195  | 
||
| 218 | 196  | 
\subsubsection*{Tasks (file re.scala)}
 | 
| 6 | 197  | 
|
| 218 | 198  | 
The file \texttt{re.scala} has already a definition for regular
 | 
199  | 
expressions and also defines some handy shorthand notation for  | 
|
200  | 
regular expressions. The notation in this document matches up  | 
|
201  | 
with the code in the file as follows:  | 
|
202  | 
||
203  | 
\begin{center}
 | 
|
204  | 
  \begin{tabular}{rcl@{\hspace{10mm}}l}
 | 
|
205  | 
& & code: & shorthand:\smallskip \\  | 
|
206  | 
  $\ZERO$ & $\mapsto$ & \texttt{ZERO}\\
 | 
|
207  | 
  $\ONE$  & $\mapsto$ & \texttt{ONE}\\
 | 
|
208  | 
  $c$     & $\mapsto$ & \texttt{CHAR(c)}\\
 | 
|
209  | 
  $r_1 + r_2$ & $\mapsto$ & \texttt{ALT(r1, r2)} & \texttt{r1 | r2}\\
 | 
|
210  | 
  $r_1 \cdot r_2$ & $\mapsto$ & \texttt{SEQ(r1, r2)} & \texttt{r1 $\sim$ r2}\\
 | 
|
211  | 
  $r^*$ & $\mapsto$ &  \texttt{STAR(r)} & \texttt{r.\%}
 | 
|
212  | 
\end{tabular}    
 | 
|
213  | 
\end{center}  
 | 
|
214  | 
||
| 
105
 
0f9f774c7697
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
100 
diff
changeset
 | 
215  | 
|
| 
 
0f9f774c7697
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
100 
diff
changeset
 | 
216  | 
\begin{itemize}
 | 
| 221 | 217  | 
\item[(1)] Implement a function, called \textit{nullable}, by
 | 
| 218 | 218  | 
recursion over regular expressions. This function tests whether a  | 
219  | 
regular expression can match the empty string. This means given a  | 
|
220  | 
regular expression it either returns true or false. The function  | 
|
221  | 
  \textit{nullable}
 | 
|
222  | 
is defined as follows:  | 
|
223  | 
||
224  | 
\begin{center}
 | 
|
225  | 
\begin{tabular}{lcl}
 | 
|
226  | 
$\textit{nullable}(\ZERO)$ & $\dn$ & $\textit{false}$\\
 | 
|
227  | 
$\textit{nullable}(\ONE)$  & $\dn$ & $\textit{true}$\\
 | 
|
228  | 
$\textit{nullable}(c)$     & $\dn$ & $\textit{false}$\\
 | 
|
229  | 
$\textit{nullable}(r_1 + r_2)$ & $\dn$ & $\textit{nullable}(r_1) \vee \textit{nullable}(r_2)$\\
 | 
|
230  | 
$\textit{nullable}(r_1 \cdot r_2)$ & $\dn$ & $\textit{nullable}(r_1) \wedge \textit{nullable}(r_2)$\\
 | 
|
231  | 
$\textit{nullable}(r^*)$ & $\dn$ & $\textit{true}$\\
 | 
|
232  | 
\end{tabular}
 | 
|
233  | 
\end{center}~\hfill[1 Mark]
 | 
|
| 
105
 
0f9f774c7697
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
100 
diff
changeset
 | 
234  | 
|
| 221 | 235  | 
\item[(2)] Implement a function, called \textit{der}, by recursion over
 | 
| 218 | 236  | 
regular expressions. It takes a character and a regular expression  | 
| 245 | 237  | 
as arguments and calculates the derivative of a xregular expression according  | 
| 218 | 238  | 
to the rules:  | 
| 
105
 
0f9f774c7697
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
100 
diff
changeset
 | 
239  | 
|
| 218 | 240  | 
\begin{center}
 | 
241  | 
\begin{tabular}{lcl}
 | 
|
242  | 
$\textit{der}\;c\;(\ZERO)$ & $\dn$ & $\ZERO$\\
 | 
|
243  | 
$\textit{der}\;c\;(\ONE)$  & $\dn$ & $\ZERO$\\
 | 
|
244  | 
$\textit{der}\;c\;(d)$     & $\dn$ & $\textit{if}\; c = d\;\textit{then} \;\ONE \; \textit{else} \;\ZERO$\\
 | 
|
245  | 
$\textit{der}\;c\;(r_1 + r_2)$ & $\dn$ & $(\textit{der}\;c\;r_1) + (\textit{der}\;c\;r_2)$\\
 | 
|
246  | 
$\textit{der}\;c\;(r_1 \cdot r_2)$ & $\dn$ & $\textit{if}\;\textit{nullable}(r_1)$\\
 | 
|
247  | 
      & & $\textit{then}\;((\textit{der}\;c\;r_1)\cdot r_2) + (\textit{der}\;c\;r_2)$\\
 | 
|
248  | 
      & & $\textit{else}\;(\textit{der}\;c\;r_1)\cdot r_2$\\
 | 
|
249  | 
$\textit{der}\;c\;(r^*)$ & $\dn$ & $(\textit{der}\;c\;r)\cdot (r^*)$\\
 | 
|
250  | 
\end{tabular}
 | 
|
251  | 
\end{center}
 | 
|
252  | 
||
253  | 
For example given the regular expression $r = (a \cdot b) \cdot c$, the derivatives  | 
|
254  | 
w.r.t.~the characters $a$, $b$ and $c$ are  | 
|
| 
105
 
0f9f774c7697
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
100 
diff
changeset
 | 
255  | 
|
| 218 | 256  | 
\begin{center}
 | 
257  | 
  \begin{tabular}{lcll}
 | 
|
| 221 | 258  | 
    $\textit{der}\;a\;r$ & $=$ & $(\ONE \cdot b)\cdot c$ & \quad($= r'$)\\
 | 
| 218 | 259  | 
    $\textit{der}\;b\;r$ & $=$ & $(\ZERO \cdot b)\cdot c$\\
 | 
260  | 
    $\textit{der}\;c\;r$ & $=$ & $(\ZERO \cdot b)\cdot c$
 | 
|
261  | 
  \end{tabular}
 | 
|
262  | 
\end{center}
 | 
|
263  | 
||
264  | 
Let $r'$ stand for the first derivative, then taking the derivatives of $r'$  | 
|
265  | 
w.r.t.~the characters $a$, $b$ and $c$ gives  | 
|
266  | 
||
267  | 
\begin{center}
 | 
|
268  | 
  \begin{tabular}{lcll}
 | 
|
269  | 
    $\textit{der}\;a\;r'$ & $=$ & $((\ZERO \cdot b) + \ZERO)\cdot c$ \\
 | 
|
| 221 | 270  | 
    $\textit{der}\;b\;r'$ & $=$ & $((\ZERO \cdot b) + \ONE)\cdot c$ & \quad($= r''$)\\
 | 
| 218 | 271  | 
    $\textit{der}\;c\;r'$ & $=$ & $((\ZERO \cdot b) + \ZERO)\cdot c$
 | 
272  | 
  \end{tabular}
 | 
|
273  | 
\end{center}
 | 
|
| 
105
 
0f9f774c7697
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
100 
diff
changeset
 | 
274  | 
|
| 218 | 275  | 
One more example: Let $r''$ stand for the second derivative above,  | 
276  | 
then taking the derivatives of $r''$ w.r.t.~the characters $a$, $b$  | 
|
277  | 
and $c$ gives  | 
|
278  | 
||
279  | 
\begin{center}
 | 
|
280  | 
  \begin{tabular}{lcll}
 | 
|
281  | 
    $\textit{der}\;a\;r''$ & $=$ & $((\ZERO \cdot b) + \ZERO) \cdot c + \ZERO$ \\
 | 
|
282  | 
    $\textit{der}\;b\;r''$ & $=$ & $((\ZERO \cdot b) + \ZERO) \cdot c + \ZERO$\\
 | 
|
283  | 
    $\textit{der}\;c\;r''$ & $=$ & $((\ZERO \cdot b) + \ZERO) \cdot c + \ONE$ &
 | 
|
284  | 
    (is $\textit{nullable}$)                      
 | 
|
285  | 
  \end{tabular}
 | 
|
286  | 
\end{center}
 | 
|
287  | 
||
288  | 
Note, the last derivative can match the empty string, that is it is \textit{nullable}.\\
 | 
|
289  | 
\mbox{}\hfill\mbox{[1 Mark]}
 | 
|
290  | 
||
| 221 | 291  | 
\item[(3)] Implement the function \textit{simp}, which recursively
 | 
| 224 | 292  | 
traverses a regular expression, and on the way up simplifies every  | 
293  | 
regular expression on the left (see below) to the regular expression  | 
|
294  | 
  on the right, except it does not simplify inside ${}^*$-regular
 | 
|
295  | 
expressions.  | 
|
| 
105
 
0f9f774c7697
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
100 
diff
changeset
 | 
296  | 
|
| 
 
0f9f774c7697
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
100 
diff
changeset
 | 
297  | 
  \begin{center}
 | 
| 218 | 298  | 
\begin{tabular}{l@{\hspace{4mm}}c@{\hspace{4mm}}ll}
 | 
299  | 
$r \cdot \ZERO$ & $\mapsto$ & $\ZERO$\\  | 
|
300  | 
$\ZERO \cdot r$ & $\mapsto$ & $\ZERO$\\  | 
|
301  | 
$r \cdot \ONE$ & $\mapsto$ & $r$\\  | 
|
302  | 
$\ONE \cdot r$ & $\mapsto$ & $r$\\  | 
|
303  | 
$r + \ZERO$ & $\mapsto$ & $r$\\  | 
|
304  | 
$\ZERO + r$ & $\mapsto$ & $r$\\  | 
|
305  | 
$r + r$ & $\mapsto$ & $r$\\  | 
|
306  | 
\end{tabular}
 | 
|
| 
105
 
0f9f774c7697
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
100 
diff
changeset
 | 
307  | 
  \end{center}
 | 
| 
 
0f9f774c7697
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
100 
diff
changeset
 | 
308  | 
|
| 218 | 309  | 
For example the regular expression  | 
310  | 
\[(r_1 + \ZERO) \cdot \ONE + ((\ONE + r_2) + r_3) \cdot (r_4 \cdot \ZERO)\]  | 
|
311  | 
||
312  | 
  simplifies to just $r_1$. \textbf{Hint:} Regular expressions can be
 | 
|
313  | 
seen as trees and there are several methods for traversing  | 
|
| 245 | 314  | 
trees. One of them corresponds to the inside-out traversal, which is also  | 
315  | 
sometimes called post-order tra\-versal: you traverse inside the  | 
|
| 224 | 316  | 
tree and on the way up you apply simplification rules.  | 
| 245 | 317  | 
  \textbf{Another Hint:}
 | 
318  | 
Remember numerical expressions from school times---there you had expressions  | 
|
| 218 | 319  | 
like $u + \ldots + (1 \cdot x) - \ldots (z + (y \cdot 0)) \ldots$  | 
320  | 
and simplification rules that looked very similar to rules  | 
|
321  | 
above. You would simplify such numerical expressions by replacing  | 
|
322  | 
for example the $y \cdot 0$ by $0$, or $1\cdot x$ by $x$, and then  | 
|
323  | 
look whether more rules are applicable. If you organise the  | 
|
324  | 
simplification in an inside-out fashion, it is always clear which  | 
|
| 224 | 325  | 
simplification should be applied next.\hfill[1 Mark]  | 
| 218 | 326  | 
|
| 221 | 327  | 
\item[(4)] Implement two functions: The first, called \textit{ders},
 | 
| 218 | 328  | 
takes a list of characters and a regular expression as arguments, and  | 
329  | 
builds the derivative w.r.t.~the list as follows:  | 
|
330  | 
||
331  | 
\begin{center}
 | 
|
332  | 
\begin{tabular}{lcl}
 | 
|
333  | 
$\textit{ders}\;(Nil)\;r$ & $\dn$ & $r$\\
 | 
|
334  | 
  $\textit{ders}\;(c::cs)\;r$  & $\dn$ &
 | 
|
335  | 
    $\textit{ders}\;cs\;(\textit{simp}(\textit{der}\;c\;r))$\\
 | 
|
336  | 
\end{tabular}
 | 
|
337  | 
\end{center}
 | 
|
338  | 
||
339  | 
Note that this function is different from \textit{der}, which only
 | 
|
340  | 
takes a single character.  | 
|
341  | 
||
342  | 
The second function, called \textit{matcher}, takes a string and a
 | 
|
343  | 
regular expression as arguments. It builds first the derivatives  | 
|
344  | 
according to \textit{ders} and after that tests whether the resulting
 | 
|
345  | 
derivative regular expression can match the empty string (using  | 
|
346  | 
\textit{nullable}).  For example the \textit{matcher} will produce
 | 
|
347  | 
true for the regular expression $(a\cdot b)\cdot c$ and the string  | 
|
348  | 
$abc$, but false if you give it the string $ab$. \hfill[1 Mark]  | 
|
349  | 
||
| 221 | 350  | 
\item[(5)] Implement a function, called \textit{size}, by recursion
 | 
| 218 | 351  | 
over regular expressions. If a regular expression is seen as a tree,  | 
352  | 
  then \textit{size} should return the number of nodes in such a
 | 
|
353  | 
tree. Therefore this function is defined as follows:  | 
|
354  | 
||
355  | 
\begin{center}
 | 
|
356  | 
\begin{tabular}{lcl}
 | 
|
357  | 
$\textit{size}(\ZERO)$ & $\dn$ & $1$\\
 | 
|
358  | 
$\textit{size}(\ONE)$  & $\dn$ & $1$\\
 | 
|
359  | 
$\textit{size}(c)$     & $\dn$ & $1$\\
 | 
|
360  | 
$\textit{size}(r_1 + r_2)$ & $\dn$ & $1 + \textit{size}(r_1) + \textit{size}(r_2)$\\
 | 
|
361  | 
$\textit{size}(r_1 \cdot r_2)$ & $\dn$ & $1 + \textit{size}(r_1) + \textit{size}(r_2)$\\
 | 
|
362  | 
$\textit{size}(r^*)$ & $\dn$ & $1 + \textit{size}(r)$\\
 | 
|
363  | 
\end{tabular}
 | 
|
364  | 
\end{center}
 | 
|
365  | 
||
| 224 | 366  | 
You can use \textit{size} in order to test how much the ``evil'' regular
 | 
| 218 | 367  | 
expression $(a^*)^* \cdot b$ grows when taking successive derivatives  | 
368  | 
according the letter $a$ without simplification and then compare it to  | 
|
369  | 
taking the derivative, but simplify the result. The sizes  | 
|
370  | 
are given in \texttt{re.scala}. \hfill[1 Mark]
 | 
|
| 221 | 371  | 
|
372  | 
\item[(6)] You do not have to implement anything specific under this  | 
|
373  | 
task. The purpose here is that you will be marked for some ``power''  | 
|
374  | 
test cases. For example can your matcher decide within 30 seconds  | 
|
375  | 
whether the regular expression $(a^*)^*\cdot b$ matches strings of the  | 
|
376  | 
  form $aaa\ldots{}aaaa$, for say 1 Million $a$'s. And does simplification
 | 
|
377  | 
simplify the regular expression  | 
|
378  | 
||
379  | 
\[  | 
|
380  | 
  \texttt{SEQ(SEQ(SEQ(..., ONE | ONE) , ONE | ONE), ONE | ONE)}
 | 
|
381  | 
\]  | 
|
382  | 
||
383  | 
  \noindent correctly to just \texttt{ONE}, where \texttt{SEQ} is nested
 | 
|
| 245 | 384  | 
50 or more times?\\  | 
| 221 | 385  | 
  \mbox{}\hfill[1 Mark]
 | 
| 
105
 
0f9f774c7697
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
100 
diff
changeset
 | 
386  | 
\end{itemize}
 | 
| 
 
0f9f774c7697
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
100 
diff
changeset
 | 
387  | 
|
| 218 | 388  | 
\subsection*{Background}
 | 
389  | 
||
390  | 
Although easily implementable in Scala, the idea behind the derivative  | 
|
391  | 
function might not so easy to be seen. To understand its purpose  | 
|
392  | 
better, assume a regular expression $r$ can match strings of the form  | 
|
393  | 
$c\!::\!cs$ (that means strings which start with a character $c$ and have  | 
|
394  | 
some rest, or tail, $cs$). If you take the derivative of $r$ with  | 
|
395  | 
respect to the character $c$, then you obtain a regular expression  | 
|
396  | 
that can match all the strings $cs$. In other words, the regular  | 
|
397  | 
expression $\textit{der}\;c\;r$ can match the same strings $c\!::\!cs$
 | 
|
398  | 
that can be matched by $r$, except that the $c$ is chopped off.  | 
|
399  | 
||
400  | 
Assume now $r$ can match the string $abc$. If you take the derivative  | 
|
401  | 
according to $a$ then you obtain a regular expression that can match  | 
|
402  | 
$bc$ (it is $abc$ where the $a$ has been chopped off). If you now  | 
|
403  | 
build the derivative $\textit{der}\;b\;(\textit{der}\;a\;r)$ you
 | 
|
404  | 
obtain a regular expression that can match the string $c$ (it is $bc$  | 
|
405  | 
where $b$ is chopped off). If you finally build the derivative of this  | 
|
406  | 
according $c$, that is  | 
|
407  | 
$\textit{der}\;c\;(\textit{der}\;b\;(\textit{der}\;a\;r))$, you obtain
 | 
|
408  | 
a regular expression that can match the empty string. You can test  | 
|
409  | 
whether this is indeed the case using the function nullable, which is  | 
|
410  | 
what your matcher is doing.  | 
|
411  | 
||
412  | 
The purpose of the $\textit{simp}$ function is to keep the regular
 | 
|
413  | 
expressions small. Normally the derivative function makes the regular  | 
|
| 221 | 414  | 
expression bigger (see the SEQ case and the example in (2)) and the  | 
| 218 | 415  | 
algorithm would be slower and slower over time. The $\textit{simp}$
 | 
416  | 
function counters this increase in size and the result is that the  | 
|
417  | 
algorithm is fast throughout. By the way, this algorithm is by Janusz  | 
|
418  | 
Brzozowski who came up with the idea of derivatives in 1964 in his PhD  | 
|
419  | 
thesis.  | 
|
420  | 
||
421  | 
\begin{center}\small
 | 
|
422  | 
\url{https://en.wikipedia.org/wiki/Janusz_Brzozowski_(computer_scientist)}
 | 
|
423  | 
\end{center}
 | 
|
424  | 
||
| 
105
 
0f9f774c7697
updated
 
Christian Urban <christian dot urban at kcl dot ac dot uk> 
parents: 
100 
diff
changeset
 | 
425  | 
|
| 218 | 426  | 
If you want to see how badly the regular expression matchers do in  | 
| 221 | 427  | 
Java\footnote{Version 8 and below; Version 9 and above does not seem to be as
 | 
428  | 
catastrophic, but still much worse than the regular expression  | 
|
429  | 
matcher based on derivatives.}, JavaScript and Python with the  | 
|
430  | 
`evil' regular expression $(a^*)^*\cdot b$, then have a look at the  | 
|
431  | 
graphs below (you can try it out for yourself: have a look at the file  | 
|
432  | 
\texttt{catastrophic9.java}, \texttt{catastrophic.js} and
 | 
|
433  | 
\texttt{catastrophic.py} on KEATS). Compare this with the matcher you
 | 
|
434  | 
have implemented. How long can the string of $a$'s be in your matcher  | 
|
435  | 
and still stay within the 30 seconds time limit?  | 
|
| 78 | 436  | 
|
| 218 | 437  | 
\begin{center}
 | 
438  | 
\begin{tabular}{@{}cc@{}}
 | 
|
439  | 
\multicolumn{2}{c}{Graph: $(a^*)^*\cdot b$ and strings 
 | 
|
440  | 
           $\underbrace{a\ldots a}_{n}$}\bigskip\\
 | 
|
441  | 
||
442  | 
\begin{tikzpicture}
 | 
|
443  | 
\begin{axis}[
 | 
|
444  | 
    xlabel={$n$},
 | 
|
445  | 
    x label style={at={(1.05,0.0)}},
 | 
|
446  | 
    ylabel={time in secs},
 | 
|
447  | 
    y label style={at={(0.06,0.5)}},
 | 
|
448  | 
enlargelimits=false,  | 
|
449  | 
    xtick={0,5,...,30},
 | 
|
450  | 
xmax=33,  | 
|
451  | 
ymax=45,  | 
|
452  | 
    ytick={0,5,...,40},
 | 
|
453  | 
scaled ticks=false,  | 
|
454  | 
axis lines=left,  | 
|
455  | 
width=6cm,  | 
|
456  | 
height=5.5cm,  | 
|
| 221 | 457  | 
    legend entries={Python, Java 8, JavaScript},  
 | 
| 222 | 458  | 
legend pos=north west,  | 
459  | 
legend cell align=left]  | 
|
| 218 | 460  | 
\addplot[blue,mark=*, mark options={fill=white}] table {re-python2.data};
 | 
461  | 
\addplot[cyan,mark=*, mark options={fill=white}] table {re-java.data};
 | 
|
| 221 | 462  | 
\addplot[red,mark=*, mark options={fill=white}] table {re-js.data};
 | 
| 218 | 463  | 
\end{axis}
 | 
464  | 
\end{tikzpicture}
 | 
|
465  | 
&  | 
|
466  | 
\begin{tikzpicture}
 | 
|
467  | 
\begin{axis}[
 | 
|
468  | 
    xlabel={$n$},
 | 
|
469  | 
    x label style={at={(1.05,0.0)}},
 | 
|
470  | 
    ylabel={time in secs},
 | 
|
471  | 
    y label style={at={(0.06,0.5)}},
 | 
|
472  | 
%enlargelimits=false,  | 
|
473  | 
    %xtick={0,5000,...,30000},
 | 
|
474  | 
xmax=65000,  | 
|
475  | 
ymax=45,  | 
|
476  | 
    ytick={0,5,...,40},
 | 
|
477  | 
scaled ticks=false,  | 
|
478  | 
axis lines=left,  | 
|
479  | 
width=6cm,  | 
|
480  | 
height=5.5cm,  | 
|
481  | 
    legend entries={Java 9},  
 | 
|
482  | 
legend pos=north west]  | 
|
483  | 
\addplot[cyan,mark=*, mark options={fill=white}] table {re-java9.data};
 | 
|
484  | 
\end{axis}
 | 
|
485  | 
\end{tikzpicture}
 | 
|
486  | 
\end{tabular}  
 | 
|
487  | 
\end{center}
 | 
|
488  | 
\newpage  | 
|
489  | 
||
490  | 
\subsection*{Part 2 (4 Marks)}
 | 
|
491  | 
||
| 221 | 492  | 
The \emph{Shunting Yard Algorithm} has been developed by Edsger Dijkstra,
 | 
493  | 
an influential computer scientist who developed many well-known  | 
|
494  | 
algorithms. This algorithm transforms the usual infix notation of  | 
|
495  | 
arithmetic expressions into the postfix notation, sometimes also  | 
|
496  | 
called reverse Polish notation.  | 
|
| 218 | 497  | 
|
| 221 | 498  | 
Why on Earth do people use the postfix notation? It is much more  | 
499  | 
convenient to work with the usual infix notation for arithmetic  | 
|
500  | 
expressions. Most modern calculators (as opposed to the ones used 20  | 
|
501  | 
years ago) understand infix notation. So why on Earth? \ldots{}Well,
 | 
|
502  | 
many computers under the hood, even nowadays, use postfix notation  | 
|
503  | 
extensively. For example if you give to the Java compiler the  | 
|
| 224 | 504  | 
expression $1 + ((2 * 3) + (4 - 3))$, it will generate the Java Byte  | 
| 221 | 505  | 
code  | 
506  | 
||
507  | 
\begin{lstlisting}[language=JVMIS,numbers=none]
 | 
|
508  | 
ldc 1  | 
|
509  | 
ldc 2  | 
|
510  | 
ldc 3  | 
|
511  | 
imul  | 
|
512  | 
ldc 4  | 
|
513  | 
ldc 3  | 
|
514  | 
isub  | 
|
515  | 
iadd  | 
|
516  | 
iadd  | 
|
517  | 
\end{lstlisting}
 | 
|
| 218 | 518  | 
|
519  | 
\noindent  | 
|
| 247 | 520  | 
where the command \texttt{ldc} loads a constant onto the stack, and \texttt{imul},
 | 
| 221 | 521  | 
\texttt{isub} and \texttt{iadd} are commands acting on the stack. Clearly this
 | 
522  | 
is the arithmetic expression in postfix notation.\bigskip  | 
|
| 218 | 523  | 
|
524  | 
\noindent  | 
|
| 221 | 525  | 
The shunting yard algorithm processes an input token list using an  | 
526  | 
operator stack and an output list. The input consists of numbers,  | 
|
527  | 
operators ($+$, $-$, $*$, $/$) and parentheses, and for the purpose of  | 
|
528  | 
the assignment we assume the input is always a well-formed expression  | 
|
| 224 | 529  | 
in infix notation. The calculation in the shunting yard algorithm uses  | 
530  | 
information about the  | 
|
| 221 | 531  | 
precedences of the operators (given in the template file). The  | 
532  | 
algorithm processes the input token list as follows:  | 
|
| 109 | 533  | 
|
534  | 
\begin{itemize}
 | 
|
| 221 | 535  | 
\item If there is a number as input token, then this token is  | 
| 224 | 536  | 
transferred directly to the output list. Then the rest of the input is  | 
| 221 | 537  | 
processed.  | 
538  | 
\item If there is an operator as input token, then you need to check  | 
|
539  | 
what is on top of the operator stack. If there are operators with  | 
|
540  | 
a higher or equal precedence, these operators are first popped off  | 
|
| 224 | 541  | 
from the stack and moved to the output list. Then the operator from the input  | 
| 221 | 542  | 
is pushed onto the stack and the rest of the input is processed.  | 
543  | 
\item If the input is a left-parenthesis, you push it on to the stack  | 
|
544  | 
and continue processing the input.  | 
|
| 224 | 545  | 
\item If the input is a right-parenthesis, then you pop off all operators  | 
| 221 | 546  | 
from the stack to the output list until you reach the left-parenthesis.  | 
547  | 
Then you discharge the $($ and $)$ from the input and stack, and continue  | 
|
| 224 | 548  | 
processing the input list.  | 
| 221 | 549  | 
\item If the input is empty, then you move all remaining operators  | 
550  | 
from the stack to the output list.  | 
|
551  | 
\end{itemize}  
 | 
|
| 218 | 552  | 
|
| 221 | 553  | 
\subsubsection*{Tasks (file postfix.scala)}
 | 
| 109 | 554  | 
|
| 221 | 555  | 
\begin{itemize}
 | 
| 224 | 556  | 
\item[(7)] Implement the shunting yard algorithm described above. The  | 
| 221 | 557  | 
  function, called \texttt{syard}, takes a list of tokens as first
 | 
558  | 
argument. The second and third arguments are the stack and output  | 
|
559  | 
list represented as Scala lists. The most convenient way to  | 
|
560  | 
implement this algorithm is to analyse what the input list, stack  | 
|
| 224 | 561  | 
and output list look like in each step using pattern-matching. The  | 
| 221 | 562  | 
algorithm transforms for example the input  | 
| 218 | 563  | 
|
| 221 | 564  | 
\[  | 
565  | 
  \texttt{List(3, +, 4, *, (, 2, -, 1, ))}
 | 
|
566  | 
\]  | 
|
| 109 | 567  | 
|
| 221 | 568  | 
into the postfix output  | 
| 218 | 569  | 
|
| 221 | 570  | 
\[  | 
571  | 
  \texttt{List(3, 4, 2, 1, -, *, +)}
 | 
|
572  | 
\]  | 
|
| 109 | 573  | 
|
| 221 | 574  | 
You can assume the input list is always a list representing  | 
575  | 
a well-formed infix arithmetic expression.\hfill[1 Mark]  | 
|
576  | 
||
577  | 
\item[(8)] Implement a compute function that takes a postfix expression  | 
|
578  | 
as argument and evaluates it generating an integer as result. It uses a  | 
|
579  | 
stack to evaluate the postfix expression. The operators $+$, $-$, $*$  | 
|
580  | 
are as usual; $/$ is division on integers, for example $7 / 3 = 2$.  | 
|
581  | 
\hfill[1 Mark]  | 
|
582  | 
\end{itemize}
 | 
|
583  | 
||
584  | 
\subsubsection*{Task (file postfix2.scala)}
 | 
|
585  | 
||
586  | 
\begin{itemize}
 | 
|
587  | 
\item[(9)] Extend the code in (7) and (8) to include the power  | 
|
588  | 
operator. This requires proper account of associativity of  | 
|
589  | 
the operators. The power operator is right-associative, whereas the  | 
|
590  | 
other operators are left-associative. Left-associative operators  | 
|
591  | 
are popped off if the precedence is bigger or equal, while  | 
|
592  | 
right-associative operators are only popped off if the precedence is  | 
|
593  | 
bigger. The compute function in this task should use  | 
|
594  | 
  \texttt{Long}s, rather than \texttt{Int}s.\hfill[2 Marks]
 | 
|
595  | 
\end{itemize}
 | 
|
| 218 | 596  | 
|
597  | 
||
598  | 
||
| 6 | 599  | 
|
600  | 
\end{document}
 | 
|
601  | 
||
| 68 | 602  | 
|
| 6 | 603  | 
%%% Local Variables:  | 
604  | 
%%% mode: latex  | 
|
605  | 
%%% TeX-master: t  | 
|
606  | 
%%% End:  |