Parsing/Comparing

mrras25 has asked for the wisdom of the Perl Monks concerning the following question:

I can not wrap my head around an easy way of doing this. I have code and it works, there is just a lot of the code and it seems a bit on the repetative side. Here is the code:

   %new_sect= buildhash('sect');
   %h_srf   = buildhash('rf');

   #### Start comparing!
   while(<OSS>) {
      chomp;
      s/\015//g;
      ### Split OSS file
      my($cellsiteID,$sectID,$mcc,$mnc,$lac,$ci,$bscid,$bts,
         $bearing,$mscID,$lat,$long,$tilt,$agl) = (split /,/, $_ );

      ### Set new varibles for reports or build of new scout!
      my($s_cellsite,$s_sectid,$s_mcc,$s_mnc,$s_lac,$s_ci,$s_bscid,
         $s_bts,$s_bearing,$s_mscid,$s_lat,$s_long,$s_tilt,$s_agl);

      if(exists $h_ssect{$cellsiteID."_".$sectID}) {
         my (@scoutSA,@scoutRA);
         my $change = 0;
         chomp(@scoutSA = split(/,/,$h_ssect{$cellsiteID."_".$sectID})
+);
         chomp(@scoutRA = split(/,/,$h_srf{$cellsiteID}));

         if($mcc !~ /^$scoutSA[$ocfg{'oss2.primpos'}]$/) {
            $change++; $s_mcc = $mcc;
            push(@{$chged{$cellsiteID."_".$sectID} },
                 $mcc,$scoutSA[$ocfg{'oss2.primpos'}] );
         } else {
            $s_mcc = $scoutSA[$ocfg{'oss2.primpos'}];
            push(@{$chged{$cellsiteID."_".$sectID}}, "NULL","NULL");
         }
         ...
[download]

The second "if" statement goes on for 13 columns... Question is there a shorter (code wise) to do this repetative code? Some columns are numbers some is ASCII. And the varibles do not have to be set that way, they could be a generic variable with a number if it makes the code shorter. Thank you, Robert

Comment on Parsing/Comparing Download Code

Replies are listed 'Best First'.
Re: Parsing/Comparing by duff (Parson) on Mar 10, 2006 at 19:30 UTC
If this is a repetitive task that you're performing on each of your `$mcc`, `$mnc`, `$lac`, etc. variables, then the easiest way to eliminate the repetitive code is to put the values into an array or hash and use a loop to iterate over all of them. I'd use a hash in your case. For example: my @fieldnames = qw/cellsiteID sectID mcc mnc lac ci bscid bts bearin +g mscID lat long tilt agl/; my %hash; # you'll want a better name :-) while (<OSS>) { @hash{@fieldnames} = split /,/; my %new = %hash; # new values go here my $key = join "_", @hash{'cellsiteID','sectID'}; next unless exists $h_ssect{$key}; my @scoutSA = split(/,/,$h_ssect{$key}); for my $f (@fields) { if ($hash{$f} ne $scoutSA[$ocfg{'oss2.primpos'}]) { $new{$f} = $hash{$f}; push(@{$chged{$key}}, $hash{$f},$scoutSA[$ocfg{'oss2.primpos'} +] ); } # ... } [download] I'm not sure how `$scoutSA[$ocfg{'oss2.primpos'}]` varies from `$mcc` to `$mnc` to the next variable and so on, so you'd need to incorporate a mapping in there for that too. Some general observations about your code: I think it's weird that you're pushing the two `"NULL"` values when you're not making a change. if you're going to use the expression `$cellsiteID."_".$sectID` many many times, you might just want to stick that in a variable of its own so that you don't inadvertently screw up. you probably don't want to use a pattern match when comparing the values in case there are characters that are special to the regular expression engine. Just use straight equality operators. Since you say some are strings and some are numbers, keep a hash that tells you which is which so that your program knows which equality test to perform. If the rest of your loop consists entirely of the body of that `if` statement, you may want to eliminate a little of the stairstep effect by using `next unless exists $h_ssect{$key};` I've made these assumptions and included them in my example above. If I'm way off base, let me know. duff	[reply] [d/l] [select]
Re^2: Parsing/Comparing by mrras25 (Acolyte) on Mar 10, 2006 at 20:23 UTC
Duff, Thank you for your response... I really needed another set of eyes looking at this code since i was just having a fit with it. Your observations are not far off base and I am going to try some of your suggestions... The reason the code was written the way it was is because I have to report on 4 different aspects of the <OSS> vs the hash or arrays I am comparing it to (failed to mention that earlier) The NULL factors where there because in the report i have to generate they want the fields blank if there is no change to the attribute this was easiest to get a report out to them by yesterday! Now I have some "free" time to clean up the code and work it better... The report I am generating is a CSV file as well and every column needs to match up. Thank you again for the response and I am going to try some of your suggestions. Robert	[reply]