Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Seed methods #299

Closed
maxhully opened this issue Apr 11, 2019 · 4 comments
Closed

Seed methods #299

maxhully opened this issue Apr 11, 2019 · 4 comments

Comments

@maxhully
Copy link
Contributor

We have a bunch of seed methods sitting in #248 that we should clean up, merge in, and document. But we'll also want to think about how we can present those methods in the clearest, most responsible manner.

@drdeford
Copy link
Member

drdeford commented May 9, 2019

Basic outlines of the current versions: https://www.overleaf.com/read/zpmyzqmpvmnx plus some additional code for context: https://github.com/drdeford/Tree_Partitions_Preliminary

@drdeford
Copy link
Member

drdeford commented May 9, 2019

This also fits into #296 as the construction of new seeds sits somewhere in between chain runs, data processing, and implementation details.

  • Do we include seed building in GerryChain? (The underlying graph and data objects are the same + you can use any such method as an i.i.d. proposal)

  • Is it closer to MAUP style preprocessing? (Could be a separate project taking that just also happens to make use of make graph)

  • Should we offer the opportunity to generate a new seed every time you generate an ensemble? (I've used this approach on some states)

@maxhully
Copy link
Contributor Author

maxhully commented May 9, 2019

I'm intrigued by the idea of making it a separate project. That would make it easier to include additional seed methods without having to worry about putting too many things in GerryChain.

Being able to generate a new seed every time you generate an ensemble would be useful. I suppose MarkovChain could optionally take a seed method as a parameter instead of an initial plan? Figuring out a standard interface for seed methods (and bipartitioning methods) would be helpful, although probably impossible.

Here's an idea I had about the bipartitioning methods. Suppose we make our constraints into callable classes instead of functions, looking something like this:

>>> pop_constraint = PopulationConstraint("TOTPOP", ideal=1250, epsilon=0.05)
>>> pop_constraint(initial_partition)
True

Then maybe we could standardize the bipartitioning methods to always be callables with the signature (graph, population constraint) -> partition?

Independent of this specific example, I think it would be good to explore using callable objects for the situations where we find ourselves using partial.

@drdeford
Copy link
Member

Now a week 6 project for vrdi 2019.

@pjrule pjrule closed this as completed Feb 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants