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!