2 array problem

[katera]

Help

I have 2 array @a @b
How to exclude second array from first?

Eg
@a= ("123;first", "124;second", "013;bla3", "011;bla4", "050,bla5");
@b= (123,011,000,050);


result:
@c= ("124;first", "013;bla3");

Thanks

 

[Michele Dondi]

I have 2 array @a @b
How to exclude second array from first?

perldoc -q difference

Eg
@a= ("123;first", "124;second", "013;bla3", "011;bla4", "050,bla5");
@b= (123,011,000,050);


result:
@c= ("124;first", "013;bla3");

Not exactly the same as the FAQ entry. Try to adapt that as an
exercise. If you can't, come back and ask for more help.


Michele

 

[anno4000]

Help

I have 2 array @a @b

You should avoid the variable names "a" and "b" in Perl, they have
special significance and don't behave like other variables in
all respects.

How to exclude second array from first?

Eg
@a= ("123;first", "124;second", "013;bla3", "011;bla4", "050,bla5");

^
Why is the separator in the last element a comma? I'll assume it's
a semicolon like the others.

@b= (123,011,000,050);

You are specifying the elements of @b as numbers with leading zeroes,
but these are lost in evaluation. The number 050 will not match the
string "050" in "050;bla5". Specify @b as strings.

result:
@c= ("124;first", "013;bla3");

There is no "124;first" in array @a but only "124;second".

In summary, every one of your three lines of problem description
contains an error. Please take more care, the inconsistencies
make it time-consuming just to find out what you want to achieve.

Here is one way:

my @a = ("123;first", "124;second", "013;bla3", "011;bla4", "050;bla5");
my @b = qw(123 011 000 050);

my @c = do {
my %h = map split( /;/) => @a;
delete @h{ @b};
map "$_;$h{ $_}" => keys %h;
};

print "@c\n";

Anno

 

[phus]

katera дµÀ£º

Help

I have 2 array @a @b
How to exclude second array from first?

Eg
@a= ("123;first", "124;second", "013;bla3", "011;bla4", "050,bla5");
@b= (123,011,000,050);


result:
@c= ("124;first", "013;bla3");

Thanks

try

my @a= ("123;first", "124;second", "013;bla3", "011;bla4",
"050;bla5");
my @b= ('123','011','000','050'); # not 123 but '123', etc
my @c = grep {!exists(${{map {$_=>1} @b}}{(m/^(\d+)/)[0]})} @a;
print "@c\n";

 

[Michele Dondi]

You are specifying the elements of @b as numbers with leading zeroes,
but these are lost in evaluation. The number 050 will not match the
string "050" in "050;bla5". Specify @b as strings.

And, (to the OP) a cheap way to do so is to put a qw in front of the
parenthesis and make those commas into spaces.


Michele

 

[anno4000]

(e-mail address removed)-berlin.de ([email protected]) wrote
on MMMMCMXCIV September MCMXCIII in <URL@ > Help
@@ >
@@ > I have 2 array @a @b
@@
@@ You should avoid the variable names "a" and "b" in Perl, they have
@@ special significance and don't behave like other variables in
@@ all respects.

Well, that's only $a and $b.

Yes, but they're package variables, so @a and $a aren't completely
independent.

use strict; use warnings;
my ( @l);

# a legit use of $a and $b
@l = sort { $a <=> $b } 1, 2, 3;

# ... makes @a behave differently
@l = @main::a; # no warning "once" here

# ... from @x
@l = @main::x; # this warns

Here the "...used only once" warning is not issued for @a. If the
"sort" line is commented out, the warning appears for both @a and @x.

Anno

 

[Michele Dondi]

That '@a' doesn't warn in your example has little to do with @a being
special. It just has to do with the fact that *a exists. Which exists

That's surely what Anno meant. As you surely know full well.


Michele

 

[Uri Guttman]

p> my @a= ("123;first", "124;second", "013;bla3", "011;bla4",
p> "050;bla5");
p> my @b= ('123','011','000','050'); # not 123 but '123', etc
p> my @c = grep {!exists(${{map {$_=>1} @b}}{(m/^(\d+)/)[0]})} @a;

yow!! do you realize that you are building the anon exists hash for EACH
iteration of the grep? that hash should be built before the grep line
and used inside to replace the map.

uri

 

[anno4000]

Michele Dondi ([email protected]) wrote on MMMMCMXCIV September
MCMXCIII in <URL:<>
<> >That '@a' doesn't warn in your example has little to do with @a being
<> >special. It just has to do with the fact that *a exists. Which exists
<>
<> That's surely what Anno meant. As you surely know full well.


Then I don't get it. @a behaves the same as @c.

True, but the specialness of $a (the package variable) makes it easier
to use it inadvertently. That way @c is slightly safer than @a.

Anno

 

[anno4000]

(e-mail address removed)-berlin.de ([email protected]) wrote
on MMMMCMXCVI September MCMXCIII in <URL: > Michele Dondi ([email protected]) wrote on MMMMCMXCIV September
> MCMXCIII in <URL: > <>
> <> >That '@a' doesn't warn in your example has little to do with @a being
> <> >special. It just has to do with the fact that *a exists. Which exists
> <>
> <> That's surely what Anno meant. As you surely know full well.
>
>
> Then I don't get it. @a behaves the same as @c.

True, but the specialness of $a (the package variable) makes it easier
to use it inadvertently. That way @c is slightly safer than @a.


I still fail to get it. You seem to be saying "because $a is special,
you might not get the warning @main::a used only once". But that is
only a useful warning if you *mistype* a variable name - in which case
it's safer to use @a (which if mistyped to @c triggers the warning -
or triggers a strict error) than to use @c (which if mistypes to @a may
not trigger the warning or error). But that doesn't make much sense.

The advice would have to be never to misspell "a" or "b" when you intend
to write something else. I guess you got me there.

So the use of @a, @b, %a, and %b as package variables (or lexicals)
seems to be technically no problem. The lexicals $a and $b should be
avoided if there is a chance you want to run sort() in the same
scope. There always is; you'd have to use a prototyped comparison
function, a major nuisance.

If one is interested in them at all, the package variables $::a and
$::b are less problematic than they would seem to be. If used in a
sub, you must localize them, but that goes for all package variables
that aren't meant to be global. $a and $b are only special in that
they can't reasonably be used globally.

The reason to avoid them would be that from "perldoc -f sort" one
would expect sort() to overwrite them randomly. But that doesn't
happen:

( $a, $b) = ( 99, 100);
my @s = sort { $b <=> $a } 1 .. 4;
print "$a $b\n";

still prints "99, 100". The preserving behavior has been around for
a long time, but it isn't documented or I overlooked it more than once.
Apart from that, there doesn't seem to be much reason to avoid $::a
and $::b at all, except, of course, who wants them in the first place.

Lexical $a and $b would be nice, but they remain problematic.

Anno