in reply to Re^2: Unique key identifer?
in thread Unique key identifer?

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.

Replies are listed 'Best First'.
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.

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.

      Its advantage is that it's more space-efficient.

      Yes, probably, but probably also less time efficient because of double indirection. (If that matters.)