| author | Christian Urban <christian.urban@kcl.ac.uk> | 
| Fri, 05 Nov 2021 16:47:55 +0000 | |
| changeset 396 | ea39bbc8d98d | 
| parent 390 | 720206dcacf7 | 
| child 412 | 5f2d547b4045 | 
| 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 | ||
| 351 | 91 | \begin{filecontents}{re-swift.data}
 | 
| 92 | 5 0.001 | |
| 93 | 10 0.001 | |
| 94 | 15 0.009 | |
| 95 | 20 0.178 | |
| 96 | 23 1.399 | |
| 97 | 24 2.893 | |
| 98 | 25 5.671 | |
| 99 | 26 11.357 | |
| 100 | 27 22.430 | |
| 101 | \end{filecontents}
 | |
| 102 | ||
| 103 | \begin{filecontents}{re-dart.data}
 | |
| 104 | 20 0.042 | |
| 105 | 21 0.084 | |
| 106 | 22 0.190 | |
| 107 | 23 0.340 | |
| 108 | 24 0.678 | |
| 109 | 25 1.369 | |
| 110 | 26 2.700 | |
| 111 | 27 5.462 | |
| 112 | 28 10.908 | |
| 113 | 29 21.725 | |
| 114 | 30 43.492 | |
| 115 | \end{filecontents}
 | |
| 6 | 116 | |
| 117 | \begin{document}
 | |
| 118 | ||
| 218 | 119 | % BF IDE | 
| 120 | % https://www.microsoft.com/en-us/p/brainf-ck/9nblgggzhvq5 | |
| 121 | ||
| 396 | 122 | \section*{Main Part 3 (Scala, 6 Marks)}
 | 
| 6 | 123 | |
| 351 | 124 | %\mbox{}\hfill\textit{``[Google’s MapReduce] abstraction is inspired by the}\\
 | 
| 125 | %\mbox{}\hfill\textit{map and reduce primitives present in Lisp and many}\\
 | |
| 126 | %\mbox{}\hfill\textit{other functional language.''}\smallskip\\
 | |
| 127 | %\mbox{}\hfill\textit{ --- Dean and Ghemawat, who designed this concept at Google}
 | |
| 128 | %\bigskip\medskip | |
| 275 | 129 | |
| 130 | \noindent | |
| 351 | 131 | This part is about a regular expression matcher described by | 
| 132 | Brzozowski in 1964. This part is due on \cwEIGHTa{} at 5pm.  The
 | |
| 133 | background is that ``out-of-the-box'' regular expression matching in | |
| 134 | mainstream languages like Java, JavaScript and Python can sometimes be | |
| 135 | excruciatingly slow. You are supposed to implement a regular | |
| 136 | expression matcher that is much, much faster. \bigskip | |
| 218 | 137 | |
| 351 | 138 | \IMPORTANTNONE{}
 | 
| 62 | 139 | |
| 140 | \noindent | |
| 218 | 141 | Also note that the running time of each part will be restricted to a | 
| 257 | 142 | maximum of 30 seconds on my laptop. | 
| 218 | 143 | |
| 144 | \DISCLAIMER{}
 | |
| 86 | 145 | |
| 221 | 146 | \subsection*{Reference Implementation}
 | 
| 147 | ||
| 351 | 148 | This Scala assignment comes with a reference implementation in form of | 
| 149 | a \texttt{jar}-file. This allows you to run any test cases on your own
 | |
| 221 | 150 | computer. For example you can call Scala on the command line with the | 
| 151 | option \texttt{-cp re.jar} and then query any function from the
 | |
| 351 | 152 | \texttt{re.scala} template file. As usual you have to prefix the calls
 | 
| 396 | 153 | with \texttt{M3} or import this object.  Since some tasks
 | 
| 351 | 154 | are time sensitive, you can check the reference implementation as | 
| 155 | follows: if you want to know, for example, how long it takes to match | |
| 156 | strings of $a$'s using the regular expression $(a^*)^*\cdot b$ you can | |
| 157 | query as follows: | |
| 221 | 158 | |
| 159 | ||
| 245 | 160 | \begin{lstlisting}[xleftmargin=1mm,numbers=none,basicstyle=\ttfamily\small]
 | 
| 221 | 161 | $ scala -cp re.jar | 
| 396 | 162 | scala> import M3._ | 
| 221 | 163 | scala> for (i <- 0 to 5000000 by 500000) {
 | 
| 292 | 164 |   | println(f"$i: ${time_needed(2, matcher(EVIL, "a" * i))}%.5f secs.")
 | 
| 221 | 165 | | } | 
| 292 | 166 | 0: 0.00002 secs. | 
| 167 | 500000: 0.10608 secs. | |
| 168 | 1000000: 0.22286 secs. | |
| 169 | 1500000: 0.35982 secs. | |
| 170 | 2000000: 0.45828 secs. | |
| 171 | 2500000: 0.59558 secs. | |
| 172 | 3000000: 0.73191 secs. | |
| 173 | 3500000: 0.83499 secs. | |
| 174 | 4000000: 0.99149 secs. | |
| 175 | 4500000: 1.15395 secs. | |
| 176 | 5000000: 1.29659 secs. | |
| 221 | 177 | \end{lstlisting}%$
 | 
| 178 | ||
| 351 | 179 | \subsection*{Preliminaries}
 | 
| 218 | 180 | |
| 181 | The task is to implement a regular expression matcher that is based on | |
| 182 | derivatives of regular expressions. Most of the functions are defined by | |
| 183 | recursion over regular expressions and can be elegantly implemented | |
| 184 | using Scala's pattern-matching. The implementation should deal with the | |
| 185 | following regular expressions, which have been predefined in the file | |
| 186 | \texttt{re.scala}:
 | |
| 6 | 187 | |
| 218 | 188 | \begin{center}
 | 
| 189 | \begin{tabular}{lcll}
 | |
| 190 | $r$ & $::=$ & $\ZERO$ & cannot match anything\\ | |
| 191 | & $|$ & $\ONE$ & can only match the empty string\\ | |
| 192 | & $|$ & $c$ & can match a single character (in this case $c$)\\ | |
| 193 | & $|$ & $r_1 + r_2$ & can match a string either with $r_1$ or with $r_2$\\ | |
| 194 | & $|$ & $r_1\cdot r_2$ & can match the first part of a string with $r_1$ and\\ | |
| 195 | & & & then the second part with $r_2$\\ | |
| 221 | 196 | & $|$ & $r^*$ & can match a string with zero or more copies of $r$\\ | 
| 218 | 197 | \end{tabular}
 | 
| 198 | \end{center}
 | |
| 6 | 199 | |
| 218 | 200 | \noindent | 
| 221 | 201 | Why? Regular expressions are | 
| 202 | one of the simplest ways to match patterns in text, and | |
| 218 | 203 | are endlessly useful for searching, editing and analysing data in all | 
| 204 | sorts of places (for example analysing network traffic in order to | |
| 205 | detect security breaches). However, you need to be fast, otherwise you | |
| 206 | will stumble over problems such as recently reported at | |
| 207 | ||
| 208 | {\small
 | |
| 209 | \begin{itemize}
 | |
| 289 | 210 | \item[$\bullet$] \url{https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019}  
 | 
| 211 | \item[$\bullet$] \url{https://stackstatus.net/post/147710624694/outage-postmortem-july-20-2016}
 | |
| 218 | 212 | \item[$\bullet$] \url{https://vimeo.com/112065252}
 | 
| 289 | 213 | \item[$\bullet$] \url{https://davidvgalbraith.com/how-i-fixed-atom}  
 | 
| 218 | 214 | \end{itemize}}
 | 
| 215 | ||
| 221 | 216 | % Knowing how to match regular expressions and strings will let you | 
| 217 | % solve a lot of problems that vex other humans. | |
| 218 | ||
| 219 | ||
| 218 | 220 | \subsubsection*{Tasks (file re.scala)}
 | 
| 6 | 221 | |
| 218 | 222 | The file \texttt{re.scala} has already a definition for regular
 | 
| 223 | expressions and also defines some handy shorthand notation for | |
| 224 | regular expressions. The notation in this document matches up | |
| 225 | with the code in the file as follows: | |
| 226 | ||
| 227 | \begin{center}
 | |
| 228 |   \begin{tabular}{rcl@{\hspace{10mm}}l}
 | |
| 229 | & & code: & shorthand:\smallskip \\ | |
| 230 |   $\ZERO$ & $\mapsto$ & \texttt{ZERO}\\
 | |
| 231 |   $\ONE$  & $\mapsto$ & \texttt{ONE}\\
 | |
| 232 |   $c$     & $\mapsto$ & \texttt{CHAR(c)}\\
 | |
| 396 | 233 |   $\sum rs$ & $\mapsto$ & \texttt{ALTs(rs)}\\  
 | 
| 218 | 234 |   $r_1 + r_2$ & $\mapsto$ & \texttt{ALT(r1, r2)} & \texttt{r1 | r2}\\
 | 
| 235 |   $r_1 \cdot r_2$ & $\mapsto$ & \texttt{SEQ(r1, r2)} & \texttt{r1 $\sim$ r2}\\
 | |
| 236 |   $r^*$ & $\mapsto$ &  \texttt{STAR(r)} & \texttt{r.\%}
 | |
| 237 | \end{tabular}    
 | |
| 238 | \end{center}  
 | |
| 239 | ||
| 396 | 240 | \noindent | 
| 241 | The alternative regular expressions comes in two versions: one is | |
| 242 | binary (+ / \texttt{ALT}) and the other is n-ary ($\sum$ /
 | |
| 243 | \texttt{ALTs}). The latter takes a list of regular expressions as
 | |
| 244 | arguments. In what follows we shall use $rs$ to stand for lists of | |
| 245 | regular expressions. The binary alternative can be seen as an abbreviation, | |
| 246 | that is $r_1 + r_2 \dn \sum\,[r_1, r_2]$. As a result we can ignore the | |
| 247 | binary version and only implement the n-ary alternative. | |
| 105 
0f9f774c7697
updated
 Christian Urban <christian dot urban at kcl dot ac dot uk> parents: 
100diff
changeset | 248 | |
| 
0f9f774c7697
updated
 Christian Urban <christian dot urban at kcl dot ac dot uk> parents: 
100diff
changeset | 249 | \begin{itemize}
 | 
| 351 | 250 | \item[(1)] Implement a function, called \textit{nullable}, by
 | 
| 218 | 251 | recursion over regular expressions. This function tests whether a | 
| 252 | regular expression can match the empty string. This means given a | |
| 253 | regular expression it either returns true or false. The function | |
| 254 |   \textit{nullable}
 | |
| 255 | is defined as follows: | |
| 256 | ||
| 257 | \begin{center}
 | |
| 258 | \begin{tabular}{lcl}
 | |
| 259 | $\textit{nullable}(\ZERO)$ & $\dn$ & $\textit{false}$\\
 | |
| 260 | $\textit{nullable}(\ONE)$  & $\dn$ & $\textit{true}$\\
 | |
| 261 | $\textit{nullable}(c)$     & $\dn$ & $\textit{false}$\\
 | |
| 396 | 262 | $\textit{nullable}(\sum rs)$ & $\dn$ & $\exists r \in rs.\;\textit{nullable}(r)$\\
 | 
| 218 | 263 | $\textit{nullable}(r_1 \cdot r_2)$ & $\dn$ & $\textit{nullable}(r_1) \wedge \textit{nullable}(r_2)$\\
 | 
| 264 | $\textit{nullable}(r^*)$ & $\dn$ & $\textit{true}$\\
 | |
| 265 | \end{tabular}
 | |
| 396 | 266 | \end{center}~\hfill[0.5 Marks]
 | 
| 105 
0f9f774c7697
updated
 Christian Urban <christian dot urban at kcl dot ac dot uk> parents: 
100diff
changeset | 267 | |
| 351 | 268 | \item[(2)] Implement a function, called \textit{der}, by recursion over
 | 
| 218 | 269 | regular expressions. It takes a character and a regular expression | 
| 289 | 270 | as arguments and calculates the derivative of a regular expression according | 
| 218 | 271 | to the rules: | 
| 105 
0f9f774c7697
updated
 Christian Urban <christian dot urban at kcl dot ac dot uk> parents: 
100diff
changeset | 272 | |
| 218 | 273 | \begin{center}
 | 
| 274 | \begin{tabular}{lcl}
 | |
| 275 | $\textit{der}\;c\;(\ZERO)$ & $\dn$ & $\ZERO$\\
 | |
| 276 | $\textit{der}\;c\;(\ONE)$  & $\dn$ & $\ZERO$\\
 | |
| 277 | $\textit{der}\;c\;(d)$     & $\dn$ & $\textit{if}\; c = d\;\textit{then} \;\ONE \; \textit{else} \;\ZERO$\\
 | |
| 396 | 278 | $\textit{der}\;c\;(\sum\;[r_1,..,r_n])$ & $\dn$ & $\sum\;[\textit{der}\;c\;r_1,..,\textit{der}\;c\;r_n]$\\
 | 
| 218 | 279 | $\textit{der}\;c\;(r_1 \cdot r_2)$ & $\dn$ & $\textit{if}\;\textit{nullable}(r_1)$\\
 | 
| 280 |       & & $\textit{then}\;((\textit{der}\;c\;r_1)\cdot r_2) + (\textit{der}\;c\;r_2)$\\
 | |
| 281 |       & & $\textit{else}\;(\textit{der}\;c\;r_1)\cdot r_2$\\
 | |
| 282 | $\textit{der}\;c\;(r^*)$ & $\dn$ & $(\textit{der}\;c\;r)\cdot (r^*)$\\
 | |
| 283 | \end{tabular}
 | |
| 284 | \end{center}
 | |
| 285 | ||
| 286 | For example given the regular expression $r = (a \cdot b) \cdot c$, the derivatives | |
| 287 | 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 | 288 | |
| 218 | 289 | \begin{center}
 | 
| 290 |   \begin{tabular}{lcll}
 | |
| 221 | 291 |     $\textit{der}\;a\;r$ & $=$ & $(\ONE \cdot b)\cdot c$ & \quad($= r'$)\\
 | 
| 218 | 292 |     $\textit{der}\;b\;r$ & $=$ & $(\ZERO \cdot b)\cdot c$\\
 | 
| 293 |     $\textit{der}\;c\;r$ & $=$ & $(\ZERO \cdot b)\cdot c$
 | |
| 294 |   \end{tabular}
 | |
| 295 | \end{center}
 | |
| 296 | ||
| 297 | Let $r'$ stand for the first derivative, then taking the derivatives of $r'$ | |
| 298 | w.r.t.~the characters $a$, $b$ and $c$ gives | |
| 299 | ||
| 300 | \begin{center}
 | |
| 301 |   \begin{tabular}{lcll}
 | |
| 302 |     $\textit{der}\;a\;r'$ & $=$ & $((\ZERO \cdot b) + \ZERO)\cdot c$ \\
 | |
| 221 | 303 |     $\textit{der}\;b\;r'$ & $=$ & $((\ZERO \cdot b) + \ONE)\cdot c$ & \quad($= r''$)\\
 | 
| 218 | 304 |     $\textit{der}\;c\;r'$ & $=$ & $((\ZERO \cdot b) + \ZERO)\cdot c$
 | 
| 305 |   \end{tabular}
 | |
| 306 | \end{center}
 | |
| 105 
0f9f774c7697
updated
 Christian Urban <christian dot urban at kcl dot ac dot uk> parents: 
100diff
changeset | 307 | |
| 218 | 308 | One more example: Let $r''$ stand for the second derivative above, | 
| 309 | then taking the derivatives of $r''$ w.r.t.~the characters $a$, $b$ | |
| 310 | and $c$ gives | |
| 311 | ||
| 312 | \begin{center}
 | |
| 313 |   \begin{tabular}{lcll}
 | |
| 314 |     $\textit{der}\;a\;r''$ & $=$ & $((\ZERO \cdot b) + \ZERO) \cdot c + \ZERO$ \\
 | |
| 315 |     $\textit{der}\;b\;r''$ & $=$ & $((\ZERO \cdot b) + \ZERO) \cdot c + \ZERO$\\
 | |
| 316 |     $\textit{der}\;c\;r''$ & $=$ & $((\ZERO \cdot b) + \ZERO) \cdot c + \ONE$ &
 | |
| 317 |     (is $\textit{nullable}$)                      
 | |
| 318 |   \end{tabular}
 | |
| 319 | \end{center}
 | |
| 320 | ||
| 321 | Note, the last derivative can match the empty string, that is it is \textit{nullable}.\\
 | |
| 322 | \mbox{}\hfill\mbox{[1 Mark]}
 | |
| 323 | ||
| 396 | 324 | \item[(3)] We next want to simplify regular expressions: essentially | 
| 325 | we want to remove $\ZERO$ in regular expressions like $r + \ZERO$ | |
| 326 | and $\ZERO + r$. However, our n-ary alternative takes a list of | |
| 327 | regular expressions as argument, we therefore need a more general | |
| 328 |   ``flatten'' function, called \texttt{flts}. This function should
 | |
| 329 | analyse a list of regular expressions, say $rs$, as follows: | |
| 330 | ||
| 331 |   \begin{center}
 | |
| 332 |     \begin{tabular}{lllll}
 | |
| 333 | 1) &$rs = []$ & $\dn$ & $[]$ & (empty list)\\ | |
| 334 |       2) &$rs = \ZERO :: rest$     & $\dn$ & $\textrm{flatten}\;rest$\\
 | |
| 335 |       3) &$rs = (\sum rs_1) :: rest$ & $\dn$ & $rs_1 ::: \textrm{flatten}\;rest$\\
 | |
| 336 |       4) &$rs = r :: rest$         & $\dn$ & $r :: \textrm{flatten}\;rest$ & (otherwise)\\
 | |
| 337 |     \end{tabular}  
 | |
| 338 |   \end{center}  
 | |
| 339 | ||
| 340 | The first clause just states that empty lists cannot be further | |
| 341 | flattened. The second removes all $\ZERO$s from the list. | |
| 342 |   The third is when the first regular expression is an \texttt{ALTs}, then
 | |
| 343 | the content of this alternative should be spilled out and appended | |
| 344 | with the flattened rest of the list. The last case is for all other | |
| 345 |   cases where the head of the list is not $\ZERO$ and not an \texttt{ALTs},
 | |
| 346 | then we just keep the head of the list and flatten the rest. | |
| 347 |   \mbox{}\hfill\mbox{[1 Mark]}
 | |
| 348 | ||
| 349 | \item[(4)] Implement the function \textit{simp}, which recursively
 | |
| 224 | 350 | traverses a regular expression, and on the way up simplifies every | 
| 351 | regular expression on the left (see below) to the regular expression | |
| 352 |   on the right, except it does not simplify inside ${}^*$-regular
 | |
| 353 | expressions. | |
| 105 
0f9f774c7697
updated
 Christian Urban <christian dot urban at kcl dot ac dot uk> parents: 
100diff
changeset | 354 | |
| 
0f9f774c7697
updated
 Christian Urban <christian dot urban at kcl dot ac dot uk> parents: 
100diff
changeset | 355 |   \begin{center}
 | 
| 218 | 356 | \begin{tabular}{l@{\hspace{4mm}}c@{\hspace{4mm}}ll}
 | 
| 357 | $r \cdot \ZERO$ & $\mapsto$ & $\ZERO$\\ | |
| 358 | $\ZERO \cdot r$ & $\mapsto$ & $\ZERO$\\ | |
| 359 | $r \cdot \ONE$ & $\mapsto$ & $r$\\ | |
| 360 | $\ONE \cdot r$ & $\mapsto$ & $r$\\ | |
| 396 | 361 | $\sum\;[r_1,..,r_n]$ & $\mapsto$ & $\sum\;(\texttt{(flts + distinct)}[simp(r_1),..,simp(r_n)])$\\  
 | 
| 218 | 362 | \end{tabular}
 | 
| 396 | 363 | \end{center}
 | 
| 364 | ||
| 365 | The last case is as follows: first apply $simp$ to all regular expressions | |
| 366 |   $r_1,.. ,r_n$; then flatten the resulting list using \texttt{flts};
 | |
| 367 | finally remove all duplicates in this list (this can be done in Scala | |
| 368 |   using the function \texttt{\_.distinct}).
 | |
| 105 
0f9f774c7697
updated
 Christian Urban <christian dot urban at kcl dot ac dot uk> parents: 
100diff
changeset | 369 | |
| 218 | 370 | For example the regular expression | 
| 371 | \[(r_1 + \ZERO) \cdot \ONE + ((\ONE + r_2) + r_3) \cdot (r_4 \cdot \ZERO)\] | |
| 372 | ||
| 373 |   simplifies to just $r_1$. \textbf{Hint:} Regular expressions can be
 | |
| 374 | seen as trees and there are several methods for traversing | |
| 396 | 375 | trees. One of them corresponds to the inside-out traversal, which is | 
| 376 | also sometimes called post-order tra\-versal: you traverse inside | |
| 377 | the tree and on the way up you apply simplification rules. | |
| 378 |   \textbf{Another Hint:} Remember numerical expressions from school
 | |
| 379 | times---there you had expressions like | |
| 380 | $u + \ldots + (1 \cdot x) - \ldots (z + (y \cdot 0)) \ldots$ and | |
| 381 | simplification rules that looked very similar to rules above. You | |
| 382 | would simplify such numerical expressions by replacing for example | |
| 383 | the $y \cdot 0$ by $0$, or $1\cdot x$ by $x$, and then look whether | |
| 384 | more rules are applicable. If you regard regular expressions as | |
| 385 | trees and if you organise the simplification in an inside-out | |
| 386 | fashion, it is always clear which simplification should be applied | |
| 387 |   next.\mbox{}\hfill\mbox{[1 Mark]}
 | |
| 218 | 388 | |
| 396 | 389 | \item[(5)] Implement two functions: The first, called \textit{ders},
 | 
| 218 | 390 | takes a list of characters and a regular expression as arguments, and | 
| 391 | builds the derivative w.r.t.~the list as follows: | |
| 392 | ||
| 393 | \begin{center}
 | |
| 394 | \begin{tabular}{lcl}
 | |
| 395 | $\textit{ders}\;(Nil)\;r$ & $\dn$ & $r$\\
 | |
| 396 |   $\textit{ders}\;(c::cs)\;r$  & $\dn$ &
 | |
| 397 |     $\textit{ders}\;cs\;(\textit{simp}(\textit{der}\;c\;r))$\\
 | |
| 398 | \end{tabular}
 | |
| 399 | \end{center}
 | |
| 400 | ||
| 401 | Note that this function is different from \textit{der}, which only
 | |
| 402 | takes a single character. | |
| 403 | ||
| 404 | The second function, called \textit{matcher}, takes a string and a
 | |
| 405 | regular expression as arguments. It builds first the derivatives | |
| 406 | according to \textit{ders} and after that tests whether the resulting
 | |
| 407 | derivative regular expression can match the empty string (using | |
| 408 | \textit{nullable}).  For example the \textit{matcher} will produce
 | |
| 409 | true for the regular expression $(a\cdot b)\cdot c$ and the string | |
| 410 | $abc$, but false if you give it the string $ab$. \hfill[1 Mark] | |
| 411 | ||
| 396 | 412 | \item[(6)] Implement a function, called \textit{size}, by recursion
 | 
| 218 | 413 | over regular expressions. If a regular expression is seen as a tree, | 
| 414 |   then \textit{size} should return the number of nodes in such a
 | |
| 415 | tree. Therefore this function is defined as follows: | |
| 416 | ||
| 417 | \begin{center}
 | |
| 418 | \begin{tabular}{lcl}
 | |
| 419 | $\textit{size}(\ZERO)$ & $\dn$ & $1$\\
 | |
| 420 | $\textit{size}(\ONE)$  & $\dn$ & $1$\\
 | |
| 421 | $\textit{size}(c)$     & $\dn$ & $1$\\
 | |
| 396 | 422 | $\textit{size}(\sum\,[r_1,..,r_n]$ & $\dn$ & $1 + \textit{size}(r_1) + ... + \textit{size}(r_n)$\\
 | 
| 218 | 423 | $\textit{size}(r_1 \cdot r_2)$ & $\dn$ & $1 + \textit{size}(r_1) + \textit{size}(r_2)$\\
 | 
| 424 | $\textit{size}(r^*)$ & $\dn$ & $1 + \textit{size}(r)$\\
 | |
| 425 | \end{tabular}
 | |
| 426 | \end{center}
 | |
| 427 | ||
| 224 | 428 | You can use \textit{size} in order to test how much the ``evil'' regular
 | 
| 218 | 429 | expression $(a^*)^* \cdot b$ grows when taking successive derivatives | 
| 430 | according the letter $a$ without simplification and then compare it to | |
| 431 | taking the derivative, but simplify the result. The sizes | |
| 396 | 432 | are given in \texttt{re.scala}. \hfill[0.5 Marks]
 | 
| 221 | 433 | |
| 396 | 434 | \item[(7)] You do not have to implement anything specific under this | 
| 221 | 435 | task. The purpose here is that you will be marked for some ``power'' | 
| 436 | test cases. For example can your matcher decide within 30 seconds | |
| 437 | whether the regular expression $(a^*)^*\cdot b$ matches strings of the | |
| 438 |   form $aaa\ldots{}aaaa$, for say 1 Million $a$'s. And does simplification
 | |
| 439 | simplify the regular expression | |
| 440 | ||
| 441 | \[ | |
| 442 |   \texttt{SEQ(SEQ(SEQ(..., ONE | ONE) , ONE | ONE), ONE | ONE)}
 | |
| 443 | \] | |
| 444 | ||
| 445 |   \noindent correctly to just \texttt{ONE}, where \texttt{SEQ} is nested
 | |
| 245 | 446 | 50 or more times?\\ | 
| 396 | 447 |   \mbox{}\hfill[1 Mark]
 | 
| 105 
0f9f774c7697
updated
 Christian Urban <christian dot urban at kcl dot ac dot uk> parents: 
100diff
changeset | 448 | \end{itemize}
 | 
| 
0f9f774c7697
updated
 Christian Urban <christian dot urban at kcl dot ac dot uk> parents: 
100diff
changeset | 449 | |
| 218 | 450 | \subsection*{Background}
 | 
| 451 | ||
| 396 | 452 | Although easily implementable in Scala (ok maybe the \texttt{simp} functions and
 | 
| 453 | \texttt{ALTs} needs a bit more thinking), the idea behind the
 | |
| 454 | derivative function might not so easy to be seen. To understand its | |
| 455 | purpose better, assume a regular expression $r$ can match strings of | |
| 456 | the form $c\!::\!cs$ (that means strings which start with a character | |
| 457 | $c$ and have some rest, or tail, $cs$). If you take the derivative of | |
| 458 | $r$ with respect to the character $c$, then you obtain a regular | |
| 459 | expression that can match all the strings $cs$. In other words, the | |
| 460 | regular expression $\textit{der}\;c\;r$ can match the same strings
 | |
| 461 | $c\!::\!cs$ that can be matched by $r$, except that the $c$ is chopped | |
| 462 | off. | |
| 218 | 463 | |
| 464 | Assume now $r$ can match the string $abc$. If you take the derivative | |
| 465 | according to $a$ then you obtain a regular expression that can match | |
| 466 | $bc$ (it is $abc$ where the $a$ has been chopped off). If you now | |
| 467 | build the derivative $\textit{der}\;b\;(\textit{der}\;a\;r)$ you
 | |
| 468 | obtain a regular expression that can match the string $c$ (it is $bc$ | |
| 469 | where $b$ is chopped off). If you finally build the derivative of this | |
| 470 | according $c$, that is | |
| 471 | $\textit{der}\;c\;(\textit{der}\;b\;(\textit{der}\;a\;r))$, you obtain
 | |
| 472 | a regular expression that can match the empty string. You can test | |
| 473 | whether this is indeed the case using the function nullable, which is | |
| 474 | what your matcher is doing. | |
| 475 | ||
| 476 | The purpose of the $\textit{simp}$ function is to keep the regular
 | |
| 477 | expressions small. Normally the derivative function makes the regular | |
| 221 | 478 | expression bigger (see the SEQ case and the example in (2)) and the | 
| 218 | 479 | algorithm would be slower and slower over time. The $\textit{simp}$
 | 
| 480 | function counters this increase in size and the result is that the | |
| 481 | algorithm is fast throughout. By the way, this algorithm is by Janusz | |
| 482 | Brzozowski who came up with the idea of derivatives in 1964 in his PhD | |
| 483 | thesis. | |
| 484 | ||
| 485 | \begin{center}\small
 | |
| 486 | \url{https://en.wikipedia.org/wiki/Janusz_Brzozowski_(computer_scientist)}
 | |
| 487 | \end{center}
 | |
| 488 | ||
| 105 
0f9f774c7697
updated
 Christian Urban <christian dot urban at kcl dot ac dot uk> parents: 
100diff
changeset | 489 | |
| 218 | 490 | If you want to see how badly the regular expression matchers do in | 
| 221 | 491 | Java\footnote{Version 8 and below; Version 9 and above does not seem to be as
 | 
| 492 | catastrophic, but still much worse than the regular expression | |
| 493 | matcher based on derivatives.}, JavaScript and Python with the | |
| 396 | 494 | ``evil'' regular expression $(a^*)^*\cdot b$, then have a look at the | 
| 351 | 495 | graphs below (you can try it out for yourself: have a look at the files | 
| 496 | \texttt{catastrophic9.java}, \texttt{catastrophic.js},
 | |
| 497 | \texttt{catastrophic.py} etc on KEATS). Compare this with the matcher you
 | |
| 396 | 498 | have implemented. How long can a string of $a$'s be in your matcher | 
| 499 | and still stay within the 30 seconds time limit? It should be muuuch better | |
| 500 | than your off-the-shelf matcher in your bog-standard language. | |
| 78 | 501 | |
| 218 | 502 | \begin{center}
 | 
| 503 | \begin{tabular}{@{}cc@{}}
 | |
| 504 | \multicolumn{2}{c}{Graph: $(a^*)^*\cdot b$ and strings 
 | |
| 505 |            $\underbrace{a\ldots a}_{n}$}\bigskip\\
 | |
| 506 | ||
| 507 | \begin{tikzpicture}
 | |
| 508 | \begin{axis}[
 | |
| 509 |     xlabel={$n$},
 | |
| 510 |     x label style={at={(1.05,0.0)}},
 | |
| 511 |     ylabel={time in secs},
 | |
| 512 |     y label style={at={(0.06,0.5)}},
 | |
| 513 | enlargelimits=false, | |
| 514 |     xtick={0,5,...,30},
 | |
| 515 | xmax=33, | |
| 516 | ymax=45, | |
| 517 |     ytick={0,5,...,40},
 | |
| 518 | scaled ticks=false, | |
| 519 | axis lines=left, | |
| 520 | width=6cm, | |
| 396 | 521 | height=5.0cm, | 
| 351 | 522 |     legend entries={Python, Java 8, JavaScript, Swift, Dart},  
 | 
| 222 | 523 | legend pos=north west, | 
| 524 | legend cell align=left] | |
| 218 | 525 | \addplot[blue,mark=*, mark options={fill=white}] table {re-python2.data};
 | 
| 526 | \addplot[cyan,mark=*, mark options={fill=white}] table {re-java.data};
 | |
| 221 | 527 | \addplot[red,mark=*, mark options={fill=white}] table {re-js.data};
 | 
| 351 | 528 | \addplot[magenta,mark=*, mark options={fill=white}] table {re-swift.data};
 | 
| 529 | \addplot[brown,mark=*, mark options={fill=white}] table {re-dart.data};
 | |
| 218 | 530 | \end{axis}
 | 
| 531 | \end{tikzpicture}
 | |
| 532 | & | |
| 533 | \begin{tikzpicture}
 | |
| 534 | \begin{axis}[
 | |
| 535 |     xlabel={$n$},
 | |
| 536 |     x label style={at={(1.05,0.0)}},
 | |
| 537 |     ylabel={time in secs},
 | |
| 538 |     y label style={at={(0.06,0.5)}},
 | |
| 539 | %enlargelimits=false, | |
| 540 |     %xtick={0,5000,...,30000},
 | |
| 541 | xmax=65000, | |
| 542 | ymax=45, | |
| 543 |     ytick={0,5,...,40},
 | |
| 544 | scaled ticks=false, | |
| 545 | axis lines=left, | |
| 546 | width=6cm, | |
| 396 | 547 | height=5.0cm, | 
| 218 | 548 |     legend entries={Java 9},  
 | 
| 549 | legend pos=north west] | |
| 550 | \addplot[cyan,mark=*, mark options={fill=white}] table {re-java9.data};
 | |
| 551 | \end{axis}
 | |
| 552 | \end{tikzpicture}
 | |
| 553 | \end{tabular}  
 | |
| 554 | \end{center}
 | |
| 555 | \newpage | |
| 556 | ||
| 557 | ||
| 558 | ||
| 559 | ||
| 6 | 560 | |
| 561 | \end{document}
 | |
| 562 | ||
| 68 | 563 | |
| 6 | 564 | %%% Local Variables: | 
| 565 | %%% mode: latex | |
| 566 | %%% TeX-master: t | |
| 567 | %%% End: |