Question: Transforming objective when passing `best_f` to `ProbabilityOfImprovement`, etc. about ax HOT 4 OPEN

I think we should be able to easily expose a transform_observation_data() method to make this less hacky - not sure why we haven't done this until now. @bletham is there a reason for this or just not something that was needed so far ?

from ax.

Some transforms for ObservationData require knowing ObservationFeatures. Particularly StratifiedStandardizeY, which standardizes Y but stratified on some conditions on X (https://github.com/facebook/Ax/blob/main/ax/modelbridge/transforms/stratified_standardize_y.py#L34). It is used for multi-task modeling, where data from different tasks may have very different scales and so need to be standardized separately.

This is why transform_observation_data is not a required method for a Transform to implement, and in fact StratifiedStandardizeY does not implement that and implements only transform_observations.

We could implement a transform_observation_data on the modelbridge, and it would just need to throw an error if the modelbridge has any transforms that do not implement transform_observation_data.

from ax.

HI @IanDelbridge, yes, that's correct, and your solution is as well. It's actually not that hacky at all, all things considered. Ideally, we'd have an automated way of transforming the inputs to the acquisition functions, but since with the modular setup you could have any number and kinds of those with different inputs it's not obvious how to tell what to transform.

Maybe a convenience feature could be something like adding a acq_options_to_transform argument to evaluate_acquisition_function and then apply what you're doing manually here under the hood and then pass the union of the transformed and the acq_options dict to the acquisition function? Do you think that would be a convenient API? Though that would also require distinguishing between python native and Tensor type inputs...

from ax.

Hi Max, thanks, I appreciate your response!

I think the part that sets off alarms telling me my solution is a hack is the way I am doing the transform. Is there a better way to apply the transform and inverse transforms without making fake observation features? Something like gp_pi.transform_observation_data(ObservationData(...))?

acq_options_to_transform would work from my perspective as an API but I'm also thinking about un-transforming the acquisition function value, specifically thinking about the UCB return value.

from ax.