iteration_number in PriorAcquisitionFunction()

[RoseGH20]

Description

I am using PriorAcquisitionFunction. Based on https://arxiv.org/pdf/2204.11051.pdf, the weight of the user-defined prior is decreased exponentially after each iteration/ optimization step. I noticed that the variable self._iteration_number in class PriorAcquisitionFunction is updated each time the acquisition function is used. However, because the acquisition function is not used at every step (multiple configurations are proposed after evaluating the acquisition function), self._iteration_number is lower than the actual number of function evaluations which keep the weight of the prior high. I am wondering if this is the desired behavior or if for this class, self._iteration_number should be equal to the number of evaluation rather than the number of time the acquisition function was used.

Steps/Code to Reproduce

af = PriorAcquisitionFunction(acquisition_function=EI(), decay_beta=5)
scenario = Scenario(task.configspace, n_trials=n_iters, seed= s)

intensifier = BBFacade.get_intensifier(scenario, max_config_calls=1)
smac = BBFacade(scenario, task.train, acquisition_function=af, overwrite=True, intensifier=intensifier)
incumbent = smac.optimize()

Expected Results (?)

AF evaluations (self._iteration_number=1)
X configurations proposed
AF evaluations (self._iteration_number=1+X)
Y configurations proposed
AF evaluations (self._iteration_number=1+X+Y)

Actual Results

AF evaluations (self._iteration_number=1)
X configurations proposed
AF evaluations (self._iteration_number=2)
Y configurations proposed
AF evaluations (self._iteration_number=3)

Versions

Version 2.0.2

[alexandertornede]

Hi!

Thanks for reporting this, we will be looking into it!

[LukasFehring]

Hi @RoseGH20 sorry for the late answer.
You are indeed correct, that the self.iteration_number does not get updated correctly. However, the experiments in the paper are conducted using HyperMapper and should therefore still hold.

I am currently working on a few fixes for the PriorAcquisitionFunction, and just pushed a preliminary fix to the linked MR.
Best
Lukas

[benjamc]

Closed by #1185

[LukasFehring]

I just found that the isse persists, if the local search calls the acquisition function multiple times