-
Notifications
You must be signed in to change notification settings - Fork 26
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
Feature Request: A congruent settings interface #47
Comments
appetrosyan
changed the title
Consistent settings interface
Feature Request: A congruent settings interface
Jun 2, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now there are no reasons why the settings file couldn't be a dictionary, so we can either extend the functionality of the settings file, or phase it out and move the logic into the function that actually uses it.
**Proposal 1: **
Add functions that load the settings file from other formats, allow serialising and de-serialising in a consistent manner, as well as adding the option to add the prior quantile or the log-likelihood at the stage of creating the settings object.
Pros:
nDims
long vector + return a tuple where necessary. Effectively, we prevent the end user from spending too much time debugging.Cons:
It's bloat.
Proposal 2:
Remove the settings object entirely. Instead, provide all the validation as part of keyword arguments of the
run_polychord
method. The settings object essentially reduces to a dictionary.Pros:
run_polychord()
andsettings
.run_polychord()
.Cons:
Duplicated error checking. More code in the
run_polychord()
function.The text was updated successfully, but these errors were encountered: