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
In the last 2 weeks, mainly @evo-bschiller performed a major refactoring of the whole bofire code base and also wrote this documentation. Our goal was to improve the overall structure, readability, and usability of bofire's components. Most importantly, we separated data models from functionality.
In the following, we list the most important changes:
renamed Model to Surrogate
added a common base class for all data models (bofire.data_models.base.DataModel)
moved all (pydantic) data models to bofire.data_models.<entity>
each entity is defined in its own package, e.g.: domain, kernels, features, objectives
entity subclasses are moved to their own module
each entity provides all relevant imports via api.py
moved functionality from data models of surrogates and strategies to
bofire.surrogates
bofire.strategies
all relevant imports are provided via api.py
AnyX type unions are available from bofire.data_models.api
also from bofire.data_model.<entity>.api
data models vs. functional components
All data models in bofire.data_models, are specified as pydantic models and inherit from bofire.data_models.base.BaseModel. These data models can be (de)serialized via .dict() and .json() (provided by pydantic). A json schema of each data model can be obtained using .schema().
The data models of most entities have not been changed. We only moved their definitions to the respective package in bofire.data_models.<entity>, split the class definitions into multiple modules, and added api.py.
For surrogates and strategies, we removed the functional parts from the data models and moved them to bofire.surrogates and bofire.strategies. These functionalities include the ask and tell as well as fit and predict methods. All class attributes (used by these method) are also removed from the data models. Each functional entity is initialized using the corresponding data model. As an example, consider the following data model of a RandomStrategy:
As each strategy data model should be mapped to a specific (functional) strategy, we provide such a mapping:
strategy=strategies.map(data_model)
Surrogates (formerly known as models) have been split in the same manner into data models (bofire.data_models.surrogates) and functional components (bofire.surrogates).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
BoFire - refactoring
In the last 2 weeks, mainly @evo-bschiller performed a major refactoring of the whole bofire code base and also wrote this documentation. Our goal was to improve the overall structure, readability, and usability of bofire's components. Most importantly, we separated data models from functionality.
In the following, we list the most important changes:
Model
toSurrogate
bofire.data_models.base.DataModel
)bofire.data_models.<entity>
domain
,kernels
,features
,objectives
api.py
bofire.surrogates
bofire.strategies
api.py
AnyX
type unions are available frombofire.data_models.api
bofire.data_model.<entity>.api
data models vs. functional components
All data models in
bofire.data_models
, are specified as pydantic models and inherit frombofire.data_models.base.BaseModel
. These data models can be (de)serialized via.dict()
and.json()
(provided by pydantic). A json schema of each data model can be obtained using.schema()
.The data models of most entities have not been changed. We only moved their definitions to the respective package in
bofire.data_models.<entity>
, split the class definitions into multiple modules, and addedapi.py
.For surrogates and strategies, we removed the functional parts from the data models and moved them to
bofire.surrogates
andbofire.strategies
. These functionalities include theask
andtell
as well asfit
andpredict
methods. All class attributes (used by these method) are also removed from the data models. Each functional entity is initialized using the corresponding data model. As an example, consider the following data model of aRandomStrategy
:Such a data model can be (de)serialized as follows:
Using this data model of a strategy, we can create an instance of a (functional) strategy:
As each strategy data model should be mapped to a specific (functional) strategy, we provide such a mapping:
Surrogates (formerly known as models) have been split in the same manner into data models (
bofire.data_models.surrogates
) and functional components (bofire.surrogates
).Beta Was this translation helpful? Give feedback.
All reactions