Re: Unique key identifer?

I don't really see the need or usefulness of the first file and array. Personally, on this specific case, I would use two hashes, one for the "+" values and one for the "-" values, because I do not think that a two-level data structure brings very much for this. This is my proposal:

use strict;
use warnings;

my (%plus, %minus);
while (<DATA>) {
    my ($fruit, $sign) = split;
    if ($sign eq '+') {
        $plus{$fruit} = 1;
    } else {
        $minus{$fruit} = 1;
    }
}

print "Positives are : ", (map "$_, ", keys %plus), "\n";
print "Negatives are : ", (map "$_, ", keys %minus), "\n";

__DATA__
apple    +
cherry    -
cherry    +
peach    +
banana    -
[download]

This yields the following output:

$ perl plus_minus.pl
Positives are : peach, cherry, apple,
Negatives are : banana, cherry,
[download]

As you can see, real code is about 12 lines or so.

Comment on Re: Unique key identifer? Select or Download Code

Replies are listed 'Best First'.
Re^2: Unique key identifer? by LanX (Saint) on Jun 27, 2014 at 21:44 UTC
had the same idea, but then I realized it's not much different from a HoH after writing `my %strands = ( '+' => \%plus, '-' => \%minus );` [download] as a side note, I'd prefer `print "Positives are : ", join (', ', keys %plus), "\n";` [download] instead of `map` :) Cheers Rolf (addicted to the Perl Programming Language)	[reply] [d/l] [select]
Re^3: Unique key identifer? by Laurent_R (Canon) on Jun 27, 2014 at 23:00 UTC
I agree with you and thank you, LanX, I am really not against using a HoH. But there are some cases where a HoH is really the natural data structure, and others where it is debatable. In this specific case, I would think that a HoH does not bring any algorithmic advantage (that's what I tried to show), so that using two hashes is simpler for the beginner. But I am perfectly happy with a HoH. On your second point, well, yes, maybe, the only aim was just to print the output to show the results. The `map` function is the first one that came to my mind to format the output, using `join` is also a good possibility (perhaps a bit clearer to the beginner). But this is really just a result formatting issue. In brief, as we all know, TIMOWTDI.	[reply] [d/l] [select]
Re^4: Unique key identifer? by roboticus (Chancellor) on Jun 28, 2014 at 00:21 UTC
Laurent_R: Yes, the task was too simple to really need much in the way of a data structure. I contemplated using a single hash with a string or bitmap for +/-, and also an HoA where different array slots would handle different symbols (+, -). In the end, I went with a HoH because it should be easy to understand, and didn't need any gymnastics. Two hashes works fine, too, it just didn't occur to me. ...roboticus When your only tool is a hammer, all problems look like your thumb.	[reply]
Re^4: Unique key identifer? by Jim (Curate) on Jun 29, 2014 at 04:06 UTC
I would think that a HoH does not bring any algorithmic advantage… Its advantage is that it's more space-efficient. Each unique first-level key (fruit names in lecb's example) is always stored exactly once rather than sometimes stored twice. Whether or not space efficiency is the advantage lecb is optimizing for, I can't say.	[reply]
Re^5: Unique key identifer? by Laurent_R (Canon) on Jun 29, 2014 at 15:33 UTC
Re^2: Unique key identifer? by lecb (Acolyte) on Jun 28, 2014 at 12:41 UTC
Thank you for your response. The 2 file structure is merely to mimic what I am trying to do for a more complicated program. I have to refer to another file which has for a particular "fruit", a + or -. From the information held in that file I then act on the data in the other file. My files are 44,000 lines long and created from some hefty scripting way out of my control, so needs to be kept in this structure. Will give this a go, thank you.	[reply]
Re^3: Unique key identifer? by Laurent_R (Canon) on Jun 28, 2014 at 19:10 UTC
Yeah, I also thought that your problem was probably not about apples, cherries and bananas. The reason I removed the opening and reading of the first file is that it was not useful for the problem you described, since all needed information was in the second file. I hope my suggested code still helps you, and I am sure many monks, including myself, will be glad to help you if you provide a scenario closer to your actual problem.	[reply]