| author | Christian Urban <urbanc@in.tum.de> | 
| Wed, 07 Aug 2019 14:32:21 +0100 | |
| changeset 272 | a091de62e3f8 | 
| 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: 
100diff
changeset | 215 | |
| 
0f9f774c7697
updated
 Christian Urban <christian dot urban at kcl dot ac dot uk> parents: 
100diff
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: 
100diff
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: 
100diff
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: 
100diff
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: 
100diff
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: 
100diff
changeset | 296 | |
| 
0f9f774c7697
updated
 Christian Urban <christian dot urban at kcl dot ac dot uk> parents: 
100diff
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: 
100diff
changeset | 307 |   \end{center}
 | 
| 
0f9f774c7697
updated
 Christian Urban <christian dot urban at kcl dot ac dot uk> parents: 
100diff
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: 
100diff
changeset | 386 | \end{itemize}
 | 
| 
0f9f774c7697
updated
 Christian Urban <christian dot urban at kcl dot ac dot uk> parents: 
100diff
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: 
100diff
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: |