[31961] in Perl-Users-Digest
Perl-Users Digest, Issue: 3225 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Dec 2 14:09:36 2010
Date: Thu, 2 Dec 2010 11:09:19 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 2 Dec 2010 Volume: 11 Number: 3225
Today's topics:
Re: FAQ 1.1 What is Perl? <user@compgroups.net/>
Optimisation for tight loops... <schaitan@gmail.com>
Re: Optimisation for tight loops... <uri@StemSystems.com>
Re: Optimisation for tight loops... <bugbear@trim_papermule.co.uk_trim>
Re: Optimisation for tight loops... <schaitan@gmail.com>
Re: Optimisation for tight loops... <sherm.pendley@gmail.com>
Re: Optimisation for tight loops... <tadmc@seesig.invalid>
Re: Optimisation for tight loops... (Jens Thoms Toerring)
Re: Optimisation for tight loops... <kst-u@mib.org>
Re: Optimisation for tight loops... <uri@StemSystems.com>
Re: Optimisation for tight loops... <uri@StemSystems.com>
Re: Optimisation for tight loops... <uri@StemSystems.com>
Re: Regex help sln@netherlands.com
Re: Regex help <derykus@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 02 Dec 2010 09:28:58 -0600
From: DunlapFRANCESCA35 <user@compgroups.net/>
Subject: Re: FAQ 1.1 What is Perl?
Message-Id: <ep-dnTN2ysGnJmrRnZ2dnUVZ_oKdnZ2d@giganews.com>
Some time ago, I did need to buy a building for my business but I didn't have enough money and could not purchase something. Thank heaven my friend adviced to take the <a href="http://bestfinance-blog.com/topics/personal-loans">personal loans</a> from creditors. Hence, I acted that and used to be satisfied with my student loan.
------------------------------
Date: Thu, 2 Dec 2010 00:28:51 -0800 (PST)
From: Krishna Chaitanya <schaitan@gmail.com>
Subject: Optimisation for tight loops...
Message-Id: <2eddc3f3-5a69-4557-8dab-f75c55d9a584@j32g2000prh.googlegroups.com>
Hi,
Does the Perl compiler/interpreter do any loop unrolling, or any loop
optimisations at all? Or do we have to code them by hand? I came
across opinions that Perl's "bad" for tight loops....I'd like to see
what the gurus say.
-Chaitanya
------------------------------
Date: Thu, 02 Dec 2010 03:35:55 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Optimisation for tight loops...
Message-Id: <8739qg4ln8.fsf@quad.sysarch.com>
>>>>> "KC" == Krishna Chaitanya <schaitan@gmail.com> writes:
KC> Does the Perl compiler/interpreter do any loop unrolling, or any
KC> loop optimisations at all? Or do we have to code them by hand? I
KC> came across opinions that Perl's "bad" for tight loops....I'd like
KC> to see what the gurus say.
no dynamic lang (and i assume it is the others are who are badmouthing
perl) can do loop unrolling and such. this is because things can change
at runtime with tied things, symrefs, and eval string. no compiler can
handle such things and optimize them out of a loop or unroll a loop.
now you can write fast and slower loops in perl. c style loops and
indexing into arrays are slow, perl foreach style loops are fast and
simple. knowing better perl is the way to write better loops, not
listening to anti-perl opinions. ask those naysayers about their 'perl
compatible regex' stuff and watch them stammer about that.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Thu, 02 Dec 2010 09:11:09 +0000
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: Optimisation for tight loops...
Message-Id: <ldadne8BkJcw_2rRnZ2dnUVZ8iOdnZ2d@brightview.co.uk>
Krishna Chaitanya wrote:
> Hi,
>
> Does the Perl compiler/interpreter do any loop unrolling, or any loop
> optimisations at all? Or do we have to code them by hand? I came
> across opinions that Perl's "bad" for tight loops....I'd like to see
> what the gurus say.
If by "tight loop" one means the sort of thing
you need for pixel-by-pixel image processing,
FFT or real time sound generation, yeah, perl is too slow.
Otherwise - not an issue.
BugBear
------------------------------
Date: Thu, 2 Dec 2010 05:02:11 -0800 (PST)
From: Krishna Chaitanya <schaitan@gmail.com>
Subject: Re: Optimisation for tight loops...
Message-Id: <80692118-bff7-4b36-835d-781d1fdec191@35g2000prb.googlegroups.com>
> now you can write fast and slower loops in perl. c style loops and
> indexing into arrays are slow, perl foreach style loops are fast and
> simple. knowing better perl is the way to write better loops, not
> listening to anti-perl opinions. ask those naysayers about their 'perl
> compatible regex' stuff and watch them stammer about that.
>
> uri
Thanks, Uri. This really helped.
On this note, I referred to perlperf and got this example going:
#!/usr/bin/perl
use warnings;
use strict;
use Benchmark qw(:hireswallclock timethese cmpthese);
my $code_C_Style = sub {
my @a = (1..100000);
my $searchfor = 99999;
for (my $i=0; $i <= $#a; $i++) {
last if $a[$i] == $searchfor;
}
};
my $code_Perl_grep = sub {
my @a = (1..100000);
my $searchfor = 99999;
return if grep /$searchfor/, @a;
};
my $code_Perl_foreach = sub {
my @a = (1..100000);
my $searchfor = 99999;
foreach (@a) {
last if /^$searchfor$/;
}
};
my $code_Perl_hashkeys = sub {
my @a = (1..100000);
my $searchfor = 99999;
my %ah;
@ah{@a} = ();
return if exists $ah{$searchfor};
};
my $results = timethese(100, {
C_Style => $code_C_Style,
Perl_grep => $code_Perl_grep,
Perl_foreach => $code_Perl_foreach,
Perl_hashkeys => $code_Perl_hashkeys
}
);
cmpthese($results);
The results were as follows:
Benchmark: timing 100 iterations of C_Style, Perl_foreach, Perl_grep,
Perl_hashkeys...
C_Style: 6.45279 wallclock secs ( 6.36 usr + 0.01 sys = 6.37 CPU)
@ 15.70/s (n=100)
Perl_foreach: 9.16967 wallclock secs ( 8.55 usr + 0.02 sys = 8.57
CPU) @ 11.67/s (n=100)
Perl_grep: 7.02614 wallclock secs ( 6.80 usr + 0.01 sys = 6.81 CPU)
@ 14.68/s (n=100)
Perl_hashkeys: 23.5906 wallclock secs (22.61 usr + 0.04 sys = 22.65
CPU) @ 4.42/s (n=100)
Rate Perl_hashkeys Perl_foreach Perl_grep
C_Style
Perl_hashkeys 4.42/s -- -62%
-70% -72%
Perl_foreach 11.7/s 164% --
-21% -26%
Perl_grep 14.7/s 233% 26%
-- -6%
C_Style 15.7/s 256% 35%
7% --
Looks like the results are against this:
" If you are searching for an element in a list, it can be more
efficient to store the data in a hash structure, and then simply look
to see whether the key is defined, rather than to loop through the
entire array using grep() for instance. " (from perlperf)
Or...did I interpret the results incorrectly, or worse, create the
wrong test case? Pardon me, this is the 1st time I'm venturing into
benchmarking.
Thanks a lot,
Chaitanya
------------------------------
Date: Thu, 02 Dec 2010 08:58:50 -0500
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: Optimisation for tight loops...
Message-Id: <m2lj48z36t.fsf@sherm.shermpendley.com>
Krishna Chaitanya <schaitan@gmail.com> writes:
> I came
> across opinions that Perl's "bad" for tight loops....I'd like to see
> what the gurus say.
Most "gurus" would say that you would be better served by profiling your
code to see where any real bottlenecks are, than by listening to random
uninformed guesswork.
sherm--
--
Sherm Pendley
<http://camelbones.sourceforge.net>
Cocoa Developer
------------------------------
Date: Thu, 02 Dec 2010 08:12:51 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Optimisation for tight loops...
Message-Id: <slrniffavv.46j.tadmc@tadbox.sbcglobal.net>
Krishna Chaitanya <schaitan@gmail.com> wrote:
> I referred to perlperf and got this example going:
>
>
> #!/usr/bin/perl
>
> use warnings;
> use strict;
> use Benchmark qw(:hireswallclock timethese cmpthese);
>
> my $code_C_Style = sub {
> my @a = (1..100000);
> my $searchfor = 99999;
Problem #1:
You are measuring *two* things: how long it takes to populate the
data structure and how long it takes to search in that structure.
We should be testing only the search time, so take the populating
out of the timed routines.
> for (my $i=0; $i <= $#a; $i++) {
> last if $a[$i] == $searchfor;
> }
> };
>
> my $code_Perl_grep = sub {
> my @a = (1..100000);
> my $searchfor = 99999;
> return if grep /$searchfor/, @a;
> };
Problem #2:
You are using different tests, numeric equality (fast) and
pattern matching (slow).
We should also consider the difference between using a numeric
test (fast) versus a string test (slow).
>
> The results were as follows:
[ snip, Perl_hashkeys was slowest ]
> Looks like the results are against this:
>
> " If you are searching for an element in a list, it can be more
> efficient to store the data in a hash structure, and then simply look
> to see whether the key is defined, rather than to loop through the
> entire array using grep() for instance. " (from perlperf)
>
> Or...did I interpret the results incorrectly, or worse, create the
> wrong test case? Pardon me, this is the 1st time I'm venturing into
> benchmarking.
You interpreted what was to be timed incorrectly, AND you created
the wrong test cases. :-)
Try the tweaked benchmark below, where the hash method is orders
of magnitude faster than any of the others.
--------------------------------------
#!/usr/bin/perl
use warnings;
use strict;
use Benchmark qw(:hireswallclock timethese cmpthese);
# populate the data structures to be searched
my @a = (1..100000);
my $searchfor = 99999;
my %ah;
@ah{@a} = (1);
my $code_C_Style = sub {
for (my $i=0; $i <= $#a; $i++) {
last if $a[$i] eq $searchfor;
}
};
my $code_C_Style2 = sub {
for (my $i=0; $i <= $#a; $i++) {
last if $a[$i] == $searchfor;
}
};
my $code_Perl_grep = sub {
return if grep $_ eq $searchfor, @a;
};
my $code_Perl_grep2 = sub {
return if grep $_ == $searchfor, @a;
};
my $code_Perl_foreach = sub {
foreach (@a) {
last if $_ eq $searchfor;
}
};
my $code_Perl_foreach2 = sub {
foreach (@a) {
last if $_ == $searchfor;
}
};
my $code_Perl_hashkeys = sub {
return if exists $ah{$searchfor};
};
my $code_Perl_hashkeys2 = sub {
return if $ah{$searchfor};
};
my $results = timethese(100, {
C_Style => $code_C_Style,
C_Style2 => $code_C_Style2,
Perl_grep => $code_Perl_grep,
Perl_grep2 => $code_Perl_grep2,
Perl_foreach => $code_Perl_foreach,
Perl_foreach2 => $code_Perl_foreach2,
Perl_hashkeys => $code_Perl_hashkeys,
Perl_hashkeys2 => $code_Perl_hashkeys2,
}
);
cmpthese($results);
--------------------------------------
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: 2 Dec 2010 14:29:00 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Re: Optimisation for tight loops...
Message-Id: <8lpopcFjgiU1@mid.uni-berlin.de>
Krishna Chaitanya <schaitan@gmail.com> wrote:
> > now you can write fast and slower loops in perl. c style loops and
> > indexing into arrays are slow, perl foreach style loops are fast and
> > simple. knowing better perl is the way to write better loops, not
> > listening to anti-perl opinions. ask those naysayers about their 'perl
> > compatible regex' stuff and watch them stammer about that.
> >
> > uri
Better leave in the attribution line your newsreader should
automatically create for you instead of just keeping the name
of the poster (or his/her signature) you're replying to..
> Thanks, Uri. This really helped.
> On this note, I referred to perlperf and got this example going:
> #!/usr/bin/perl
> use warnings;
> use strict;
> use Benchmark qw(:hireswallclock timethese cmpthese);
> my $code_C_Style = sub {
> my @a = (1..100000);
> my $searchfor = 99999;
> for (my $i=0; $i <= $#a; $i++) {
> last if $a[$i] == $searchfor;
> }
> };
> my $code_Perl_grep = sub {
> my @a = (1..100000);
> my $searchfor = 99999;
> return if grep /$searchfor/, @a;
> };
> my $code_Perl_foreach = sub {
> my @a = (1..100000);
> my $searchfor = 99999;
> foreach (@a) {
> last if /^$searchfor$/;
> }
> };
> my $code_Perl_hashkeys = sub {
> my @a = (1..100000);
> my $searchfor = 99999;
> my %ah;
> @ah{@a} = ();
> return if exists $ah{$searchfor};
> };
> my $results = timethese(100, {
> C_Style => $code_C_Style,
> Perl_grep => $code_Perl_grep,
> Perl_foreach => $code_Perl_foreach,
> Perl_hashkeys => $code_Perl_hashkeys
> }
> );
> cmpthese($results);
> The results were as follows:
> Benchmark: timing 100 iterations of C_Style, Perl_foreach, Perl_grep,
> Perl_hashkeys...
> C_Style: 6.45279 wallclock secs ( 6.36 usr + 0.01 sys = 6.37 CPU)
> @ 15.70/s (n=100)
> Perl_foreach: 9.16967 wallclock secs ( 8.55 usr + 0.02 sys = 8.57
> CPU) @ 11.67/s (n=100)
> Perl_grep: 7.02614 wallclock secs ( 6.80 usr + 0.01 sys = 6.81 CPU)
> @ 14.68/s (n=100)
> Perl_hashkeys: 23.5906 wallclock secs (22.61 usr + 0.04 sys = 22.65
> CPU) @ 4.42/s (n=100)
> Rate Perl_hashkeys Perl_foreach Perl_grep
> C_Style
> Perl_hashkeys 4.42/s -- -62%
> -70% -72%
> Perl_foreach 11.7/s 164% --
> -21% -26%
> Perl_grep 14.7/s 233% 26%
> -- -6%
> C_Style 15.7/s 256% 35%
> 7% --
> Looks like the results are against this:
> " If you are searching for an element in a list, it can be more
> efficient to store the data in a hash structure, and then simply look
> to see whether the key is defined, rather than to loop through the
> entire array using grep() for instance. " (from perlperf)
> Or...did I interpret the results incorrectly, or worse, create the
> wrong test case? Pardon me, this is the 1st time I'm venturing into
> benchmarking.
Well, to start with, you gave a huge disadvantage to the foreach
loop, at least in comparison to the C_style method. Compare your
loop
my $code_Perl_foreach = sub {
my @a = (1..100000);
my $searchfor = 99999;
foreach (@a) {
last if /^$searchfor$/;
}
};
with
my $code_Perl_foreach = sub {
my @a = (1..100000);
my $searchfor = 99999;
foreach (@a) {
last if $_ == $searchfor;
}
};
That's faster by a factor of more than 3 on my machine and makes it
the fastest of the bunch, it's even better than the C_style loop
by more than a factor of 2. The reason it's faster is reather obvious:
it just needs to do a numerical comparison (like you do in C_style)
instead of evaluating a regex. So how you compare makes a huge
difference.
But then I don't see what this comparison proves. If you have
to search for an element in an array only once then, of course,
the overhead of creating a hash out of it is forbidding. But
things change completely if you have to search for lots of ele-
ments. Then you incur the cost of setting up the hash once, but
afterwards the lookups into hash are blindingly fast, while
searching over the array with any of the other methods requires
looping over half the elements on average (assuming that the
elements you search for are distributed randomly over the
array).
For that use case creating the array and the hash once and
then do only the searching within the functions you benchmark
would result in a more reasonable comparison. And then the
hashkey method is the absolute winner with something in the
order of a few microseconds instead of seconds in all other
cases.
As you see you've got to pick the right method as well as the
right type of comparison for the problem at hand to be efficient.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
------------------------------
Date: Thu, 02 Dec 2010 08:44:21 -0800
From: Keith Thompson <kst-u@mib.org>
Subject: Re: Optimisation for tight loops...
Message-Id: <ln1v60p1ju.fsf@nuthaus.mib.org>
"Uri Guttman" <uri@StemSystems.com> writes:
>>>>>> "KC" == Krishna Chaitanya <schaitan@gmail.com> writes:
>
> KC> Does the Perl compiler/interpreter do any loop unrolling, or any
> KC> loop optimisations at all? Or do we have to code them by hand? I
> KC> came across opinions that Perl's "bad" for tight loops....I'd like
> KC> to see what the gurus say.
>
> no dynamic lang (and i assume it is the others are who are badmouthing
> perl) can do loop unrolling and such. this is because things can change
> at runtime with tied things, symrefs, and eval string. no compiler can
> handle such things and optimize them out of a loop or unroll a loop.
Why not? Perl is compiled before it's executed, after all, and
the compiler *could* determine that the body of a loop doesn't do
anything disruptive and use that information to perform optimizations
(loop unrolling, common subexpression elimination, etc.).
It's not at all clear that it makes sense to do so, given that
you're going to pay the overhead each time the program is executed.
And I have no idea what optimizations the perl implementation
actually performs. But I suggest that your "no dynamic lang"
claim is overstated.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Thu, 02 Dec 2010 13:35:11 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Optimisation for tight loops...
Message-Id: <87aako2fc0.fsf@quad.sysarch.com>
>>>>> "KC" == Krishna Chaitanya <schaitan@gmail.com> writes:
KC> Looks like the results are against this:
KC> " If you are searching for an element in a list, it can be more
KC> efficient to store the data in a hash structure, and then simply look
KC> to see whether the key is defined, rather than to loop through the
KC> entire array using grep() for instance. " (from perlperf)
anyone here could have told you that. and it is only true if you need to
do this search multiple times. and that has nothing to do with the speed
of perl loops. it is all about using the best data structure for a task.
KC> Or...did I interpret the results incorrectly, or worse, create the
KC> wrong test case? Pardon me, this is the 1st time I'm venturing into
KC> benchmarking.
you don't need to do benchmarking for such an obvious choice.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Thu, 02 Dec 2010 13:38:25 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Optimisation for tight loops...
Message-Id: <8762vc2f6m.fsf@quad.sysarch.com>
>>>>> "TM" == Tad McClellan <tadmc@seesig.invalid> writes:
TM> my @a = (1..100000);
TM> my $searchfor = 99999;
TM> my %ah;
TM> @ah{@a} = (1);
that will only set one element to 1. assign () to make them all undef
and use exists or assign a full list with (1) x @a.
TM> my $code_Perl_hashkeys = sub {
TM> return if exists $ah{$searchfor};
TM> };
you do use exists (as i suspected you would). so () would have been
fine.
what about trying first() from List::Utils?
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Thu, 02 Dec 2010 13:43:50 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Optimisation for tight loops...
Message-Id: <871v602exl.fsf@quad.sysarch.com>
>>>>> "KT" == Keith Thompson <kst-u@mib.org> writes:
>> no dynamic lang (and i assume it is the others are who are badmouthing
>> perl) can do loop unrolling and such. this is because things can change
>> at runtime with tied things, symrefs, and eval string. no compiler can
>> handle such things and optimize them out of a loop or unroll a loop.
KT> Why not? Perl is compiled before it's executed, after all, and
KT> the compiler *could* determine that the body of a loop doesn't do
KT> anything disruptive and use that information to perform optimizations
KT> (loop unrolling, common subexpression elimination, etc.).
KT> It's not at all clear that it makes sense to do so, given that
KT> you're going to pay the overhead each time the program is executed.
KT> And I have no idea what optimizations the perl implementation
KT> actually performs. But I suggest that your "no dynamic lang"
KT> claim is overstated.
then why haven't you ever seen any dynamic lang do any of the classic
loop optimizations you see in classic compiled langs like fortran? you
can't. loop unrolling and constant subexpression expression moving can't
be done if the values can change underneath as they can in a language
like perl. a sub call which can be chosen at runtime in the loop can
change the WHOLE loop by calling eval. and that can't be detected. any
variable in the loop could be tied which is a runtime thing and that
could call anything which could change the loop. no compiler can see or
predict those sorts of things. perl does constant folding, conversions
of constant style subs (as what the constant pragma does) to real
constants and not much else. those things can't have variables or
anything other than pure constants at compile time.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Thu, 02 Dec 2010 09:49:20 -0800
From: sln@netherlands.com
Subject: Re: Regex help
Message-Id: <qnlff6p4sif9s7l6v5q1avoovcnfvimlvp@4ax.com>
On Thu, 2 Dec 2010 00:14:55 +0100, "lennie" <erling.kopperdal@lyse.net> wrote:
>Many good solutions, TIMTOWTDI :)
>
>This is my suggestion:
>
>while(<SYSCMD>)
>{
> if (/^(\d+)\s+(\d+)\s+(\d+)\s+(\d+)/){
> push(@X_Cord, $1);
> push(@Y_Cord, $2);
> push(@depth, $3);
> push(@refresh, $4);
> }
>}
>close(SYSCMD);
>
>IMHO: Gives a good balance between what my poor head can read and input
>control :)
>
>Cheers
>
The regex you use is interresting.
/^(\d+)\s+(\d+)\s+(\d+)\s+(\d+)/
The separator in the OP's sample data is a single tab \t
but you use \s+.
All indications from your regex show validation
requirements with the + quantifier. As well, there is
an assertion of beginning of string ^ followed by digits,
however, you don't have the end of string assertion with
preceding digits.
This cannot validate input on an apparent fixed output, and
with his data, that would appear to be this:
/^(\d+)\t(\d+)\t(\d+)\t(\d+)$/
otherwise, its just as valid to say this
/\s*(\d+)\s*(\d+)\s*(\d+)\s*(\d+)\s*/
because the assumption is slop data both ways and your
beginning of string assertion ^ is useless when used
without $ in a line of data that should be completely
consumed as 4 groups of digits only.
If the alternate assumption is that there could be partial
data of limited form with only slight validation, then this
might be a better trap:
/^\s*(\d+)\s*(\d*)\s*(\d*)\s*(\d*)/
-sln
------------------------------
Date: Wed, 1 Dec 2010 23:44:21 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Regex help
Message-Id: <728589d2-79c0-4e06-be66-5c97eb7c5745@22g2000prx.googlegroups.com>
On Dec 1, 3:14=A0pm, "lennie" <erling.kopper...@lyse.net> wrote:
> "king" <hara.acha...@gmail.com> skrev i meldingnews:2e958e6c-5983-4161-a7=
be-eb4e87939a4c@c17g2000prm.googlegroups.com...
>
>
>
> >I have the below text:
> > Want to store it in array using regular expression.
>
> > The script is as below.
> > "
> > open(SYSCMD, "dccmd -listmodes |");
>
> > while(<SYSCMD>)
> > {
> > if(/^(\d+)[\s+](\d+)/)
> > {
> > chomp;
> > push(@X_Cord, $1);
> > }
> > if(/[\s+](\d+)[\s+](.*)$/)
>
> > {
> > chomp;
> > push(@Y_Cord, $1);
> > }
> > if(/(\d+)(\s+)(\d+)$/)
>
> > {
> > chomp;
> > push(@depth, $1);
>
> > }
> > if(/(\s+)(\d+)$/)
> > {
> > chomp;
> > push(@refresh, $1);
>
> > }
>
> > }
> > close(SYSCMD);
>
> > foreach(@X_Cord)
> > {
> > print "$_\n";
> > }
> > foreach(@Y_Cord)
> > {
> > print "$_\n";
> > }
> > foreach(@depth)
> > {
> > print "$_\n";
> > }
> > foreach(@refresh)
> > {
> > print "$_\n";
> > }
> > "
>
> > The output of dccmd command is
> > "Resolution Changer 3.12 from 12noon (12noon.com)
>
> > Width Height Depth Rate
>
> > 320 200 8 60
>
> > 320 200 16 60
>
> > 320 200 32 60
>
> > 512 384 8 60
>
> > 512 384 16 60
>
> > 512 384 32 60
>
> > 640 400 8 60
>
> > 640 400 16 60
>
> > 640 400 32 60
>
> > 640 480 8 60
>
> > 640 480 16 60
>
> > 640 480 32 60
>
> > 800 600 8 60
>
> > 800 600 16 60
>
> > 800 600 32 60
>
> > 1024 768 8 60
>
> > 1024 768 16 60
>
> > 1024 768 32 60
>
> > 1280 800 8 60
>
> > 1280 800 16 60
>
> > 1280 800 32 60
>
> > "
> > From the script I am getting only X_cord and Y_cord. But I am not
> > getting the depth and refresh.
> > Can anybody help me with the refresh rate.
>
> Many good solutions, TIMTOWTDI :)
>
> This is my suggestion:
>
> while(<SYSCMD>)
> {
> =A0 if (/^(\d+)\s+(\d+)\s+(\d+)\s+(\d+)/){
> =A0 =A0 push(@X_Cord, $1);
> =A0 =A0 push(@Y_Cord, $2);
> =A0 =A0 push(@depth, $3);
> =A0 =A0 push(@refresh, $4);
> =A0 }}
>
[ ... ]
you could even use /x and named capture buffers for
even more readability IMO:
if ( /^( ?<xcord> \d+ ) \s+ ( ?<ycord> \d+ ) \s+
( ?<depth> \d+) \s+ ( ?<refresh> \d+) /x )
{
push @X_Cord, $+{xcord};
push @Y_Cord, $+{ycord};
push @depth, $+{depth};
push @refresh,$+{refresh};
}
--
Charles DeRykus
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3225
***************************************
