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:
More functionality -- we only add new features.
If using proper OOP, should either make settings immutable, or provide proper setters that run whenever the functions are updated, rather than only once.
We could also test if the prior quantile / likelihood misbehave, early: could see if they accept an 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:
Simpler procedural interface.
No state to worry about and minimal runs remain minimal.
Much easier to document.
No chance of providing incongruent configuration to run_polychord() and settings.
Can do without breaking backwards compatibility, by simply allowing all elements of the settings object to be passed to run_polychord().
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:
nDimslong 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_polychordmethod. 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.