Re^2: Unique key identifer?

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)

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

Replies are listed 'Best First'.
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
Its advantage is that it's more space-efficient. Yes, probably, but probably also less time efficient because of double indirection. (If that matters.)	[reply]