Re: A better way.
Dan Klose wrote:
Hello Everyone.
I have the following code:
### CODE BLOCK ###
my %hash_of_arrays2;
Have you considered a hash of hashes? For me, given the sample below, I
would prefer it, but obviously I haven't seen your whole script.
for (keys %hash_of_arrays) {
my @array_of_data = exists($hash_of_arrays{$_})
[EMAIL PROTECTED]
:();
I don't think the above is doing what you anticipate. 'exists' just
tests whether there is a key/value pair given the key. But since you are
iterating over the keys of the hash the test must always be true. If
there is no value, then your initialization will be the same as ()
anyways. So basically you can drop the above completely, or a better
check would be to test the number of elements (make sure you have an
array ref first if you are worried about it).
perldoc -f exists
my $mean = mean([EMAIL PROTECTED]); #GET MEAN
my $std_dev = dev([EMAIL PROTECTED]); #GET STANDARD DEV
Given that the above two functions take an array reference there is no
reason to dereference the array reference first, just to pass a
reference. You are using twice the memory to do so when the references
should allow you to save on memory that Perl would automatically duplicate.
push @{$hash_of_arrays2{$_}}, $mean;
push @{$hash_of_arrays2{$_}}, $std_dev;
This gets back to my question of the hash of hashes. Rather than
stuffing the mean and std_dev into indexes 0 and 1, why not just put
them in named indexes.
$hash_of_hashes-{$_}-{'mean'} = $mean;
$hash_of_hashes-{$_}-{'std_dev'} = $std_dev;
}
for (sort {$hash_of_arrays2{$a}[0] = $hash_of_arrays2{$b}[0]}
keys %hash_of_arrays2) {
print $_, $hash_of_arrays2{$_}[0], $hash_of_arrays2{$_}[1]\n;
}
### END OF CODE ###
If anyone has the time could you please show me ways of shortening this
code e.g. eliminating the second for block (integration into the
previous block) and any other tips / tricks.
The problem is that to do a sort you have to know all of the values that
you are sorting on before you can start, which means you can't print the
output in a sorted manner in the first loop, so there really is no way
to combine the two. The best you could hope for would be to populate an
array in sorted order in the first loop and then just print the result
in the second, but your sorting routine would very likely be less
efficient than Perl's built-in one.
There are no other people here that code perl and so I get no
advice/feedback on how to improve my scripts.
You have come to the right place then. I know that feeling, it stinks.
Thanks in advance.
Dan.
http://danconia.org
-- UNTESTED --
my %hash_of_calculations;
for my $key (keys %hash_of_arrays) {
if (ref $hash_of_arrays-{$key} eq 'ARRAY' and
@{$hash_of_arrays-{$key}}) {
# data to process
@{$hash_of_calculations-{$key}}{'mean','std_dev'} =
(mean($hash_of_arrays-{$key}), dev($hash_of_arrays-{$key}));
}
else {
# no data to process
@{$hash_of_calculations-{$key}}{'mean','std_dev'} = ();
}
}
for my $key (sort { $hash_of_calculations-{$a}-{'mean'} =
$hash_of_calculations-{$b}-{'mean'} } keys %hash_of_calculations) {
print Key: $key\n;
print Mean: $hash_of_calculations-{$key}-{'mean'}\n;
print Std Dev: $hash_of_calculations-{$key}-{'std_dev'}\n;
}
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response
Re: A better way.
On Aug 2, Dan Klose said:
my %hash_of_arrays2;
for (keys %hash_of_arrays) {
my @array_of_data = exists($hash_of_arrays{$_})
[EMAIL PROTECTED]
:();
Given that you're iterating over the list of keys in %hash_of_arrays,
there's NO reason to be using exists() here.
my @array_of_data = @{ $hash_of_arrays{$_} };
my $mean = mean([EMAIL PROTECTED]); #GET MEAN
my $std_dev = dev([EMAIL PROTECTED]); #GET STANDARD DEV
There's no reason to make a COPY of the array and then dereference. I'd
suggest doing:
my $data = $hash_of_arrays{$_};
my $mean = mean($data);
my $std_dev = dev($data);
push @{$hash_of_arrays2{$_}}, $mean;
push @{$hash_of_arrays2{$_}}, $std_dev;
You can do both at once:
$hash_of_arrays2{$_} = [ $mean, $std_dev ];
}
You can make that for loop into one statement:
my %hash_of_arrays2 = map {
$_ = [ mean($hash_of_arrays{$_}), dev($hash_of_arrays{$_}) ]
} keys %hash_of_arrays;
for (sort {$hash_of_arrays2{$a}[0] = $hash_of_arrays2{$b}[0]}
keys %hash_of_arrays2) {
print $_, $hash_of_arrays2{$_}[0], $hash_of_arrays2{$_}[1]\n;
}
There's no way to eliminate the second loop, because you need to have all
the data calculated before you can sort them.
--
Jeff japhy Pinyan % How can we ever be the sold short or
RPI Acacia Brother #734 % the cheated, we who for every service
http://japhy.perlmonk.org/ % have long ago been overpaid?
http://www.perlmonks.org/ %-- Meister Eckhart
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response
Re: A better way.
Hi,
I have gone for the following code:
my %avs_dev = map{
$_ = [mean($hoa{$_}), dev($hoa{$_})]
} keys %hoa;
for (sort {$avs_dev{$a}[0] = $avs_dev{$b}[0]} keys %avs_dev) {
print $_, $avs_dev{$_}[0], $avs_dev{$_}[1]\n;
}
I have never used MAP before... it looks handy!
Works a treat.
Thanks to Jeff 'japhy' Pinyan Wiggins d'Anconia
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response
Re: A better way
Brian Ling wrote:
Hi List,
I have the following bit of code, that works but doesn't feel like the
best way, can anyone think of a better neater answer maybe a one liner?
my $target = getTarget();
If ( target eq MAIN ) { return }
#do lots of other stuff with value of target
well this works:
return if 'MAIN' eq (my $target = getTarget());
/Stefan
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way
Stefan,
Personally, I'd prefer:
if (target ne MAIN)
{
#do lots of other stuff
}
I think general programming practice discourages multiple return points
in subroutines.
RobR
__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: A better way
Thanks for that, I had not released you could effectively use the getTarget() return value twice :-) well this works: return if 'MAIN' eq (my $target = getTarget()); /Stefan BBCi at http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system, do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way
Rob Richardson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Stefan,
Personally, I'd prefer:
if (target ne MAIN)
{
#do lots of other stuff
}
I think general programming practice discourages multiple return points
in subroutines.
Yes, and it's no more dangerous than multiple 'last' statements in loops.
Rob
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way
Brian Ling wrote: Thanks for that, I had not released you could effectively use the getTarget() return value twice :-) well this works: return if 'MAIN' eq (my $target = getTarget()); /Stefan Personally, I prefer: ( my $target = getTarget() ) eq 'MAIN' and return; as I believe that the declaration should always be at the beginning of the line. If that's not possible with the construct you need then there's nothing lost by doing my $target; return if 'MAIN' eq ( $target = getTarget() ); Cheers, Rob -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way
Rob Dixon said:
Rob Richardson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Stefan,
Personally, I'd prefer:
if (target ne MAIN)
{
#do lots of other stuff
}
I think general programming practice discourages multiple return points
in subroutines.
Yes, and it's no more dangerous than multiple 'last' statements in loops.
To my mind,
return if $target eq MAIN;
at the top of a sub is a lot more helpful than making me search all the
way down to the botttom to see if there is anything after the conditional.
And it's probably a lot less likely that the next person to edit that sub
will goof up by adding something where it shouldn't be.
Slavish devotion to the single exit point paradigm can produce some
wonderfully messy code, all scrunched up at the right of the screen.
Then again, I probably wouldn't merge those two original lines either.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way
Paul Johnson wrote:
Rob Dixon said:
Rob Richardson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Stefan,
Personally, I'd prefer:
if (target ne MAIN)
{
#do lots of other stuff
}
I think general programming practice discourages multiple return points
in subroutines.
Yes, and it's no more dangerous than multiple 'last' statements in loops.
To my mind,
return if $target eq MAIN;
at the top of a sub is a lot more helpful than making me search all the
way down to the botttom to see if there is anything after the conditional.
And it's probably a lot less likely that the next person to edit that sub
will goof up by adding something where it shouldn't be.
Slavish devotion to the single exit point paradigm can produce some
wonderfully messy code, all scrunched up at the right of the screen.
It's one of the more useless dogma to have come out of the industry.
As you say it's easy to create unreadable code through being tied to
only a single 'return', and I'd say it's just about as easy to write nonsense
by scattering returns through a subroutine with impunity. Any rule
to get around the problem has to be much less simplistic.
It's the same problem as the anti 'goto' camp. I would say that gotos
are fine, but labels are a real problem because you can use them
to jump into and out of scopes and pop stack frames as you wish.
'next', 'last', 'redo', 'return', 'exit' and subroutine calls are all gotos,
except that they're not allowed labels in the general sense that
'goto' is. The point they refer to is a well defined and sensible
place to pass control to within normal programming practice.
Then again, I probably wouldn't merge those two original lines either.
That's another one for another day :)
Cheers,
Rob
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way
Rob Richardson wrote:
Stefan,
Personally, I'd prefer:
if (target ne MAIN)
{
#do lots of other stuff
}
I think general programming practice discourages multiple return points
in subroutines.
RobR
I disagree. While one should certainly exercise care when making an early return, and
clean up any external links that may have been created, such constructs can make for
very clear and efficient code. Usually, I do it first thing after taking arguments.
It just makes sense, before you jump into a process, to see if you really need to do
the process at all. Among other things, early returns act as very elegant handlers
for the stopping cases in recursive functions.
Joseph
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way
Paul Johnson wrote: To my mind, return if $target eq MAIN; at the top of a sub is a lot more helpful than making me search all the way down to the botttom to see if there is anything after the conditional. And it's probably a lot less likely that the next person to edit that sub will goof up by adding something where it shouldn't be. Slavish devotion to the single exit point paradigm can produce some wonderfully messy code, all scrunched up at the right of the screen. Then again, I probably wouldn't merge those two original lines either. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net Ditto--on both points. The original formulation was just fine. Unless the $target variable was meant simply to decide on a return, it makes more sense to assign its value--one task, one line, and check it for validity--another task entirely, on a line of its own. The only thing it lacked was a meaningful return value. Since the getTarget function provided enough information to decide in favor of an early exit, this information should probably be passed on more explicitly, perhaps just by returning 0 rather than undef. Joseph -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way
R. Joseph Newton said: The only thing it lacked was a meaningful return value. Since the getTarget function provided enough information to decide in favor of an early exit, this information should probably be passed on more explicitly, perhaps just by returning 0 rather than undef. Just to pick nits, I think that a plain return here is absolutely correct. Or, at least it is in the general case, given that we know nothing about the return values of this particular function. The reason? If you return 0 or an explicit undef, and then call the function in list context, you will have returned a true value, a list with one element. If you just return, then in list context the return value will be an empty list, which is a false value. Calling a function in list context can occur more often that you might imagine, and so I recommend this as a good habit to get into. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way
Paul Johnson wrote: R. Joseph Newton said: The only thing it lacked was a meaningful return value. Since the getTarget function provided enough information to decide in favor of an early exit, this information should probably be passed on more explicitly, perhaps just by returning 0 rather than undef. Just to pick nits, I think that a plain return here is absolutely correct. Or, at least it is in the general case, given that we know nothing about the return values of this particular function. The reason? If you return 0 or an explicit undef, and then call the function in list context, you will have returned a true value, a list with one element. If you just return, then in list context the return value will be an empty list, which is a false value. Calling a function in list context can occur more often that you might imagine, and so I recommend this as a good habit to get into. -- Paul Johnson - [EMAIL PROTECTED] Good point, Paul. I forget that Perl has that feature. I mean, I use it to load variables from existing functions, but I seriously doubt that I would ever return anything other than scalar from a function. I value the funnel model for functions. I tend to use reference parameters for any function whose specification would not be satisfied with a discrete scalar. Joseph -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way
R. Joseph Newton wrote:
Paul Johnson wrote:
To my mind,
return if $target eq MAIN;
at the top of a sub is a lot more helpful than making me search all the
way down to the botttom to see if there is anything after the conditional.
And it's probably a lot less likely that the next person to edit that sub
will goof up by adding something where it shouldn't be.
Slavish devotion to the single exit point paradigm can produce some
wonderfully messy code, all scrunched up at the right of the screen.
Then again, I probably wouldn't merge those two original lines either.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Ditto--on both points. The original formulation was just fine.
Brian Ling wrote:
my $target = getTarget();
If ( $target eq MAIN ) { return }
#do lots of other stuff with value of target
I wouldn't disagree, except that it's the perfect place to use
return If $target eq MAIN
or
$target eq MAIN and return
to cut down on the furniture.
Unless the $target variable was meant simply to decide on a return, it makes more
sense to assign its value--one task, one line, and check it for validity--another
task
entirely, on a line of its own.
So presumably you're against
while ( my $line = FH ) {
:
}
on the same grounds? :)
The only thing it lacked was a meaningful return value. Since the getTarget function
provided enough information to decide in favor of an early exit, this information
should probably be passed on more explicitly, perhaps just by returning 0 rather
than undef.
I might buy
... this information could /possibly/ be passed on ...
A simple
return;
is /explicitly/ not returning a value, which is fine. The fact that you get 'undef' if
you
use the subroutine call as a value is irrelevant.
I don't believe a subroutine should always return a value just because it /can/. That
value is only useful if the calling code needs to behave differently depending on
the action of the subroutine. More often than not there's simply no point in passing
any value back to the calling code at all. Coding a return value that isn't used just
makes you look for subtleties that aren't there, and can lead (with the 'single exit
point' strategy) to the nightmare of dozens of subroutines which uselessly have a
'return 1' as their final statement. I do wish though that there was a better
distinction
between returning control and returning a value. In Perl it's made slightly worse
because
you can have both a 'return' without a value and a value without a 'return' (on the
last
line of the subroutine).
Cheers,
Rob
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way
Rob Dixon wrote:
Unless the $target variable was meant simply to decide on a return, it makes more
sense to assign its value--one task, one line, and check it for validity--another
task
entirely, on a line of its own.
So presumably you're against
while ( my $line = FH ) {
:
}
on the same grounds? :)
Only in cases where one is having trouble sorting out whether problems are arising
from the assignment, or some aspect of the validation statement. It doesn't do any
harm to take the extra line.
The only thing it lacked was a meaningful return value. Since the getTarget
function
provided enough information to decide in favor of an early exit, this information
should probably be passed on more explicitly, perhaps just by returning 0 rather
than undef.
I might buy
... this information could /possibly/ be passed on ...
A simple
return;
is /explicitly/ not returning a value, which is fine. The fact that you get 'undef'
if you
use the subroutine call as a value is irrelevant.
I don't believe a subroutine should always return a value just because it /can/. That
value is only useful if the calling code needs to behave differently depending on
the action of the subroutine. More often than not there's simply no point in passing
any value back to the calling code at all. Coding a return value that isn't used just
makes you look for subtleties that aren't there, and can lead (with the 'single exit
point' strategy) to the nightmare of dozens of subroutines which uselessly have a
'return 1' as their final statement. I do wish though that there was a better
distinction
between returning control and returning a value. In Perl it's made slightly worse
because
you can have both a 'return' without a value and a value without a 'return' (on the
last
line of the subroutine).
Cheers,
Rob
Agreed. The overall sense of the question, though, indicated to me that there is a
lot going on in this function, and that it wouldn't hurt to provide any calling
function with some indication of what went on inside. If the caller has no use for
the return falags, then it can call in a void context. But this sense arises more
from the apparent nature of the function than as a blanket rule.
Joseph
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way, a perl way?
On Jan 22, david said:
@data_ = map { (my $copy = $_) =~ s/^ //; $copy } @data;
s/^ // for(@data_ = @data);
Sigh. I usually do that. I was a little slow on the idiom-uptake.
--
Jeff japhy Pinyan [EMAIL PROTECTED] http://www.pobox.com/~japhy/
RPI Acacia brother #734 http://www.perlmonks.org/ http://www.cpan.org/
stu what does y/// stand for? tenderpuss why, yansliterate of course.
[ I'm looking for programming work. If you like my work, let me know. ]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way, a perl way?
On Jan 22, Jerry Preston said:
I am looking for a better way, a perl way for the following:
foreach ( @data ) ) {
s/^ //;
$data_[ $jp++ ] = $_;
}
You do realize that you're modifying the elements in @data as well, right?
So that, unless $jp starts at some value other than 0, @data_ and @data
are exactly the same.
If you DON'T want that, you'd have to do:
for (@data) {
(my $copy = $_) =~ s/^ //;
push @data_, $copy;
}
Or something to that effect. Here's a one-liner:
@data_ = map { (my $copy = $_) =~ s/^ //; $copy } @data;
--
Jeff japhy Pinyan [EMAIL PROTECTED] http://www.pobox.com/~japhy/
RPI Acacia brother #734 http://www.perlmonks.org/ http://www.cpan.org/
stu what does y/// stand for? tenderpuss why, yansliterate of course.
[ I'm looking for programming work. If you like my work, let me know. ]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way, a perl way?
.--[ Jerry Preston wrote (2003/01/22 at 11:59:14) ]--
|
| I am looking for a better way, a perl way for the following:
|
| foreach ( @data ) ) {
|s/^ //;
|$data_[ $jp++ ] = $_;
| }
|
`-
I'm assuming you are wanting to remove all entries in @data that
begin with a space, this will do it in one line:
@data = map( { if( $_ !~ s/^ //) { $_; } }, @data);
-
Frank Wiles [EMAIL PROTECTED]
http://frank.wiles.org
-
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: A better way, a perl way?
Frank Wiles wrote:
.--[ Jerry Preston wrote (2003/01/22 at 11:59:14) ]-- |
| I am looking for a better way, a perl way for the following: |
| foreach ( @data ) ) {
|s/^ //;
|$data_[ $jp++ ] = $_;
| }
|
`-
I'm assuming you are wanting to remove all entries in @data that
begin with a space, this will do it in one line:
@data = map( { if( $_ !~ s/^ //) { $_; } }, @data);
That doesn't compile. What are you trying to do?
Not sure why you're assuming that's what he wants, but if it is, wouldn't a
simple grep be the way to do it?
@data = grep $_ !~ /^ /, @data;
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way, a perl way?
Jeff 'Japhy' Pinyan wrote:
If you DON'T want that, you'd have to do:
for (@data) {
(my $copy = $_) =~ s/^ //;
push @data_, $copy;
}
Or something to that effect. Here's a one-liner:
@data_ = map { (my $copy = $_) =~ s/^ //; $copy } @data;
a bit shorter:
#!/usr/bin/perl -w
use strict;
my @data = (' 123',' 456',' 789');
my @data_ = ();
s/^ // for(@data_ = @data);
print join('',@data),\n,join('',@data_),\n;
__END__
prints:
123 456 789
123456789
david
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: A better way to handle array index?
From: Johnstone, Colin [EMAIL PROTECTED]
for example I read my form variables into a hash for processing.
I then reference them by the form fieldname.
#read STDIN, $PostData, $ENV{'CONTENT_LENGTH'};
#print post data =$PostDatabr;
#postdata will look like this
#[EMAIL PROTECTED]radAction=unsubscriberad
#Format=htmlSubmit=Submit I need to extract from this string the
#fields and their values
my @fields = split( /\/, $PostData);
...
Please don't do this. The query/posted data parsing is not as simple
as it seems. You are much safer if you
use CGI;
Or maybe
use CGI::Deurl;
Both available from CPAN, CGI.pm should already be installed.
Jenda
= [EMAIL PROTECTED] === http://Jenda.Krynicky.cz =
When it comes to wine, women and song, wizards are allowed
to get drunk and croon as much as they like.
-- Terry Pratchett in Sourcery
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way to handle array index?
From: chris [EMAIL PROTECTED]
I am looking for a less cryptic way to handle array index.
most cryptic
$array[0]
better
use constant NAME = 0;
$array[NAME]
This all depends on what do you want to do with the data structure.
But most probably you do want to use a hash.
$hash{NAME}
Jenda
= [EMAIL PROTECTED] === http://Jenda.Krynicky.cz =
When it comes to wine, women and song, wizards are allowed
to get drunk and croon as much as they like.
-- Terry Pratchett in Sourcery
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: A better way to handle array index?
And if you're really stuck with using arrays, you can always:
my @bases = ();
my $first = 0;
$bases[$first] = 'who';
-Original Message-
From: Johnstone, Colin
To: 'chris'
Cc: '[EMAIL PROTECTED]'
Sent: 10/19/02 5:47 PM
Subject: RE: A better way to handle array index?
That would be a hash. (or an associative array)
for example I read my form variables into a hash for processing.
I then reference them by the form fieldname.
#read STDIN, $PostData, $ENV{'CONTENT_LENGTH'};
#print post data =$PostDatabr;
#postdata will look like this
#[EMAIL PROTECTED]radAction=unsubscriberadFo
rmat=htmlSubmit=Submit
#I need to extract from this string the fields and their values
my @fields = split( /\/, $PostData);
#Once extracted I write the fieldnames and their values to the formData
Hash
#the index is the fieldname from the form
foreach $_ ( @fields ){
@data = split( /=/, $_ );
$formData{$data[0]} = $data[1];
}
#This routine is used to check the values in the form data hash for
debugging purposes
# while(($k,$v)=each(%formData)){
# print$k = $vbr;
# }
# I access the values of the fields by calling them as below
# another name for a has is an associative array
# print brEmail Address =.$formData{'txtEmailAddr'}.br;
# print Action =.$formData{'radAction'}.br;
# print Format =.$formData{'radFormat'}.br;
-Original Message-
From: chris [mailto:chris;home.com]
Sent: Sunday, October 20, 2002 10:40
To: [EMAIL PROTECTED]
Subject: A better way to handle array index?
I am looking for a less cryptic way to handle array index.
most cryptic
$array[0]
better
use constant NAME = 0;
$array[NAME]
Any ideas?
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: A better way to handle array index?
That would be a hash. (or an associative array)
for example I read my form variables into a hash for processing.
I then reference them by the form fieldname.
#read STDIN, $PostData, $ENV{'CONTENT_LENGTH'};
#print post data =$PostDatabr;
#postdata will look like this
#[EMAIL PROTECTED]radAction=unsubscriberadFormat=htmlSubmit=Submit
#I need to extract from this string the fields and their values
my @fields = split( /\/, $PostData);
#Once extracted I write the fieldnames and their values to the formData Hash
#the index is the fieldname from the form
foreach $_ ( @fields ){
@data = split( /=/, $_ );
$formData{$data[0]} = $data[1];
}
#This routine is used to check the values in the form data hash for debugging purposes
# while(($k,$v)=each(%formData)){
# print$k = $vbr;
# }
# I access the values of the fields by calling them as below
# another name for a has is an associative array
# print brEmail Address =.$formData{'txtEmailAddr'}.br;
# print Action =.$formData{'radAction'}.br;
# print Format =.$formData{'radFormat'}.br;
-Original Message-
From: chris [mailto:chris;home.com]
Sent: Sunday, October 20, 2002 10:40
To: [EMAIL PROTECTED]
Subject: A better way to handle array index?
I am looking for a less cryptic way to handle array index.
most cryptic
$array[0]
better
use constant NAME = 0;
$array[NAME]
Any ideas?
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: a better way?
open(FILE, yourfile) or die $!;
chomp(my(@lots) = FILE);
close FILE;
-Original Message-
From: Jerry Preston [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 26, 2002 11:30 AM
To: Beginners Perl
Subject: a better way?
Hi!
Is there a better way? A Perl way?
$j = 0;
while( file ) {
chomp;
( $lots[ $j++ ] ) = $_;
}
? @lots = file;
Thanks,
Jerry
The views and opinions expressed in this email message are the sender's
own, and do not necessarily represent the views and opinions of Summit
Systems Inc.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: a better way?
On Sep 26, Jerry Preston said:
Is there a better way? A Perl way?
$j = 0;
while( file ) {
chomp;
( $lots[ $j++ ] ) = $_;
That's usually written as
push @lots, $_;
}
Well, you could do:
chomp(@lines = FILE);
but why do you need the file in an array?
--
Jeff japhy Pinyan [EMAIL PROTECTED] http://www.pobox.com/~japhy/
RPI Acacia brother #734 http://www.perlmonks.org/ http://www.cpan.org/
** Look for Regular Expressions in Perl published by Manning, in 2002 **
stu what does y/// stand for? tenderpuss why, yansliterate of course.
[ I'm looking for programming work. If you like my work, let me know. ]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: a better way?
maybe the file has perl code and intends to:
eval{ @lines };
for some wacky reason. I am sure you can remember your early perl days when
you read files into arrays because it was cool and easy.
:^P
-Original Message-
From: Jeff 'japhy' Pinyan [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 26, 2002 11:36 AM
To: Jerry Preston
Cc: Beginners Perl
Subject: Re: a better way?
but why do you need the file in an array?
The views and opinions expressed in this email message are the sender's
own, and do not necessarily represent the views and opinions of Summit
Systems Inc.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: a better way?
Jeff,
I guess it an old 'c' habit. I do this to check each line for the item I am
looking for.
I there a better way and why?
Thanks,
Jerry
-Original Message-
From: Jeff 'japhy' Pinyan [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 26, 2002 10:36 AM
To: Jerry Preston
Cc: Beginners Perl
Subject: Re: a better way?
On Sep 26, Jerry Preston said:
Is there a better way? A Perl way?
$j = 0;
while( file ) {
chomp;
( $lots[ $j++ ] ) = $_;
That's usually written as
push @lots, $_;
}
Well, you could do:
chomp(@lines = FILE);
but why do you need the file in an array?
--
Jeff japhy Pinyan [EMAIL PROTECTED] http://www.pobox.com/~japhy/
RPI Acacia brother #734 http://www.perlmonks.org/ http://www.cpan.org/
** Look for Regular Expressions in Perl published by Manning, in 2002 **
stu what does y/// stand for? tenderpuss why, yansliterate of course.
[ I'm looking for programming work. If you like my work, let me know. ]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: a better way?
if you use an array you are using up memory.
small files are okay for that.. but you can do it in the while loop without
the array.
But TIMTOWTDI.
what are you checking for in the lines? Just an example will tell us what's
best for your application.
-Original Message-
From: Jerry Preston [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 26, 2002 11:51 AM
To: [EMAIL PROTECTED]
Cc: Beginners Perl
Subject: RE: a better way?
Jeff,
I guess it an old 'c' habit. I do this to check each line
for the item I am
looking for.
I there a better way and why?
Thanks,
Jerry
-Original Message-
From: Jeff 'japhy' Pinyan [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 26, 2002 10:36 AM
To: Jerry Preston
Cc: Beginners Perl
Subject: Re: a better way?
On Sep 26, Jerry Preston said:
Is there a better way? A Perl way?
$j = 0;
while( file ) {
chomp;
( $lots[ $j++ ] ) = $_;
That's usually written as
push @lots, $_;
}
Well, you could do:
chomp(@lines = FILE);
but why do you need the file in an array?
The views and opinions expressed in this email message are the sender's
own, and do not necessarily represent the views and opinions of Summit
Systems Inc.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: a better way?
On Sep 26, Jerry Preston said:
I guess it an old 'c' habit. I do this to check each line for the item I am
looking for.
I there a better way and why?
my $found = 0;# have we found 'jeff'?
while (FILE) { # reads ONE LINE at a time, and stores it in $_
if (/jeff/) { # if the line has 'jeff' in it
$found = 1; # set $found to true
last; # and stop processing the file
}
}
is more likely to be more efficient than
my $found = grep /jeff/, FILE;
or
my @lines = FILE;
my $found = grep /jeff/, @lines;
--
Jeff japhy Pinyan [EMAIL PROTECTED] http://www.pobox.com/~japhy/
RPI Acacia brother #734 http://www.perlmonks.org/ http://www.cpan.org/
** Look for Regular Expressions in Perl published by Manning, in 2002 **
stu what does y/// stand for? tenderpuss why, yansliterate of course.
[ I'm looking for programming work. If you like my work, let me know. ]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way to list variable names in report format?
Thank you. Now I can quit the horizontal scrolling. On Wed, 11 Sep 2002 20:52:59 -0400, [EMAIL PROTECTED] (Bob Showalter) wrote: I know beans about formats, but perldoc perlform contains this statement: The expressions may be spread out to more than one line if enclosed in braces. If so, the opening brace must be the first token on the first line. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way to list variable names in report format?
Oops. $$
@$myStuff{qw/column1 column2 column3/};
is definitely an improvement but my list is very long. I think I will
have to assign new variables just to make the listing in multiple
lines. Horizontal scrolling to read off-page code is not nice.
On Wed, 11 Sep 2002 16:42:10 -0700, [EMAIL PROTECTED] (John W. Krahn)
wrote:
Chris wrote:
I have many report columns and would like the format easier to read.
Is there a way to list the variables in multiple lines?
change this
myStuff-{column1},myStuff-{column2},myStuff-{column3}
Do you mean:
$myStuff-{column1}, $myStuff-{column2}, $myStuff-{column3}
to
myStuff-{column1},
myStuff-{column2},
myStuff-{column3}
to make the listing more readable but will not compile
How about:
@$myStuff{qw/column1 column2 column3/};
John
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way for seeding an annoymous hash
At 11:44 AM 8/8/02 -0700, drieux wrote:
On Thursday, August 8, 2002, at 11:04 , Peter Scott wrote:
At 10:38 AM 8/8/02 -0700, drieux wrote:
I'm not sure the average normal person would feel at home with say:
%{$by_os{$os_key}}-{$_}++ for(@$found);
Especially since it's only by accident that
%hash-{key}
happens to do the same thing as
$hash{key}
Many people think it's a bug and plan on eliminating it.
so how do I work around that
Simple; instead of typing
%hash-{key}
or any more complex variant of it, use
$hash{key}
should I use
${$by_os{$os_key}}{$_}++ for(@$found);
which is only marginally more Dense???
$by_os{$os_key}{$_}++ for @$found
(Pity that @{$by_os{$os_key}}{@$found}++ doesn't work...)
See perlref.
we're on the back side of this coding game
where I clean up all of the sillies that seemed
useful as I tested them out - and were suppose to
make the code simpler to read - hence also to maintain...
--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Any better way to make 1000000 becomes 1,000,000 ?
Connie -
Try this (not really much better) from Perl Cookbook #2.17:
use strict;
use warnings;
my $num = commify (1_000_000);
print $num\n;
sub commify
{
my $text = reverse $_[0];
$text =~ s/(\d\d\d)(?=\d)(?!\d*\.)/$1,/g;
return scalar reverse ($text);
}
Aloha = Beau.
-Original Message-
From: Connie Chan [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 29, 2002 9:13 PM
To: [EMAIL PROTECTED]
Subject: Any better way to make 100 becomes 1,000,000 ?
my $num = 100; # or whatever integer;
$num = reverse($num);
$num =~ s/(\d{3})/$1,/g;
chop $num if $num =~ /,$/;
$num = reverse($num);
print $num;
I have this script to make an integer with comma at every 3 digits, from
right to left.
(What should this presentation way name actaully ?? ) Like 123456 will
becomes 123,456.
Is there anyway can making this simpler ? Can sprintf help ?
Another question is that how can I use 16 digits long integer ? Any LongInt
there ?
Rgds,
Connie
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any better way to make 1000000 becomes 1,000,000 ?
This works for me
http://search.cpan.org/doc/WRW/Number-Format-1.44/Format.pm
use strict;
use warnings;
use Number::Format qw(:subs :vars);
$THOUSANDS_SEP = '.';
$DECIMAL_POINT = ',';
my @number = (123456789,123);
foreach my $number (@number) {
print format_number($number) . \n;
}
use Number::Format qw(:subs);
my @number = (123456789,123);
foreach my $number (@number) {
print format_picture($number, '###,###,###,###') . \n;
}
On Tue, 30 Jul 2002 15:12:30 +0800, [EMAIL PROTECTED] (Connie Chan)
wrote:
my $num = 100; # or whatever integer;
$num = reverse($num);
$num =~ s/(\d{3})/$1,/g;
chop $num if $num =~ /,$/;
$num = reverse($num);
print $num;
I have this script to make an integer with comma at every 3 digits, from right to
left.
(What should this presentation way name actaully ?? ) Like 123456 will becomes
123,456.
Is there anyway can making this simpler ? Can sprintf help ?
Another question is that how can I use 16 digits long integer ? Any LongInt there ?
Rgds,
Connie
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way for ugly code?
--- Teresa Raymond [EMAIL PROTECTED] wrote:
Curtis,
What part of the code that you posted actually does the untainting?
Here's one way to grab the data and untaint it in one line:
my ( $name ) = ( $q-param('name') =~ /^(\w+)$/ );
Note that the parentheses around *both side* of the assignment.
Also, you need the parentheses in
the regular expression. $name will be undef if it does not untaint.
Hi Teresa,
From perlsec: The only way to bypass the tainting mechanism is by referencing
subpatterns from a
regular expression match.
In Perl, if you are referencing subpatterns and you put parentheses around the entire
expression,
the sub patterns are returned (list context) and are, of course, untainted. For
example:
my ( $a, $b, $c ) = ( '111-222-333' =~ /^(\d+)-(\d+)-(\d+)$/ );
print $a $b $c;
In the above code, 111 222 333 will be printed. Note that parentheses are also
around the right
side of the expression. The above snippet will not work otherwise.
Cheers,
Curtis Poe
=
Senior Programmer
Onsite! Technology (http://www.onsitetech.com/)
Ovid on http://www.perlmonks.org/
__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way for ugly code?
--- Mark Ross [EMAIL PROTECTED] wrote:
Hi all,
I'm curious how I can condense this code. I'm pulling
my values from a Web submitted form (using CGI), and I
need to untaint them.
But, each form field has different requirement for
what characters it can match (account number should
only be numbers, etc).
I was wondering if there's a better way to do go
through these all without dupicating so much code? I'd
be more than willing to give up the customized error
messages if I could reduce these down to oneliners.
Here's one way to grab the data and untaint it in one line:
my ( $name ) = ( $q-param('name') =~ /^(\w+)$/ );
Note that the parentheses around *both side* of the assignment. Also, you need the
parentheses in
the regular expression. $name will be undef if it does not untaint.
Cheers,
Curtis Poe
=
Senior Programmer
Onsite! Technology (http://www.onsitetech.com/)
Ovid on http://www.perlmonks.org/
__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way for ugly code?
Curtis,
What part of the code that you posted actually does the untainting?
--- Mark Ross [EMAIL PROTECTED] wrote:
Hi all,
I'm curious how I can condense this code. I'm pulling
my values from a Web submitted form (using CGI), and I
need to untaint them.
But, each form field has different requirement for
what characters it can match (account number should
only be numbers, etc).
I was wondering if there's a better way to do go
through these all without dupicating so much code? I'd
be more than willing to give up the customized error
messages if I could reduce these down to oneliners.
Here's one way to grab the data and untaint it in one line:
my ( $name ) = ( $q-param('name') =~ /^(\w+)$/ );
Note that the parentheses around *both side* of the assignment.
Also, you need the parentheses in
the regular expression. $name will be undef if it does not untaint.
Cheers,
Curtis Poe
=
Senior Programmer
Onsite! Technology (http://www.onsitetech.com/)
Ovid on http://www.perlmonks.org/
__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A better way?
--- Tim Musson [EMAIL PROTECTED] wrote:
Hey all,
I have this code fragment.
if ($Var eq String) {
Sub($Var1);
} elsif ($Var2 =~ /$STRING/) {
Sub($Var1);
}
Is this a better way?
if (($Var eq String) || ($Var2 =~ /$STRING/)) {
Sub($Var1);
}
I like it better.
Personally, I'd say
Sub($Var1) if $Var eq String or $Var2 =~ /$STRING/;
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
Re: A better way?
On Fri, 22 Jun 2001, Tim Musson wrote:
Is this a better way?
if (($Var eq String) || ($Var2 =~ /$STRING/)) {
Sub($Var1);
}
I usually write...
if ($Var eq String or $Var2 =~ /$STRING/) {
...as I like the diffrent precidence of the 'or' operator.
You can also leave off the if you are using Perl 5.
As to if it is a better way... I would say yes because it
probably saves a CPU cycle or two, and you reduce the chance
of editing errors by not having duplicate code that can be
a pain to maintain.
--
Ian
