in reply to Re^5: regex in REPLACEMENT in s///
in thread regex in REPLACEMENT in s///

Nice try, but that was not my use case. I only multiplied the int part to prove I could do it from the CODE part of s///. Now let's say that IS my use case, that I want to multiply AND commify WITHOUT grouping, and the real number MUST be in a string, as in hippo's test paradigm, to wit:

   $orig = 'This is a real number, 123456.56567';
   $want = 'This is a real number, 493,826.26268';

I can do it with mine but not yours, as in:

$want = 'This is a real number, 493,826.26268';
($have = (($orig) =~ s{ \d+\.?\d* }{ $& * 4 }erx )) =~ s{ \d+ }{
    $& =~ s/ (?<=\d) (?= (?:\d{3} )+ (?!\d) ) /,/xrg; }ex;
$intpart = $&;
is $intpart, 493826, '$& int part captured';
is $have, $want, 'Insert commas where appropriate';

[download]

And as the Monks prefer, no grouping () to be seen. That is three s/// in a one-liner. First, grab the real number and factor it; next, grab just the int part and commify it; finally, put it back in the string. Man, s/PATTERN/CODE/e is potent mojo.

Replies are listed 'Best First'.
Re^7: regex in REPLACEMENT in s///
by hippo (Archbishop) on Sep 15, 2023 at 09:08 UTC
    And as the Monks prefer, no grouping () to be seen.

    Just to nail this point, I doubt anyone has good grounds to object to relevant use of grouping. The problem is that by default using brackets creates a capture group and this results in 2 levels of potential inefficiency (the group and the capture). And that's not to say that capture groups are bad - far from it. There is just no point in paying the performance penalty if you don't need the capturing.

    The inefficiencies being discussed here are obviously small but if you are using such a regex in the middle of tight loop which runs millions/billions of times then these things mount up so it is as well to be aware of them. I wouldn't go tying myself in knots to avoid them in cases where they don't matter.

    In general:

    • If you have a need for capture groups, use them but be aware of the potential performance penalty
    • If you have a need for groups but not capture, use them but ensure they are non-capturing using the methods already outlined by haukex
    • If you don't have a need for groups, don't use them

    We've all seen code where people have sprinkled unnecessary characters. In most cases it has no effect (good or bad) and just makes the code harder to read and maintain. With brackets in regex there is an effect and the price is worth paying if your code makes use of the functionality. But if you don't need it then it is best avoided.

    🦛

[reply]

      To hippo and tybalt89:

      Thank you both for participating in this stimulating dialogue. There are always new things to learn about Perl regexes, and as ikegami said, this is an exercise in nested s///, which I very much want to master. Here are nine more tests I added to hippo's test paradigm, to wit:

      sub getArray {
    my $n = $_[0];
    my @examples = (
        "The population of the U.S. is ${\($n*340389145)} people",
        "The frequency is ${\($n*13824)}Hz",
        "This is a real number, ${\($n*723540.34034)}",
        "${\($n*1045.357)}",
        "${\($n*834569.334656)}",
        "${\($n*1000000)} B.C.",
        "My daily compensation is \$${\($n*2234.36)} per hour.",
        "${\($n*2349134)}",
        "${\($n*123456)}",
    );
    return @examples;
}

my $n = 4;
my @have = getArray(1);
my @want = getArray($n);

for my $i (0 .. $#have) {
    my $have = $have[$i];
#   say "$have";
    my $want = $want[$i];
#   say "$want";
    (my $work1 = (($have) =~ s{ \d+\.?\d* }{ $& * $n }erx )) =~ s{ \d+
+ }{
       $& =~ s/ (?<=\d) (?= (?:\d{3} )+ (?!\d) ) /,/xrg; }ex;

    (my $work2 = $want) =~ s{ (?<int> (\d+)) }{
        $+{int} =~ s/ (?<=\d) (?= (?:\d{3} )+ (?!\d) ) /,/xrg; }ex;

    is $work1, $work2, 'Factor and insert commas where appropriate';
}

      [download]

      As I said, I could not make tybalt89's commify variation work, but perhaps he can. As you can see from getArray(), I made the tests more robust. I agree with hippo re performance. If I were going to include a construction as complicated as this that gets called many times, I'd Benchmark it to do comparative analysis.

      Regards

[reply]
[d/l]

In Section Seekers of Perl Wisdom