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

Implement randomization strategies for iterative gapfilling #25

Open
gregmedlock opened this issue Dec 14, 2018 · 0 comments
Open

Implement randomization strategies for iterative gapfilling #25

gregmedlock opened this issue Dec 14, 2018 · 0 comments

Comments

@gregmedlock
Copy link
Member

gregmedlock commented Dec 14, 2018

Users should be able to tune the bias/variance of an ensemble during iterative gapfilling. For example, the current implementation exhaustively gapfills on all positive growth media conditions. We suspect that this leads to greater convergence in model structure than if only a fraction of media condition were used for each member (e.g. a random 70% of conditions).

To solve this issue, we should add an argument for selecting a randomized fraction for each ensemble member (e.g. random_fraction = True will lead the the stated behavior above), and an argument to specify the fraction of conditions used (e.g. fraction_conditions = 1.0 to include all conditions). The default behavior will be the behavior of the existing implementation, where all media conditions are used for each member. If random_fraction = False, fraction_conditions must be equal to 1.0. In order to gapfill to fewer conditions for the entire ensemble, users should just pass a smaller set of conditions.

Alongside this enhancement, there should be an additional argument to return a dictionary log that indicates the gapfill history for each member of the ensemble. The dictionary could have the structure {member.id:{reaction.id:[ordered list of medium dictionaries]}}, where reaction.id is for the reaction representing the former objective that was fixed as a constraint. This behavior might need to be altered in the future to include more complex fixed constraints.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant