Re: set partition question

[pball.benetech]

On May 25, 7:46*pm, [e-mail] wrote:

I think this problem is related to integer partitioning, but it's not

<snip>

>
If, by "integer partitioning," you mean the "subset sum
problem" (given a finite set S of integers, does S contain a subset
which sums up to some given integer k?), then you are right. *I'm
reasonably sure there's a polynomial reduction from your problem to
the subset sum problem. *That would make your problem NP-complete.

Wow, that's helpful. http://en.wikipedia.org/wiki/Subset_sum clarifies
what I'm trying to do. Yes, it probably is NP-complete. Fortunately my
use case doesn't require that the process finish, just that it produce
a lot. I can exclude trivial cases (e.g., f' = f(S) + s_1 - s_1) with
some sort of simplifier.

Like I said, because this looks related to the subset sum problem
(though harder, because you're asking for "all" such functions, for
some rigorous definition of "all," as per the previous sentence), I
suspect it's NP-complete. *However, there are probably some good
heuristics, such as if s1 has a large intersection with s0, it's
probably a good idea to use s1 in whatever formula you come up with.

There are a few real-world constraints which make the problem easier,
but only by linear factors, I suspect. More on this below.

Other than that, I don't really have an idea. *Can you say what the
application of this algorithm would be? *Knowing the use case might
suggest a better approach.

This is a problem in statistical estimation. Given n records made up
of k variables, define a cell as the point in the cartesian product of
v_1 * v_2 * ... * v_k. I want to apply an estimator on the data in
each cell.

However, many cells are empty, and others are too sparse to support
estimation. One solution is to build lots of valid aggregations,
called "strata," for which estimates can be made for chunks of cells.
A "valid aggregation" is a sequence of *adjacent* cells (see below)
whose data are pooled (by whatever mechanism is relevant to the
estimator).

The cells are "elements" in my initial problem statement, and the
strata are the sets.

The constraints I mentioned are on the composition of strata: strata
can only contain sequences of adjacent cells, where adjacency is
defined for each variable. Two cells are adjacent if they are equal on
every variable except one, and on that one and by its definition, they
are adjacent.

Does this make it easier to understand, or more difficult? thanks --
PB.

[miller.paul.w]

On May 25, 11:40*pm, [e-mail] wrote:

This is a problem in statistical estimation. Given n records made up
of k variables, define a cell as the point in the cartesian product of
v_1 * v_2 * ... * v_k. I want to apply an estimator on the data in
each cell.

So, basically, V = (v_1, v_2, ... , v_{k-1}, v_k) can be regarded as
an abstract, k-dimensional vector, right?

If I understand your revised problem statement correctly, what you
really want to do is build a graph of these vectors, where graph
adjacency is equivalent to adjacency in your sense. That is, imagine
you have V_1, V_2, ... , V_n all sitting out in front of you,
represented abstractly as simple points. Draw a line between V_i and
V_j if they are "adjacent" in your sense of the word. What you have
then is a graph structure where your version of adjacency exactly
corresponds to graph adjacency. Then, in your language, a stratum is
simply a path in this graph, and finding those is easy.

That is, unless I've got this all wrong. :-)

[pball.benetech]

On May 25, 10:41*pm, [e-mail] wrote:

So, basically, V = (v_1, v_2, ... , v_{k-1}, v_k) can be regarded as
an abstract, k-dimensional vector, right?

Yes.

If I understand your revised problem statement correctly, what you
really want to do is build a graph of these vectors, where graph
adjacency is equivalent to adjacency in your sense. *That is, imagine
you have V_1, V_2, ... , V_n all sitting out in front of you,
represented abstractly as simple points. *Draw a line between V_i and
V_j if they are "adjacent" in your sense of the word. *What you have
then is a graph structure where your version of adjacency exactly
corresponds to graph adjacency. *Then, in your language, a stratum is
simply a path in this graph, and finding those is easy.

You're solving an earlier part of the problem which I call stratum
generation. I've never thought to use a graph representation for
stratum generation -- very interesting, and I'll pursue it. Would you
be willing to outline how you'd do it here?

I've had fun "breeding" strata using genetic algorithms, and a lot of
interesting ideas came out of that experiment, in particular the
utility of building randomly shaped strata to do indirect estimates
(the objective of the set arithmetic described here). I used GA's
because I think that the space of possible strata is too big to search
by brute force.

I'd still like to have the graph representation for the brute force
solution. Or, in another random algorithm, the graph could be a
sampling frame from which random paths could be pulled.

In a real dataset, some of the strata will contain adequate data to
make an estimate, and these are called valid strata. Other legal
strata (as shown by a path through the graph) may not have adequate
data to make an estimate (thus, legal but invalid).

We've done this problem by hand: observing that we can estimate a
stratum (1,2,3) and another (2,3) but not (1). So
E(1) = E(1,2,3) - E(2,3)
There are issues with the variance of E(1), but that's a very
different problem. Using the valid strata E(1,2,3) and E(2,3) we've
made an indirect estimate of E(1).

I'm looking for an algorithm which automates the search for
combinations like the one above. Given a set of valid strata[1], yield
combinations of valid strata which, when combined via union or
difference[2], evaluate to a stratum (adjacent but possibly not
valid). The combination of valid strata is called an indirect
estimate

[1] strata can be generated via many methods; they all end up in the
same database
[2] Note that the set of operations is shrinking :)

Thanks in advance for your thoughts -- PB.