in reply to Re: Extracting columns from a two dimensional array
in thread Extracting columns from a two dimensional array

Could this work for populating a hash with 2 columns of an array or arrays? And if so, would it be more efficient than walking through the array assigning key/value pairs from the columns...as in:
my %hash; for (my $row = 0; $row < @array; $row++) { $hash{"$array[$row][6]"} = "$array[$row][7]"; }
Jack
Cogito cogito, ergo cogito sum
(I think I think, therefore I think I am)

Replies are listed 'Best First'.
Re^3: Extracting columns from a two dimensional array
by Aristotle (Chancellor) on Dec 21, 2004 at 14:34 UTC

    That is an entirely different question.

    First off: please don't use for(;;) loops in Perl unless you really need to. For iterating over arrays or lists, there is almost never a good reason to favour this type of loop. Use foreach( LIST ) instead — that will very nearly remove the source for a large chunk of off-by-one errors.

    And make it a habit not to use doublequotes where you don't need them. It will bite you when stringification is not an identity function, such as with references, besides the fact that it forces needless work on the interpreter.

    foreach my $row ( @array ) { $hash{ $row->[ 6 ] } = $row->[ 7 ]; }

    If you actually needed the index, you can do that too:

    foreach my $i ( 0 .. $#array ) { $hash{ $array[ $i ][ 6 ] } = $array[ $i ][ 7 ]; }

    Of course in this case you don't.

    As to your question, well, something very similar can indeed be done:

    my %hash = map { $row->[ 6 ] => $row->[ 7 ] } @array;

    Whether that's faster or not I don't know and don't care, and neither should you. I do know that it's not going to be measurably faster or slower either way, since both ways do roughly the same amount of work. Other factors are going to dictate the speed of your program anyway — if you read a lot of data from a file or pull any across a network, the penalty waiting for spinning metal or travelling electrons will outweigh microoptimizations like this one by so many orders of magnitude that the impact of for vs map won't be more than noise in your benchmarks. (You do benchmark, don't you?) And that's just two examples of the things that will eclipse this so much. So choose the idiom that you find easier to understand.

    • Programs must be written for people to read, and only incidentally for machines to execute. —Abelson and Sussman
    • It is easier to optimize correct code than to correct optimized code. —Bill Harlan

    Makeshifts last the longest.

      OK. Thanks for the advice on for (;;) loops vs foreach loops. That's just the kind of obvious thing that I don't know.

      Either idiom works for me. I try to program for a hypothetical programmer who'll have to support my stuff after I'm gone...and who knows less than me - a scary proposition in anyone's book. Anyway, if there's an inelegant but clear way of doing something and an elegant but obscure way of doing something, I'll take the clear/inelegant one - assuming there's no significant performance hit 'cause yes, I do benchmark my code. I'm translating someone else's undocumented, c-shell spaghetti code into Perl and I don't want to do unto others as was done unto me.

      Jack

      Cogito cogito, ergo cogito sum
      (I think I think, therefore I think I am)

        Oh goodie. C shell? I think the “spaghetti” bit is redundant in that sentence… :-) Good luck with that — and commendations on your good habits.

        Makeshifts last the longest.