Closed FrederikHeber closed 6 years ago
I need to base the set of options that control sampling, optimization, ..., i.e. 'step_width' and so on, onto a solid base.
To this end, I refactor MockFlags
into a full class.
Work has begun in branch *Abstract_Options`.
Implementation is now done in the following way:
Options
where we override __getattr__
and __setattr__
to allow the user to easily access options is if they were member variables of the class, i.e. the following works.
options = Options()
print(options.step_width)
options.step_width = 0.03
options.add("step_width")
will make it known to the class. This is not necessary but enforces the programmer to be aware of adding new options.PythonOptions
contains a flock of default options, their types, and a description. This allows to use options.help("step_width")
and get a description, default value, type, and so on. Moreover, the type is checked when setting the value. Setting an unexpected type triggers an ValueError
with a informative error message.CommandlineOptions
adds additional code to convert strings into the desired type, e.g. a list of integers. For example, hidden_dimension can be specified as both "2" "2"
and "2 2"
. Both versions are converted into [2,2]
. Moreover, it adds all arguments to the argparse
parser, using the description, default value and type from PythonOptions
. I.e. this is ensured to be consistent.As this is working and Simulation_interface is merged into v0.9, I close the issue.
When using the python interface, one gets confusing error message when an option is used with the wrong type. For example, hidden_dimension needs to be a string at the moment. If we use a list of strings, we get an error message.
Python options should have clear types (similar to the ones used by the command-line interface via
argparse
) and need to admonish if the wrong type is given,