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

adding return_parameters option to Engine #62

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mattyTokenomics
Copy link

Adding optional parameter return_parameters which returns the parameters used in each run within the experiment results output.

Defaults to False.

This feature saves time, reduces complexity, and avoids the risk of error when requiring users to manually construct a map of which parameters correspond to each run after the fact.

Adding optional parameter `return_parameters` which returns each the parameters used in each run within the experiment results output.

Defaults to False.

This feature saves time, reduces complexity, and avoids the risk of error when requiring users to manually construct a map of which parameters correspond to each run after the fact.
@@ -164,6 +167,8 @@ def _single_run_wrapper(args):
if raise_exceptions and exception:
raise exception
else:
if run_args.return_parameters:
[substep.update(run_args.parameters) for timestep in results for substep in timestep]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One issue we might face including all parameters in the simulation results is that typically not all parameters are basic Python types, serialisable, or able to be stored in Pandas DataFrames efficiently.

As an alternative we do currently have access to each subset's parameters in the before_subset() and after_subset() hooks, should a user want to get access to these before or after a specific set of parameters is used in a simulation.

I understand the use case of storing parameters in the simulation results and having them end up in a DataFrame though - I have done this in the past for a subset of the parameters that are useful to have in post-processing and maybe additionally are basic Python types.

Let me sleep on this and see if there are other ways of implementing, open to ideas too :)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I 100% agree with the benefits of such a feature:

This feature saves time, reduces complexity, and avoids the risk of error when requiring users to manually construct a map of which parameters correspond to each run after the fact.

Copy link
Author

@mattyTokenomics mattyTokenomics Feb 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point about complex data types for params. Given all params are specified as values in a dict though, I believe it should cover every case to output a dict with keys corresponding to run # and subset # and a value of a dict of params:
{ run_i: {subset_j: {param_x: value_x }, subset_j+1: {param_x: value_x }} }

This approach would need to make experiment.run() return both the run results and the params dict at well. ie:
results, params = experiment.run()

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

Successfully merging this pull request may close these issues.

2 participants