C[omp]ute

Welcome to my blog, which was once a mailing list of the same name and is still generated by mail. Please reply via the "comment" links.

Always interested in offers/projects/new ideas. Eclectic experience in fields like: numerical computing; Python web; Java enterprise; functional languages; GPGPU; SQL databases; etc. Based in Santiago, Chile; telecommute worldwide. CV; email.

Personal Projects

Choochoo Training Diary

Last 100 entries

Implementing a Regular Expression Engine

From: "andrew cooke" <andrew@...>

Date: Sun, 22 Mar 2009 20:21:29 -0400 (CLT)

A week or two ago I posted a message here saying I had implemented a
regular expression engine.  I deleted it today...

It would be more correct to say I have been learning about how to
implement a regular expression engine by failing to implement one. 
However, I am making some progress.

My initial take on regular expressions was to treat them as a tree
(basically the parse tree you would expect from their string
representation).  While that wasn't necessarily wrong, it made life a lot
harder than it should have been - it is much easier to model them as
directed graphs.

One translated into graph form, it's pretty easy to generate a
non-deterministic finite automaton that does the appropriate matching. 
That's because it's pretty much the same as the core loop for trampolined
recursive descent parser.  You can even get all the different matches with
back-tracking (technically I am therefore implementing the NFA (with eta
transitions, which are useful to order different parts of the automoaton)
using a PDA, which is more general and so explains the connection to
recursive descent parsing).

That's as far as I have got.  A previous post here gives references on how
to translate the NFA to a DFA (which being deterministic is a lot easier
to "run"; the flip side is that it may have exponentially more states and
there's no way to implement it so that all variations (non greedy matching
etc) are returned).

My aim is to make this NFA a standard LEPL matcher.  The DFA
implementation will be used for lexing.  In the future I'd also like to
see if compiling Any, Literal, Word etc (and combinations with And, Or,
Repeat) to NFA make things faster.

Andrew

http://en.wikipedia.org/wiki/Automata_theory - the table at the bottom is
particularly useful.

Initial DFA Results

From: "andrew cooke" <andrew@...>

Date: Tue, 24 Mar 2009 20:52:27 -0400 (CLT)

This is sweet - it's nice when a piece of code does things you didn't
really expect it to do (I mean, in theory, I can see why it works, but in
practice, the way it solves the problems is almost "intelligent").

Here's an example for the regexp a(bc|b*d):

     a      d
  0 ---> 1 +--> 2* <--+----.
           |b     c/d |    |
           `--> 3 +---'    |
                  |b      d|
                  `--> 4 +-'
                  '      |b
                  |      |
                  `------'

or, as printed (the [...] are the original nfa nodes):

  0 [0]       a:1,
  1 [3, 5, 6] d:2;b:3,
  2 [1, 2]    label,
  3 [4, 5, 6] b:4;[c-d]:2,
  4 [5, 6]    b:4;d:2

Andrew

Original NFA

From: "andrew cooke" <andrew@...>

Date: Tue, 24 Mar 2009 21:11:09 -0400 (CLT)

Just for fun, here's the underlying NFA (with eta/empty transitions). 
This is easier to construct (both by hand and in code)

      a     b      c
  0 ---> 3 +--> 4 ----------+> 1 ---> 2 "label"
           |                |
           |              d |
           `--> 5 +--> 6 ---'
           '      |
           |   b  |
           `------'

0 a:3
1 2
2 label
3 b:4 5
4 c:1
5 b:5 6,
6 d:1

(This is all left to right except for the b* loop from/to 5 at the bottom)

Andrew

Epsilon!

From: "andrew cooke" <andrew@...>

Date: Tue, 24 Mar 2009 21:25:35 -0400 (CLT)

I've been calling my epsilons etas!  Ooops.  Andrew

Comment on this post