I'm convinced that map & grep aren't as heavily used as they could be because people don't understand them.

I don't think I agree with the implied premise that map() and grep() should be used more heavily. I'd say they are probably used inappropriately at least as often as appropriate uses for them are missed.

For instance, in the example you gave, you'd probably be better off using a hash to determine common elements.

Update: You should also be more careful to check your benchmarks for correctness. Your "using grep" benchmark doesn't even reference @array1...

Update 2: I also just noticed you are using grep in a scalar context in the unless clause in your "using foreach" sub. That's one of those inappropriate uses of grep I mentioned above...

-sauoq
"My two cents aren't worth a dime.";

The hash trick is a nice way if the array is small enough. for huge arrays the algorhitmical/runtime trade may be worth the price to save memory.


holli, /regexed monk/

Sure... if memory is so tight that you have to choose an O(n * m) time complexity over O(n + m) then I guess you gotta do what you gotta do.

Of course, in that case (and especially if this is a routine task) you are almost certainly going to win by throwing more RAM at the problem because the larger your dataset the more (time) you are saving with the linear algorithm.

Update: Also note that the additional memory you need will be relative to the smaller of your two arrays. (As a possible optimization depending, of course, on your data.)

-sauoq
"My two cents aren't worth a dime.";

I'm convinced that map & grep aren't as heavily used as they could be because people don't understand them.

'using grep' => sub {
  my @common;
  my %seen;

  @common =
    grep {
     my $element1 = $_;
     !$seen{$element1}++ and grep { $element1 eq $_ } @array2
    } @array1;
},
[download]

dang typos of mine!

Thanks! :)

Jason L. Froebe

Team Sybase member

No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

At least one book I can think of does. Check out Dominus' Higher-Order Perl (ISBN 1558607013).

As to the question of grep and map being used as much as they could, I couldn't agree more. At work, I've had to train a few people to use them instead of foreach when they made sense ... and then untrain them a bit when they started using them where they didn't make sense. The point isn't to religiously worship them, but to make your code do what it says: if you're converting one list into another, you're mapping from one to the other. If you're finding elements in a list, you're grepping for them.

By speaking idiomatically perl, you may get a speed benefit (as you did in your benchmark), but, more importantly, you get a maintenance benefit: your code looks like a design document!

That is actually part of the reason why I don't like map's and grep's used in void context - they are no longer reading like plain English. "Map from @common to ... nothing?" Instead, just use for/foreach: "For each element in @common, do..." That reads like exactly the solution you're attempting to do. Which is probably how you're thinking of the problem - and, any time your can code your solution in the domain of the problem instead of the domain of the solution, you're going to end up with clearer and more flexible code.

-Andrew.

It comes from the (Unix) grep utility which stands for (g)lobal-(r)egular (e)xpression-(p)rint.

In vim, the command :g/re/p (where g means "global", re is clearly "regex" and p means "print") will find all lines matching the regex and print them in a list. This was apparently true of vim's predecessors as well, but it's still a valid (and useful) command in vim today. See also Wikipedia.

Says chester:

In vim...

The g/re/p command actually goes back to ed, which was the original Unix editor, back around 1972, and is still provided with all Unix systems. After ed came vi, the visual editor, with command syntax similar to ed's, and then vim, which is an improved version of vi.

Early versions of Unix also had a gres command (perform a substitution on all matching lines) but it was obsoleted by sed and abandoned.

--
Mark Dominus
Perl Paraphernalia

First, new programmers will have difficulty lining up multiple actions all at once. Compare these:

my @newlist = map { $_*2 } @list;

my @list;
my @newlist;
for my $item( @list)
{
  push @newlist, $item * 2;
}
[download]

The second example is easier for a newbie to manage. It loops through @list, one at a time. Each time through, $item will hold the active value. Multiply each value by 2, and save it in @newlist.

Second, it's easier to debug the 2nd example. There are several places to breakpoint or print out intermediate results to check that the code behaves as expected. Printing out intermediate results in a map is also easy, but it has to be done carefully to avoid munging the map return values.

My point is that a newbies coming from some other languages (those without map or grep) would be more comfortable with the 2nd form. Once entrenched, they are less likely to embrace map and grep without extra incentives.