Unify acquisition rules and function builders #213
joelberkeley
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
WORK IN PROGRESS
see also #136 #137 #91
Here I propose to unify and generalise the acquisition rules and acquisition function builders, reduce boilerplate, and provide a number of utilities which cast the acquisition optimizers and acquisition function reducers as or with standard design patterns.
Let's start with where we are right now. An acquisition rule is defined by
and an acquisition function builder by
There are three differences between these two signatures
a) the
AcquisitionRule
accepts a search spaceb) the
AcquisitionRule
has a notion of statec) the
AcquisitionFunctionBuilder
produces aAcquisitionFunction
while theAcquisitionRule
produces aTensorType
The first two may need changing. For a) ... For b) we can either: note that
TrustRegion
is the only rule that uses state, and remove the state from the acquisition rule by making the process of generating an acquisition space a seperate step to acquiring a new point; or we can make theAcquisitionFunctionBuilder
stateful, which would allow optimizations such as passing the Pareto set between steps, thus avoiding the need to recompute all of it on each step.For the third, we can parametrize over the return type. For illustration, we'll look at the simple stateless case where nothing receives the search space. Here, we can use the interface
An
AcquisitionRule
is then aCallable[[SP_contra], Step[TensorType]]
and a function builder is aStep[AcquisitionFunction]
.We'll take a look at representation.
Step
is an interface with one method, and most if not all implementations also only have one method, so common design approaches suggest this should be a functionOne benefit of this is that defining a function requires less boilerplate than implementing an
ABC
. The other is that it encourages composition over inheritance.We'll now turn to combinators over
Step
. These utilities provide natural, yet abstract and powerful tools for working with the values produced by these objects, marked above by typeT
. Between them, they would comprise most of the architecture of trieste. First, we canmap
overStep
s,with which we can define an acquisition rule as
We also get other things for free with
map
, such as modifying the acquisition function that would be produced by a builder before it's builtSecond, we can define
reduce
:===============================
First, we can
map2
(from Applicative) overStep
s, which takes aStep
producing aT
and another producing aU
, and using an appropriate function, produce aStep
producing aV
, aswith which we can define an acquisition rule in terms of the trust region algorithm, the acquisition function builder and an optimizer
Note this isn't Python's built-in
map
, but an example of the more general concept:Beta Was this translation helpful? Give feedback.
All reactions