not really. The crucial point is that the entire content of that csv file can be auto-generated in a few linew unless I'm missing something important here.
Take this as a simple example:
my @combinations = ( "1,1","1,2","2,1","2,2")
vs.
my @combinations;
for my $i (1..2){
for my $j (1..2) {
push @combinations, "$i,$j";
}
}
I'm generating an array in this case with strings that are combinations of elements, in this case simply the number 1 and 2 but you can easily substitute that with "THIS", "THAT" and "This Evaluation", "That Evalutation" etc, which is what you have (if I remember your other thread correctly).
In the first example, I harcode the array by typing all the combinations in my script. I could also save them to a file in csv format, as dump of the array (using Data::Dumper), or whatever format you can think of - the problem remains: I'm hardcoding all possible but entirely predictabe and therefore scriptable combinations of elements.
In the second example, I generate all possible combinations on the fly. Again, if I remember correctly, you only need to do that to generate a file name. For that reason you don't even need to save the data to an array or a hash - you just generate the string as a combination of all the elements and then use that to open your file - job done.
Of course, in my simple example, the second version is longer than the first, but you can easily see how that changes quickly with more elements and more combinations.
So, if the data can be generated on the fly, do it - that's the whole point of scripting. If not, i.e. sometimes you want the scale for a "THIS" plot to be "0:" and sometimes ":100" and tehre is no way to predict it, then you have to resort to a config file (for which you can use a number of options, such as YAML or simple config format - have a look around on the CPAN).
Hope this helps. | [reply]
[d/l]
[select] |
Thank you tospo.
The problem is that not each number can be combined with each evaluation name. Therefore I do need a config file. In fact I happened to populate the hash %module reading the csv-file in the following way:
open(my $fh, "<", "parameter.csv") or die "$!";
my $header = <$fh>;
while(<$fh>) {
my @line = split(/;/, $_);
my $t = $line[0];
${module}{$t}{name} = $line[1];
my $n = $line[2];
${module}{$t}{indicator}{$n}{ind} = $line[3];
${module}{$t}{indicator}{$n}{yscala} = $line[4];
}
close $fh;
The file names in the gnuplot command are generated afterwards on the fly whereby only the names are created which are allowed by config file.
After that I used the code from wfsp from Re^2: How to declare variables per loop in the following way:
my @cmds;
for my $number (sort keys %{${module}{$topic}{indicator}}){
my $cmd = build_command($number, %args);
push @cmds, $cmd;
}
for (my $i=0; $i<@cmds; $i++) {
if($i == 0 or $i % 2 == 0) {
$cmds[$i] = "$multiplot\n\n$cmds[$i]";
}
}
for (my $i=0; $i<@cmds; $i++) {
if($i % 2 == 1 or $i == $#cmds) {
$cmds[$i] = "$cmds[$i]\n\n unset multiplot\n\n";
}
}
my $slurpline;
for (my $i=0; $i<@cmds; $i++) {
$slurpline.=$cmds[$i];
}
The gnuplot command itself is very short now:
open my $P, "|-", "gnuplot" or die;
printflush $P qq[
$postscript
$slurpline
];
close $P;
Thanks again!
VE
| [reply]
[d/l]
[select] |
Whatever works best for you! Just a short comment: you can easily combine the 4 for loops in your code example into a single one without pushing the commands into an array of commands, just increment $i inside the loop then do your tests for i%2 using one if-else control structure.
The whole set-up still looks awkward to me but that doesn't matter and you should go with it if it works. After some more experience you might come back to this and then immediately see a better way of doing it. If I now look at some of my early Perl scripts it causes me physical pain :-). It's just the way it is. Good luck with your further adventures in Perl!
| [reply] |
I used to know a girl called sue strict. shudders | [reply] |