[FEATURE REQUEST]: RangeParameter handling periodic variables (such as angles)

[EtorArza]

Motivation

Greetings,

I am using bayesian optimization with Ax for a project where we are trying to optimize the shape of flying drones. All of the parameters I am optimizing are continuous, but some of the parameters are angles. The range of these angle parameters is [0,2pi] where 0 an 2pi are equivalent. This also implies that going from 2pi - epsilon to 0+epsilon should be a small change of 2 epsilon, instead of a large change of 2pi - 2epsilon that it is currently.

As far as I understand, there is no way to account for this with the current implementation of Ax cannot account for this. Moreover, I am getting solutions like

0.000, 0.229, 0.255, 6.283, 6.258, 0.213, 0.532, 0.863, 0.63, 6.283, 0.750, 0.571, 0.342, 0.00, 0.352, 0.110, 0.647, 0.725

with many values close to 2pi and 0.0.

Describe the solution you'd like to see implemented in Ax.

It would be nice if Ax could take into account periodic variables like this, such that 0 and 2pi are the same instead of far away.

Describe any alternatives you've considered to the above solution.

Currently, a workaround I can think of is using the interval [-pi, 3pi] such that the whole range can be used in the optimization without any discontinuities. However, this is not ideal since it adds duplicate solutions. Note however, that the optimization is still working, even without this workaround, but this would be a nice enhancement.

Is this related to an existing issue in Ax or another repository? If so please include links to those Issues here.

I looked at the issues with Ax and I was not able to find anything similar to this. It might require changing the underlying BO Torch package used by Ax, but I am not knowledgeable enough to know that for sure.

Code of Conduct

• I agree to follow Ax's Code of Conduct

[Balandat]

Thanks for raising this issue.

I am getting solutions [...] with many values close to 2pi and 0.0.

This is caused by the model having larger uncertainty at the "boundary" and I agree that this is suboptimal behavior.

As you said the proper way to do this would be to use a custom kernel that is periodic in the angle parameters in the underlying BoTorch model. We don't have out-of-the-box support for this right now, but it's something we could potentially consider in the longer term (this would involve some nontrivial engineering effort piping everything through properly).

cc @sdaulton who has used a custom setup for periodic contextual features in (non-OSS) Ax for any thoughts.

cc @mpolson64 re considerations for Parameter types

[Balandat]

cc @SebastianAment