author | Christian Urban <urbanc@in.tum.de> |
Mon, 21 Jan 2019 16:04:30 +0000 | |
changeset 257 | ba4d976ca88d |
parent 253 | ec7a12806c3f |
child 275 | eb1b4ad23941 |
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
67ce930b5935
updated
Christian Urban <christian dot urban at kcl dot ac dot uk>
parents:
100
diff
changeset
|
215 |
|
67ce930b5935
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
67ce930b5935
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
67ce930b5935
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
67ce930b5935
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
67ce930b5935
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
67ce930b5935
updated
Christian Urban <christian dot urban at kcl dot ac dot uk>
parents:
100
diff
changeset
|
296 |
|
67ce930b5935
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
67ce930b5935
updated
Christian Urban <christian dot urban at kcl dot ac dot uk>
parents:
100
diff
changeset
|
307 |
\end{center} |
67ce930b5935
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
67ce930b5935
updated
Christian Urban <christian dot urban at kcl dot ac dot uk>
parents:
100
diff
changeset
|
386 |
\end{itemize} |
67ce930b5935
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
67ce930b5935
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: |