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

[Feat] Save/load models to/from file #129

Closed
quantum9Innovation opened this issue Dec 29, 2021 · 2 comments
Closed

[Feat] Save/load models to/from file #129

quantum9Innovation opened this issue Dec 29, 2021 · 2 comments
Labels
feat 🚀 New feature or request low-priority 🔽 Will be worked on later
Milestone

Comments

@quantum9Innovation
Copy link
Member

quantum9Innovation commented Dec 29, 2021

Is your feature request related to a problem? Please describe.
There is no problem directly related to this feature request, though it would solve issues relating to model reproduciblity, which will prove especially useful in research.

Describe the solution you'd like
Two functions, each of which compile an epispot model object into a file (JSON would probably be best, though any object-oriented file type like YAML/TOML could theoretically work). For certain abstract elements related to the models, (e.g. parameters defined as functions) values could be linked to names or special codes which could be interpreted later with the help of a dictionary. With this dictionary, the reader function would be able to read from the file and recreate the model in its original form, solving the problem of reproducibility and drastically lowering the file size required to do so.

Describe alternatives you've considered
There are, of course, multiple alternatives to solving the reproducibility issue, outlined below:

(1) Copying code: While this works, it's inefficient, occasionally hard to read (as it can be clouded with unnecessary functions and scripts), and involves large file sizes for a problem that can be solved more cleanly by other means.

(2) Saving model outputs: This is perhaps the most obvious solution, but it prevents researchers from actually inspecting the models producing the results and only shows part of the larger picture.

(3) Compiling the model to lower-level code ⁉️: Very efficient, but almost certainly unreadable. Why would we ever want to do this??

Additional context
It would be nice to ship this with epispot v3b, but the current situation makes that look unlikely. Regardless, @Quantalabs will head development until this enters nightly (or, if we're lucky, beta) testing.

@quantum9Innovation quantum9Innovation added this to the v3.0.0-beta milestone Dec 29, 2021
@quantum9Innovation quantum9Innovation added this to In progress in Development v2 Dec 29, 2021
@quantum9Innovation quantum9Innovation added feat 🚀 New feature or request low-priority 🔽 Will be worked on later labels Dec 29, 2021
@Quantalabs
Copy link
Member

/available (LGTM!)

@github-actions
Copy link

This issue is open for contributions.
Claim this issue with "/claim" (without the quotes).

quantum9Innovation added a commit to epispot/epispot-transition-v3 that referenced this issue Jul 25, 2022
See #129 (epispot/epispot#129) for more information.

Actual process uses `dill` to serialize Python objects.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat 🚀 New feature or request low-priority 🔽 Will be worked on later
Projects
No open projects
Development v2
  
In progress
Development

No branches or pull requests

2 participants