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

Refactoring run for additional flexibility #40

Open
psteinb opened this issue Dec 21, 2021 · 1 comment · May be fixed by #42
Open

Refactoring run for additional flexibility #40

psteinb opened this issue Dec 21, 2021 · 1 comment · May be fixed by #42
Labels
enhancement New feature or request

Comments

@psteinb
Copy link
Contributor

psteinb commented Dec 21, 2021

Not sure I am overseeing something, but the run methods in the algorithms only return the predicted samples - nothing else.

It might be worthwhile to consider refactoring this, so that each python module in the algorithms directory offers to return the obtained posterior. This would entail in pseudo code:

def train(...):
	return trained_objects

def infer(...)
	return predicted_objects

def run(...):
	trained_objects = train(...)
	predicted_objects = infer(trained_objects, ...)
	return predicted_objects

This refactoring should/would not change the API which is used downstream. It would however allow more analyses on the obtained posterior (mean/median map estimation versus SGD based map estimation etc).

@jan-matthis
Copy link
Contributor

Thanks for the suggestion, Peter!

I agree that for additional analyses, it might be useful to be able to access the "trained object" (currently, depending on the algorithm, there is one trained object, or none, e.g., for some ABC methods). run does return not only predictive samples, but also the number of simulations that were actually performed (simulator.num_simulations; as a safety-check), and, if the algorithm supports it, the log probability of true parameters as an optional third return.

If you are up for it, I'd be glad to accept a PR that refactors the functions along the lines you propose and continue discussing there :)

@jan-matthis jan-matthis changed the title splitting the run methods of algorithms Refactoring run for additional flexibility Jan 3, 2022
@jan-matthis jan-matthis added the enhancement New feature or request label Jan 3, 2022
@psteinb psteinb linked a pull request Jan 5, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

Successfully merging a pull request may close this issue.

2 participants