2. Compare two arrays and show the elements that exist in both (I actually screwed up in my live question, but the answers were still informative). This is a great question because it shows how someone thinks. Lower level devs use nested loops (I did, when this was thrown at me a few years ago). Smart people use hash slices. Really smart people use 'undef'd hash slices to save memory.

Arjen

Your example fails if @a1 or @a2 have a value more than once. For example, @a1 = (1, 2, 3, 2, 1) and @a2 = (4, 5, 6, 5, 4). Your grep would show 1, 2, 4, and 5 as elements existing in both arrays, when the right answer is obviously zero.

I will also disagree with cLive ;-) that "really smart people" use the undef'd hash slices to save memory - if memory is a concern, sure. But in general, the difference is not going to be significant. Premature optimisation and all that. I've even found sometimes where using the standard "++$hash{$value}" turns out to be handy three months later when the number of times a value shows up becomes relevant. I didn't need to change nearly as much code because I wasn't "really smart" according to cLive's definition.

Anyway, as always, TIMTOWTDI, so being able to use the undef'd hash slice is still a tool to keep handy:

  my %a1;
  undef @a1{@a1};
  my @in_both = grep { exists $a1{$_} } @a2;
[download]

Unfortunately, this has the side effect of showing duplicates if @a1 has a value, and @a2 has that value multiple times. Which, of course, may be what you want, but it's not explicit in the original requirement.

  my (%a1, %a2);
  undef @a1{@a1};
  undef @a2{@a2};
  my @in_both = grep { exists $a1{$_} } keys %a2;
[download]

Oh, and I also recommend better variable names than what I'm using here. :-)

Update: Added the italicised part in the last line.

The example isn't a real good one, I know. I was just playing around with variations on a theme, not trying to get a bullet-proof solution. But still, good point about the example :-)

cLive ;-)'s solution is a variation on a theme explained in the Cookbook. I was under the impression that there existed some really nifty hash slice trick to get the results that I didn't know about, hence the question.

In my production code, I use good variable names. When experimenting, I'm not as picky :-) I probably should be when posting code here.

Thanks, Arjen

Interestingly, you made the same mistake an applicant made when doing the compare - as Tanktalus has pointed out :)

By the way, Tanktalus, by "really smart people", I was referring to tilly here ;-)

cLive ;-)

It is more accurate to say that smart people know that they can use the undef trick - then don't. Because it is an unnecessary micro-optimization that could easily confuse others.

Smart people use hash slices. Really smart people use 'undef'd hash slices to save memory.

undef'd hash slices save time not memory.

Update: Also, as pointed out to me in a previous post, only use this method if you don't care about the values of the hash, as the values do not necessarily get set to undef.

I notice that in five years no one has filled in the details of the concise implementation.

# given two arrays you want to compare for common elements, @a1 & @a2 
+...
my %common;
undef @common{@a1};
delete @common{@a2};
my @common = keys %common;
#for example:
  DB<1> @a1 = qw(a b c d e)

  DB<2> @a2 = qw(a c e )

  DB<3> undef @common{@a1}

  DB<4> x \%common
0  HASH(0x8408418)
   'a' => undef
   'b' => undef
   'c' => undef
   'd' => undef
   'e' => undef
  DB<5> delete @common{@a2}

  DB<6> x \%common
0  HASH(0x8408418)
   'b' => undef
   'd' => undef
  DB<7> print join " ", keys %common
b d
[download]

As Occam said: Entia non sunt multiplicanda praeter necessitatem.