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