Dual look-up on keys?

[castironpi at gmail.com]

On Mar 6, 5:16 am, Bryan Olson <fakeaddr... at nowhere.org> wrote:
> castiro... at gmail.com wrote:
> > Bryan Olson wrote:
> >> How can we efficiently implement an abstract data type, call it
> >> 'DoubleDict', where the state of a DoubleDict is a binary
> >> relation, that is, a set of pairs (x, y); and the operations on
> >> a DoubleDict are those on a Python set, plus:
>
> >>      find_by_first(self, x):  return [y where (x, y) in DoubleDict]
>
> >>      find_by_second(self, y):  return [x where (x, y) in DoubleDict]
> > It gets hairier if you have an element that isn't a first or second
> > necessarily.
>
> >       find_by_other(self, x): return [y where (x, y) in DoubleDict or
> > (y, x) in DoubleDict]
>
> Do you need all three find_by's, or are the pairs actually
> unordered, so you just need to find partners? Are the relations
> many-to-many, and if so do you want duplicates removed?
>
> As programming exercises, the variants are all reasonable and
> possibly interesting. I was just trying to answer the call to
> nail down the problem statement.

You've helped me nail down the problem in my post.  It was that I was
trying to ask two questions at once.  (He had at -least- one
question!).  The first was from an old piece of code I wrote that
simply wanted to know what the object that's storing the combination
of A and B was, so frozenset([A,B]) works perfectly, and I'm satisfied
as for that one.

But the second one, which was interefering with my own thoughts, was
another one.

The company was selling multiple products at multiple sites.
Softdrink A at store 1, softdrink B at store 1, softdrink B at store
2.  My 'add' operation, 'say store N sold softdrink S' always had two
lines and I really hated it.  It worked, of course, but still.  I felt
like it was a stain.

I was asking if anyone knows how to tie it, but it was kind of
intimidating seeing how the implementation worked already.

> Do you need all three find_by's, or are the pairs actually
> unordered, so you just need to find partners? Are the relations
> many-to-many, and if so do you want duplicates removed?

The first one was, find the information I already have about a
partnership.

> As programming exercises, the variants are all reasonable and
> possibly interesting. I was just trying to answer the call to
> nail down the problem statement.

Which is now something I can do.

Actually, there's another data structure I was working on (a year ago
now) that's tangentially related, so if you guys want me to hold off
on that one til you or I is satisfied on the company-product map, I
will!  Otherwise, I'll just post it here and leave it to you.
(Knowing myself, something tells me I'll try to formulate it later on
today regardless.  Heh heh heh.  If that's not the most virtuous way
to ask for help, then I might have inherited from TroubleMaker at some
point up the line.)