diff -r d99c0026ebaf -r 89c9fcb211a8 msc-projects-12.html --- a/msc-projects-12.html Sat Nov 17 13:56:30 2012 +0000 +++ b/msc-projects-12.html Sat Nov 17 20:04:29 2012 +0000 @@ -57,8 +57,8 @@ PPDP'12 conference. The task in this project is to implement the results from this paper.
The background for this project is that some regular expressions are
- "evil"
- and can "stab you in the back" according to
+ “evil”
+ and can “stab you in the back” according to
this blog post.
For example, if you use in Python or
in Ruby (probably also in other mainstream programming languages) the
@@ -69,7 +69,7 @@
re.rb
(Ruby version). You can imagine an attacker
mounting a nice DoS attack against
- your program if it contains such an "evil" regular expression. Actually
+ your program if it contains such an “evil” regular expression. Actually
Scala (and also Java) are almost immune from such
attacks as they can deal with strings of up to 4,300 a
s in less than a second. But if you scale
the regular expression and string further to, say, 4,600 a
s, then you get a StackOverflowError
@@ -87,7 +87,7 @@
derivatives of regular expressions.
These derivatives were introduced in 1964 by
Janusz Brzozowski, but according to this
- paper had been lost in the "sands of time".
+ paper had been lost in the “sands of time”.
The advantage of derivatives is that they side-step completely the usual
translations of regular expressions
into NFAs or DFAs, which can introduce the exponential behaviour exhibited by the regular
@@ -106,7 +106,7 @@
I used them once myself in a paper
in order to prove the Myhill-Nerode theorem.
So I know they are worth their money. Still, it would be interesting to actually compare their results
- with my simple rainy-afternoon matcher and potentially "blow away" the regular expression matchers
+ with my simple rainy-afternoon matcher and potentially “blow away” the regular expression matchers
in Python and Ruby (and possibly in Scala too).
However, there is one restriction that makes this project harder than it seems - as first sight. The department does not allow large server applications and databases - to be run on calcium - the central server in the department. So the problem should be solved with as few resources needed - on the "back-end" which collects the votes. + at first sight: The department does not allow large server applications and databases + to be run on calcium, which is the central server in the department. So the problem + should be solved with as few resources as possible + on the “back-end” collecting the votes.