All the records where the 4th column has a 1 value are pushed into @grp

Then, $md[1]=[@grp];

Next, it clears @grp and reads the file again and all records where the 4th column has a 2 value are pushed into @grp

Then, $md[2]=[@grp];

This repeats 50 times in order to create an organized multi-dimensional array of the data from the text file.

This part works as intended.

Now comes the part where I am trying to combine all the records which had a value of 1 in the 4th column, which I stored in @grp and then store into $md[1], into a single record. Will this work? Oh, I am also trying to sort it to keep it in order. $a below should be a date (ex. 201211).

Re: [Laurent_R] Moving part of Multi-Dimensional Array to an Array
[In reply to]

Can't Post

I got it to work.

@grp = @{$md[1]};

I know it seems like extra copying back and forth, but that is because it's needed to organize all the data in one location because there are 6 columns of data per month (4yrs to report on continuously) and 50+ rows (categories) on the report I am automating. So, while I do have to do some additional copying initially I am using loops which saves me time in the long run.

Otherwise, if I just print directly from the @grp as you had suggested what happens if new categories are added/removed? I would then have to return to the code and make adjustments manually. By using the extra copying and loops this report will self-sustain. I have 100+ reports that I already automated and set them up so they run without any intervention needed, aside from random issues that pop-up sometimes.

Of course I didn't expect you to know that since you're viewing the situation from another monitor.

Re: [lilmark] Moving part of Multi-Dimensional Array to an Array
[In reply to]

Can't Post

Compressing your code down to fewer lines should not be a primary concern. It is more important to have logical flow, easy to read/understand and without any obvious inefficiencies. Keeping those within the primary focus will help keep the code length down to a reasonable level.

Once the code is far enough along in development, you can profile it to find the inefficiencies and then benchmark different methods to improve those inefficiencies.

Please put your code within the "code tags" whenever you post any code. The code tags will retain the indentation which will make it easier for us to read and follow your code logic.

Here are a few code comments for you to consider.

All Perl scripts you write should include the strict and warnings pragmas. Those pragmas will aide in pointing out lots of common coding mistakes which can be difficult to track down as the code expands. So, begin all scripts like this:

Code

#!/usr/bin/perl

use strict; use warnings;

The strict pragma requires you to declare your vars, which is normally done with the 'my' keyword which declares a lexical var or you can use the 'our' keyword to declare a global var if required. You vary rarely need to use global vars.

Quote

Code

open FP, "$path/Analysis.txt";

That line has multiple problems. 1) You should ALWAYS check the return code of an open call to verify that it was successful and take proper action if it failed instead of blindly assuming that it succeeded.

2) It is better/safer to use the 3 arg form of open especially if any portion of it was provided by user input.

3) It is best practice to use a lexical var for the file handle instead of a bareword.

Code

open my $analysis_fh, '<', "$path/Analysis.txt" or die "failed to open '$path/Analysis.txt' <$!>";

Quote

Code

while(chomp($r=<FP>))

That statement is not doing exactly what you think. The condition that it's testing is the return value of chomp, not the assignment of $r. The issue here is that it will needlessly generate the following warning if the last line of the file does not contain a line terminator.

Quote

Use of uninitialized value in chomp at ...

Quote

Code

for ( $i = 0 ; $i < scalar @{ $pp_tot{$lf_cd}{$yrmo} } ; $i++ ) {

Perl's for loop syntax is cleaner and more efficient than the C style loop you're using.

Re: [lilmark] Moving part of Multi-Dimensional Array to an Array
[In reply to]

Can't Post

In most applications, "efficiency" is seldom an issue. It is far more important that readers (including yourself) can understand the code. Few of us have the discipline to rewrite "working" code for the benefit of someone else. You really only have one chance at the truly important decisions such as the data structures.

Code

while(chomp($r=<FP>)) {

This line will not process your last line of data if it does not have a newline at the end. (Probably not an issue if you are controlling the data, but why take a chance?) Good Luck, Bill

Re: [BillKSmith] Moving part of Multi-Dimensional Array to an Array
[In reply to]

Can't Post

In Reply To

In most applications, "efficiency" is seldom an issue.

Well, yes and no...

I understand what you mean, but I am working daily with GB of data, efficiency is often an issue...

I have had recently an application which was going to take more than 60 days to execute. I rewrote it entirely in Perl, and managed to get it working in 13 hours. This makes a real business difference.