-
Notifications
You must be signed in to change notification settings - Fork 4
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
Refactor to enable different models to be run with the same importance_sampling code? #3
Comments
Looks like there are other pieces of code that need refactoring in the same way, eg |
@drphilmarshall Passing in a custom |
I wanted some input on the structure of the code. I have a python code that contains all the information for the current two models. It creates a class for each type of population. Within each class it:
**Any preference on naming scheme? I currently implemented one that tacks on a two letter description of the population plus the number of SNe in the model "testdata_SP_200" for Single Population with 200 total SNe
How do you want the gen_dataset, sample_lcs (for naming only), importance_sampling, plot_global to handle having multiple choices? I'm curious what kind of interface is most useful right now. There are a few options.
|
In answer to your last question: I usually keep classes and functions in separate files, with matching
Then, you can turn this into an importable module by
and editing this file so that it contains a list of import statements like:
When you do an
from python, you then get access to all the classes and functions in all
(if ImportanceSampler was a class defined in importance_sampler.py) Most of my python repos have this structure, if you want to browse around. On Tue, Feb 10, 2015 at 4:58 PM, Kara Ponder notifications@github.com
|
I would probably just go with the third option: setting a few parameters at the top of the main script. It's not a permanent solution, but that's OK: this is still just a sandbox! The naming scheme for directories sounds fine. When you feel like it, throw you code up on github and we can comment in a bit more detail on particulars, before merging. One of the nice things about github is that you can update a previously created Pull Request in response to comments, simply by making more commits on your branch, and pushing the branch to github again. |
BTW, @rbiswas4 and I discussed a more permanent API (that might go into sncosmo) yesterday here in Berkeley. We ran into a difficulty that I'll describe in a separate Issue. |
Looks like the
lnlike
function inimportance_sampling.py
could be refactored to call out to one of any number (currently two) model's likelihoods. Let's do this refactoring so that we can explore different model choices without changing the wayemcee
is called at the hyper level. @kponder could do this safely from her MultiPop branch, before merging to her master and submitting a pull request.The nice thing about this scheme is that then we will be able to define models by PGMs, and then implement them as single separated likelihood functions.
The text was updated successfully, but these errors were encountered: