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

Reduce code duplication #6

Open
FractalArt opened this issue Aug 28, 2020 · 1 comment
Open

Reduce code duplication #6

FractalArt opened this issue Aug 28, 2020 · 1 comment
Assignees
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@FractalArt
Copy link
Collaborator

There is a lot of duplicated code in the functions integrators::plain::integrate() and integrators::plain::resume_integration_from_checkpoints() that could potentially be reduced by factoring out the main skeleton in a helper function.

@FractalArt FractalArt added enhancement New feature or request good first issue Good for newcomers labels Aug 28, 2020
@FractalArt FractalArt self-assigned this Aug 28, 2020
@FractalArt
Copy link
Collaborator Author

I was wondering whether it would make sense to convert the integration functions to trait methods on a PlainIntegrator struct (implementing a new trait Integrator) that would hold a random number generator self.rng and a vector of checkpoints self.checkpoints.

This way, it could have additional trait methods from_rng and from_checkpoints, where the first method would construct a new integrator by providing a random number generator and initializing the checkpoints vector to an empty vector. The second method would construct a new integrator from a set of checkpoints, storing them in self.checkpoints and using the rng_after of the last checkpoint as self.rng. The struct could then have a private method that takes care of the integration which in turn is called by the methods of the Integrator trait integrate and resume_from_checkpoints (to reduce code duplication).

Another good point about this would be that there could be another Integrator-trait method store_checkpoints_to_file() which, when called would set a struct member checkpoint_file: Option<File> that would then trigger to store the checkpoints in the file when the integrator goes out of scope. I think this is more secure and robust than doing this manually in the code. If the method is not called, we have self.checkpoint_file == None and no checkpoints are stored upon dropping.

On the other hand, since checkpoint files are somewhat related to presenting examples, I was wondering whether maybe they should be part of a dedicated callback function.

@FractalArt FractalArt added this to the Plain Integrator Support milestone Aug 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

1 participant