Re^3: Selecting a Specific Keys in Relation to a List

I agree about using exists on a hash of "unwanted" keys instead of the array. Good point. I didn't go that route due to the small number of keys (3) in the example. For larger sets of keys to check against, a grep on a array would definitely not be the way to go.

And, the matching in the regex is easily fixed by using /^$k$/ instead, which would allow the possible exceptions like ytd_total, etc.

Hadn't thought about List::MoreUtils, either.

---
echo S 1 [ Y V U | perl -ane 'print reverse map { $_ = chr(ord($_)-1) } @F;'

Comment on Re^3: Selecting a Specific Keys in Relation to a List

Replies are listed 'Best First'.
Re^4: Selecting a Specific Keys in Relation to a List by TGI (Parson) on Nov 02, 2007 at 18:33 UTC
For a small number of keys, the nested loop isn't so bad. I've been burned enough times by changing requirements that if I have two algorithms of similar complexity to code and cost to run, I'll almost always favor the one that scales better, even if the ability to scale isn't strictly necessary. The matching regex should probably include a quotemeta as well as the start and stop anchors: `/^\Q$k\E$/`. So key names like `day` are safe. This SHOULD cover all the possible mixups. I think it does. I'm pretty sure... All the above struggling with subtle bugs demonstrates something important. If you are testing for string equivalence, use the string equivalence operator, and not a regex. So, if I decided to implement the code with a call to `any` I'd use: `next if any { $_ eq $k } @do_not_want;` [download] TGI says moo*	[reply] [d/l]

Replies are listed 'Best First'.

Re^4: Selecting a Specific Keys in Relation to a List
by TGI (Parson) on Nov 02, 2007 at 18:33 UTC

For a small number of keys, the nested loop isn't so bad. I've been burned enough times by changing requirements that if I have two algorithms of similar complexity to code and cost to run, I'll almost always favor the one that scales better, even if the ability to scale isn't strictly necessary.

The matching regex should probably include a quotemeta as well as the start and stop anchors: /^\Q$k\E$/. So key names like day* are safe. This SHOULD cover all the possible mixups. I think it does. I'm pretty sure...

All the above struggling with subtle bugs demonstrates something important. If you are testing for string equivalence, use the string equivalence operator, and not a regex.

So, if I decided to implement the code with a call to any I'd use:

next if any { $_ eq $k } @do_not_want;
[download]

TGI says moo

[reply]
[d/l]