21–30 of 117 posts
Earlier quoted context omitted.
What do you mean? Could you please clarify that? What did your understand by "in front"?
Presumably, they thought of A as in front of B in the expression "AB" rather than in the expression "BA". (Which is also how I would normally think of "in front", for what it's worth!)
Invented in 1998 by Perl hacker Abigail: http://neilk.net/blog/2000/06/01/abigails-regex-to-test-for-... (check out Abigail's other JAPHs if you like stuff like this)
It should be noted that this is not possible with regular expressions in the traditional sense (i.e. regular expressions only matching regular languages): http://math.stackexchange.com/a/181233/21405 Because of back references PCRE regular expressions can match non-regular languages as well.
One of my pet peeves is how PRCE destroyed the definition of "regular" in regular expressions. It has basically made a huge number of programmers illiterate as to what truly is regular in the formal sense.
It's basically the Sieve of Eratosthenes[1] algorithm, and it's possible to do it with regular expressions because numbers here are represented in unary[2] number system, where number of characters/tokens equals the number itself. It's a common trick for testing various Turing-machine stuff. [1] https://en.wikipedia.org/wiki/Sieve_of_Eratosthenes [2] https://en.wikipedia.org/wiki/Unary_numeral_system
Earlier quoted context omitted.
One of my pet peeves is how PRCE destroyed the definition of "regular" in regular expressions. It has basically made a huge number of programmers illiterate as to what truly is regular in the formal sense.
But why should people care about what is regular in the formal sense ? Rather, regular in this context would mean it can be recognized with a restricted type of algorithm, which resembles the formalism.
Earlier quoted context omitted.
But why should people care about what is regular in the formal sense ? Rather, regular in this context would mean it can be recognized with a restricted type of algorithm, which resembles the formalism.
Is there a standard for which additional features one can add on top of regular expressions in the original limited sense and still be considered a regex?
Earlier quoted context omitted.
Is there a standard for which additional features one can add on top of regular expressions in the original limited sense and still be considered a regex?
I always understood it as being whatever can be straightforwardly tacked onto a typical DFA implementation. I though that's how people came up with it—whichever extras were the easiest to implement without mucking anything else up, so in a way they "came for free". (It's possible I misunderstood, I don't know for sure.)
Earlier quoted context omitted.
I always understood it as being whatever can be straightforwardly tacked onto a typical DFA implementation. I though that's how people came up with it—whichever extras were the easiest to implement without mucking anything else up, so in a way they "came for free". (It's possible I misunderstood, I don't know for sure.)
Well, sure, but "whatever can be straightforwardly tacked on" is highly subjective, no?
tl;dr if you know a little regex - convert your number to a string of that length (1 = 1, 2 = 11, 3 = 111) - handle 0 / 1 separately - ^(..+?)\1+$ - trick; the WHOLE thing has to match to return (^$) - first \1 match is "11", ergo string must be "11", "1111", "111111" to match - second \1 match "111", ergo string must be "111", "111111", "111111111" to match - and so on. if you find before length of string, it was no…
In other words, it's the Sieve of Eratosthenes implemented via regex: https://en.wikipedia.org/wiki/Sieve_of_Eratosthenes