You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment we've got a class TunableMethod that samplers and optimisers and anything else can implement, that provides two methods:
n_hyper_parameters -> int
set_hyper_parameters(x)
where x is an array of scalars. This is really useful as it means you can treat the hyper parameters as a 1d vector of parameters to optimise, and @martinjrobins has been doing this in performance testing.
Here, it'd be really good if we could pass in an extra argument after n_warmup that would be e.g. an array of hyperparameters.
The internal code would then (1) figure out if it's a single or multi-chain method, (2) call set_hyperparameters on each.
Solved!
But it does mean that
you need to remember the order the hyperparameters are in, when writing the test; and
you need to set each hyperparameter, even the ones that are always some magic number (e.g. 7 in bfgs)
So I was thinking it'd be good to have a set_hyperparameters that takes a dictionary, or named arguments, as input. That way the code above could be e.g.
(which would work via arbitrary keyword args: def set_hyper_parameters(**kwargs) gets kwargs as a dictionary)
Proposal 1
We update tunable method to:
def set_hyper_parameter_array(self, x):
"""
Sets the hyper-parameters for the method with the given vector of
values (see :class:`TunableMethod`).
Parameters
----------
x
An array of length ``n_hyper_parameters`` used to set the
hyper-parameters.
"""
pass
def set_hyper_parameters(self, **kwargs):
"""
Sets the hyper-parameters for the method using keyword
arguments (see :class:`TunableMethod`).
Examples::
tunable_method.set_hyper_parameters(x=3, y=4)
parameters = {'x': 3}
tunable_method.set_hyper_parameters(**parameters)
The hyper-parameters that can be set depend on the class implementing
:class:`TunableMethod`. Setting hyper-parameters that do not exist will
result in a ``ValueError`` being raised.
"""
pass
Proposal 2
Slightly more confusing, but perhaps better
def set_hyper_parameter(self, _array=None, **kwargs):
"""
Sets the hyper-parameters for the method with a given vector of
values or keyword arguments (see :class:`TunableMethod`).
Parameters
----------
_array
An optional array of length ``n_hyper_parameters`` used to set the
hyper-parameters.
**
Optional keyword arguments to set specific hyper-parameters. (If both
a vector an keyword arguments are given, the array arguments will be
set first, and then overwritten by the keyword arguments).
Examples::
tunable_method.set_hyper_parameters([3, 4])
tunable_method.set_hyper_parameters(x=3, y=4)
parameters = {'x': 3}
tunable_method.set_hyper_parameters(**parameters)
The hyper-parameters that can be set depend on the class implementing
:class:`TunableMethod`. Setting hyper-parameters that do not exist will
result in a ``ValueError`` being raised.
"""
pass
Further changes
The controller would get some extra method set_hyper_parameters(**kwargs) that gets kwargs as a dict, it can then just pass this on to the appropriate sampler or samplers via sampler.set_hyper_parameters(**kwargs) (where the ** unpacks the dict into keyword arguments again).
Similarly, the functional tests would get a constructor argument hyper_parameters that they could then pass to the controller using controller.set_hyper_parameters(**hyper_parameters)
The text was updated successfully, but these errors were encountered:
At the moment we've got a class TunableMethod that samplers and optimisers and anything else can implement, that provides two methods:
where
x
is an array of scalars. This is really useful as it means you can treat the hyper parameters as a 1d vector of parameters to optimise, and @martinjrobins has been doing this in performance testing.For functional testing, @fcooper8472 has proposed something like this:
Here, it'd be really good if we could pass in an extra argument after
n_warmup
that would be e.g. an array of hyperparameters.The internal code would then (1) figure out if it's a single or multi-chain method, (2) call set_hyperparameters on each.
Solved!
But it does mean that
So I was thinking it'd be good to have a
set_hyperparameters
that takes a dictionary, or named arguments, as input. That way the code above could be e.g.or
for a particularly nasty problem.
Seems to me this will be much easier to use?
An additional bonus would be that we solve @ben18785 's (justified) annoyance with setting hyperparameters on a controller.
Instead of
we could do
and
(which would work via arbitrary keyword args:
def set_hyper_parameters(**kwargs)
gets kwargs as a dictionary)Proposal 1
We update tunable method to:
Proposal 2
Slightly more confusing, but perhaps better
Further changes
The controller would get some extra method
set_hyper_parameters(**kwargs)
that getskwargs
as a dict, it can then just pass this on to the appropriate sampler or samplers viasampler.set_hyper_parameters(**kwargs)
(where the**
unpacks the dict into keyword arguments again).Similarly, the functional tests would get a constructor argument
hyper_parameters
that they could then pass to the controller usingcontroller.set_hyper_parameters(**hyper_parameters)
The text was updated successfully, but these errors were encountered: