Generate Regex from Examples
regex.inginf.units.it
regex.inginf.units.it
Automatic Generation of Regular Expressions from Examples with Genetic Programming[0]
Automatic String Replace by Examples [1]
[0] http://machinelearning.inginf.units.it/publications/internat...
[1] http://machinelearning.inginf.units.it/publications/internat...
we are experiencing some trouble with connectivity due to the... unexpected popularity :)
we are working to solve this, but we are a very small research group with limited resources.
meanwhile, if you are interested in the details of our algorithm take a look at the source code hosted here: https://github.com/MaLeLabTs/RegexGenerator
{a, b, c, d}
a | b | c | d
*
Negative examples constrain the most permissive interpretation to the regular language defined:
1a. Let NegativeExamples be the most restrictive regular
expression [as above] using the negative examples as
input.
or
1b. Let NegativeExamples be the most permissive regular
expression [as above] using the negative exmaples as
input.
2. Let U be the regular language defined by the kleene star.
U - NegativeExamples
Regular expressions are a compact way of precisely describing an enumeration of permutations. The only way to get equal precision via enumeration is to fully enumerate all the permutations. Once a parser gets into the picture, then the input strings have to have semantics that the parser can use and a hidden set of parser rules for interpreting those semantics.
Formally, regular expressions describe finite automata. A finite automata is a state machine that accepts a language. Hence, a regular expression defines a language [and in particular a regular language]. Regular languages have closure properties, which is to say that under certain operations two regular languages produce another regular language, and therefore certain operations on regular expressions can produce another regular expression.
The regular expression generator takes some input and produce a regular expression. There are two possible scenarios:
1. Treat the input as one or more regular languages
and perform only closed operations.
2. Treat the input as some other type of language,
e.g. a context free language and parse the input
according to the rules of that language to produce
a regular expression.
The second option means that in order to determine what output a given input will produce we have to know about a potentially unlimited number of rules (and these rules may change dynamically based on the input)[1].
What this means is that no regular expression generator is generally useful as a black box. Ambiguity assures it, and ambiguity is intrinsic because the regular expression generator must treat the input as within a more complex language (e.g. context free) and force it into the simpler class of regular languages. As my analysis shows, the way in which the regular expression generator interprets the input is arbitrary.
If you're really interested in the topic, Jeff Ulman (who with Alfred Aho wrote the book on automata) teaches a course on automata via Coursera. Rumor (well actually an email) has it that he is teaching it again this fall. A person could do worse than learning about automata from a person down a Stanford hallway from Donald Knuth's office.
Even cooler is that Jeff Ullman shows up in class to discuss questions (which is probably why the course only comes around once a year).
https://www.coursera.org/course/automata
Just because lunches cannot be free doesn't mean they can't be cheap.
[1] Moreover, via the Halting Problem we cannot be certain that the regular expression generator will produce any output at all.
The provided examples often cover a subset of the target language; there are infinite regular languages that fit the task---described by provided examples---and infinite number of regular expressions generating it. Regex generator searches for a regular expression taking into account other constraints---i.e: it prefers small regular expressions. In this way we use the regular expression length as heuristic that pushes towards more generic regular expressions and more human-readable-understandable solutions.
We know that we cannot infer a regular language from an incomplete subset of it; regex generator is intended as a practical tool that solves a real-world problem.
Anyhow, the literature is full of papers about inferring an automata from examples: http://link.springer.com/chapter/10.1007/BFb0054059 http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1299597 http://www.sciencedirect.com/science/article/pii/S0031320305... http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1432740
The empty language + the positive examples
Kleene star - the negative examples
2. The only way for a user to know if the regular expression provided by the output is meaningful is to already know the regular expression that describes the desired state machine...or to knowingly accept that the output regular expression is based on rules that are not derived directly from the input and ideally to understand what those rules are. That's fine for sophisticated users who understand the context, but not for people who don't understand automata.
3. The end user gains nothing by withholding training data because the regular expression is deterministic. Withholding training data is only useful for understanding the heuristics of the generator and tuning it. The regular expression itself is simply right or wrong.
4. While automatic generation of automata sounds like the sort of thing that solves real world problems, the automatic generation of regular expressions of the sort programmers rely on seems more likely to produce bugs of the sort that arise when a programmer writes code that they don't understand.
+ve: a | aaa | aaaaaaa | aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
-ve: b | 1000 | cd
No?
EDIT: Formatting.
2. to evaluate the solution quality on the training data is wrong. In order to mitigate the overfitting risk, the Regex Generator learns the regular expressions from half of the training examples and validates them on the other half of the examples. We also assessed our algorithm on 20 extraction tasks and evaluated the final solutions on unknown corpora (testing): the quality of final solutions is comparable to expert human solutions.
"Sophisticated" regex users don't need our tool: regex generator is intended for novice users or to demonstrate that we can automatically find solutions which are comparable with human ones.
Please note that defining an extraction task is always error prone, there may be errors in the task definition (understanding) or during the regex coding; smart and expert programmers make errors too, there may be corner cases they have not thought about. Sometimes, you need to get the job done--with a fair confidence--and improve it later. This is our view of the real world.
Most important thing: your criticisms are valid for all the problems of supervised machine learning. Do you really think taht driverless car, antispam filters, automatic transaltors and so on are useless only because they are trying to infer a model from partial data? I do not think so.
[a-d]
I start to think that we are talking about different topics ;-)
However, it could also have come up with the rule ([0-8]*).
So how does it know which one to choose? Can one also submit counter-examples?
The result is: \d
Since it's impossible to do accurately, it has to use some "common sense" via genetic programming or whatever. In your example, it probably sees that people rarely want [1-8]{1,3}, but that it's a subset of \d+ and goes with that instead.
Zipcodes would be something I'd like to see available as regexes.
(Edit: If you want the full ZIP+4 where it's given, you can add (\-\d{4})? as a term in the regex, and you can validate them the same way. USPS also offers an API for validating address information; it's been some years since I used it, and I recall it being somewhat recondite in the fashion of most .gov APIs, but it's there and it works.)
Edit again: OK, the site loaded. It looks like a tool for generating regexes via machine learning techniques to match highly complex targets. From a purely technical perspective, that sounds really neat -- but from a maintainability perspective, it sounds like even more of a nightmare than complex regexes usually are.
I like that!