in reply to Simple regex question. Grouping with a negative lookahead assertion.

One of your main problems here is deciding that you needed a look-ahead assertion: you don't. (See Look-Around Assertions in perlre - Extended Patterns for details.)

It's useful to show actual and expected output. Here's what I get: 

$ perl -Mstrict -Mwarnings -E '
    my $dna = q{atctcggataatgggataaaaatataggctataaatggcgccccggctaatttt
+t};

    if ($dna =~ /atg([acgt]+)(?!(taa|tag|tga))/xms) {
        say $1;
    }
'
ggataaaaatataggctataaatggcgccccggctaattttt

[download]

So, that skips everything until 'atg' is found; after that, as many as possible of [acgt] are captured as long as your rule (must not be followed by taa|tag|tga) is adhered to. The end of the $dna string is not "followed by taa|tag|tga" so the successful match ends there.

What you really want to do is stop capturing when taa|tag|tga is found. That would be: 

$ perl -Mstrict -Mwarnings -E '
    my $dna = q{atctcggataatgggataaaaatataggctataaatggcgccccggctaatttt
+t};

    if ($dna =~ /atg([acgt]+)(?:taa|tag|tga)/xms) {
        say $1;
    }
'
ggataaaaatataggctataaatggcgccccggc

[download]

So now, as many as possible of [acgt] are captured until taa|tag|tga is found.

Furthermore, it looks like you want "as few as possible of [acgt]" instead of "as many as possible of [acgt]": 

$ perl -Mstrict -Mwarnings -E '
    my $dna = q{atctcggataatgggataaaaatataggctataaatggcgccccggctaatttt
+t};

    if ($dna =~ /atg([acgt]+?)(?:taa|tag|tga)/xms) {
        say $1;
    }
'
gga

[download]

You can clean that up by replacing [acgt] with . (you only have those four letters in $dna and, indeed, in DNA) and removing the three modifiers xms which you make no use of. 

$ perl -Mstrict -Mwarnings -E '
    my $dna = q{atctcggataatgggataaaaatataggctataaatggcgccccggctaatttt
+t};

    if ($dna =~ /atg(.+?)(?:taa|tag|tga)/) {
        say $1;
    }
'
gga

[download]

I note that the modifiers xms are written in the same (alphabetically) unordered way as they appear throughout Perl Best Practices (PBP). So, either you've just copied those from somewhere else and don't know what they mean (see perlre - Modifiers) or you're required to follow PBP. If the latter, you should use warnings (see also -w in perlrun) and the regular expression would be better as: 

/atg (.+?) (?>taa|tag|tga)/msx

[download]

(?>pattern) is also explained in perlre - Extended Patterns.

Finally, in your real code, unless you're ensuring that $dna is always lowercase (e.g. by using lc), you should also add the i modifier (also described in perlre - Modifiers).

-- Ken

Replies are listed 'Best First'.
Re^2: Simple regex question. Grouping with a negative lookahead assertion.
by AnomalousMonk (Archbishop) on Jul 15, 2013 at 09:40 UTC

    In general, I agree with the points in your reply, but a coupla quibbles...

    ... the modifiers xms ... would be better as:
    /atg (.+?) (?>taa|tag|tga)/msx
    [emphasis added]

    Why better? The modifiers are given in alphabetic order in a  Regexp object stringization, but what is the advantage of keeping that order? I thought TheDamian used the  //xms ordering throughout PBP simply because it happened to be the order in which those modifiers were introduced and discussed in the regex section of the book, not because of any inherent advantage. Is their order not irrelevant to compilation/execution?

    Also, what is the advantage of using atomic grouping for the  (?>taa|tag|tga) stop codon (if that's the right terminology) sub-pattern? My understanding is that the primary (maybe the only?) purpose of atomic grouping is to defeat backtracking in situations in which the programmer knows backtracking will impair performance. In the example regex, once the stop codon pattern matches, the overall match succeeds; there is never any backtracking to defeat. (This is already discussed in part here, but I still don't see any advantage.)

    ... in your real code, unless you're ensuring that $dna is always lowercase (e.g. by using lc), you should also add the i modifier ...

    I would emphasize that it's usually very important to ensure lower- (or canonical-) casing for long string matches because the  //i modifier can impose a significant performance hit. In the benchmarks I did here, just adding  //i to my equivalent of the
        /atg(.+?)(?:taa|tag|tga)/
    regex incurred a 30% - 35% hit.

[reply]
[d/l]
[select]
      "... the modifiers xms ... would be better as:"

      Well, I've seen some things taken out of context in my time but I think this one takes the biscuit. I'm not annoyed; I actually got a bit of a chuckle. I was, however, somewhat surprised.

      Just so we're clear, let me highlight the seven words you pulled out of three sentences in order to get something to quibble about:

      "I note that the modifiers xms are written in the same (alphabetically) unordered way as they appear throughout Perl Best Practices (PBP). So, either you've just copied those from somewhere else and don't know what they mean (see perlre - Modifiers) or you're required to follow PBP. If the latter, you should use warnings (see also -w in perlrun) and the regular expression would be better as:

      My regex following "You can clean that up by ..." was: 

      /atg(.+?)(?:taa|tag|tga)/

      [download]

      That was my solution. I was happy with it. I'm still happy with it.

      I then went on to say that if the OP was "required to follow PBP" then certain other things should be done. These included using warnings and making some changes to my regex. I wasn't advocating blind adherence to PBP and I don't believe anything in my post suggested that.

      As far as the order of the modifiers goes: write them any way you want. PBP typically has xms (and, yes, that's the order in which they are presented in the book); I prefer to write them alphabetically (that's just me); to the best of my knowledge, the regex engine doesn't care what order you use.

      Regarding the (?>pattern) construct, I claimed no advantage to using this. It's just another PBP guideline: "... rewrite any instance of: X | Y as: (?> X | Y )" [truncated extract from page 271].

      Finally, you make a good point about "lower- (or canonical-) casing". I concur.

      -- Ken

[reply]
[d/l]
[select]

        I apologize for my confusion, but at least I was able to brighten your day with a chuckle!

[reply]

In Section Seekers of Perl Wisdom