Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change acquisition function builders to be functions #137

Closed
joelberkeley opened this issue Feb 7, 2021 · 1 comment
Closed

Change acquisition function builders to be functions #137

joelberkeley opened this issue Feb 7, 2021 · 1 comment
Labels
enhancement New feature or request

Comments

@joelberkeley
Copy link
Contributor

joelberkeley commented Feb 7, 2021

As a maintainer/user, I want the acquisition function builders to be lightweight: easy to compose, construct and generally manipulate, so that code is easier to read, conceptualise and extend.

To this end, I propose changing the acquisition function builders to be functions not classes. For example:

AcquisitionFunctionBuilder = Callable[
    [Mapping[str, Dataset], Mapping[str, ProbabilisticModel]], AcquisitionFunction
]


def expected_improvement(
    data: Mapping[str, Dataset], models: Mapping[str, ProbabilisticModel]
) -> AcquisitionFunction:
    ...

If it's not clear to users what is and isn't an acquisition function builder by its signature, we could either take care to say what is an AcquisitionFunctionBuilder in the docstring for each one, or do the following workaround:

def _expected_improvement(
    data: Mapping[str, Dataset], models: Mapping[str, ProbabilisticModel]
) -> AcquisitionFunction:
    ...

expected_improvement: Final[AcquisitionFunctionBuilder] = _expected_improvement

This would obviously not be needed for e.g.

def probability_of_feasbility(threshold: TensorType) -> AcquisitionFunctionBuilder:
    ...

which returns a builder, rather than is one. It appears this would show up clearly in the docs. It may also be clearer to put everything on the same footing and have them all return builders:

def expected_improvement() -> AcquisitionFunctionBuilder:
@joelberkeley joelberkeley added the enhancement New feature or request label Feb 7, 2021
@uri-granta
Copy link
Collaborator

This is no longer plausible as AcquisitionFunctionBuilder now also includes the logic for updating functions without retracing. (In fact, it's likely that a better solution would have been to remove AcquisitionFunctionBuilders altogether and just use an AcquisitionFunction class that handles updates itself, but at this point this looks like far too much work: #650.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants