Probabilistic Reparameterization Part 2

[TobyBoyne]

Motivation

Probabilistic Reparameterization is a technique for optimizing mixed feature spaces, proposed in [1]. There is an existing pull request (#1533), which requires resolving merge conflicts, and writing tests. This PR continues that work.

[1] Samuel Daulton et al. Bayesian Optimization over Discrete and Mixed Spaces via Probabilistic Reparameterization, NeurIPS '22

Have you read the Contributing Guidelines on pull requests?

Yes

Test Plan

I have currently written tests that optimize the acquisition function. I will also write more fine grained tests: specifically, testing the structure of the chained transforms generated in factory.py, and testing the new transforms.

Related PRs

This continues the work in #1533. The tutorial is in #1534, which also would need updating.

[TobyBoyne]

Currently, the test comparing the Analytic vs MC methods for PR do not give the same (or close to the same) results, which doesn't seem correct to me. I will keep investigating, I imagine it is an issue with my code since the results in the paper seem to be fairly consistent between Analytic and MC (it seems to be that the Analytic approach is giving 0 acqf value everywhere). If anyone does spot any mistakes, please let me know!

For reference, the MC method in this test does give similar results to completely enumerating the mixed features.

[esantorella]

cc @sdaulton

[eytan]

Great to see you picking this up @TobyBoyne—thanks so much for your contributions to the project!

It'll be cool to see PR working with BARK—seems like a natural way to get around using MIP and a good use of those MCMC samples!

[TobyBoyne]

Some questions I've found while working on this:

1. I have included the tests for the *PRInputTransform with the other PR tests. Should they be moved to test/models/transform/input.py? Similarly, should these transforms even be with the other InputTransforms, since they are highly specific to PR?
2. Flexibility in dimension position - we currently assume/enforce that the dimensions are ordered continuous->discrete->categorical. Should this be relaxed, or is it okay to leave for the sake of cleaner code?
3. Flexibility in encoding - PR currently only supports one-hot encoding for categoricals. In Support categoricals in alternating optimization #2866, I assumed that categoricals were encoded ordinally. Is there a canonical/preferred encoding for categoricals? Should both be supported?

[TobyBoyne]

Analytic vs MC methods for PR do not give the same (or close to the same) results

For anyone interested, this was due to PR implicitly assuming that integer idxs are in the rightmost columns (after continuous), whereas the MixedAckley benchmark places them in the leftmost columns.

[codecov]

Codecov Report

Attention: Patch coverage is 89.61353% with 43 lines in your changes missing coverage. Please review.

Project coverage is 99.78%. Comparing base (13444be) to head (5a1b0fc).
Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
...ch/acquisition/probabilistic_reparameterization.py	80.32%	36 Missing ⚠️
botorch/models/transforms/input.py	95.90%	7 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##              main    #2882      +/-   ##
===========================================
- Coverage   100.00%   99.78%   -0.22%     
===========================================
  Files          211      213       +2     
  Lines        19512    19956     +444     
===========================================
+ Hits         19512    19913     +401     
- Misses           0       43      +43     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[sdaulton]

I have included the tests for the *PRInputTransform with the other PR tests. Should they be moved to test/models/transform/input.py?

It seems fine to leave them with the other PR tests.

Similarly, should these transforms even be with the other InputTransforms, since they are highly specific to PR?

I think it makes sense to put them in a separate file (perhaps acquisition/probabilistic_reparameterization.py), since they are only used via AnalyticProbabilisticReparameterization and MCProbabilisticReparameterization.

Flexibility in dimension position - we currently assume/enforce that the dimensions are ordered continuous->discrete->categorical. Should this be relaxed, or is it okay to leave for the sake of cleaner code?

Ideally this would be relaxed, but I think we can leave that as a TODO for now if it adds to much complexity. If we do leave the ordering assumption, let's make sure we raise exceptions if the ordering is violated.

Flexibility in encoding - PR currently only supports one-hot encoding for categoricals. In #2866, I assumed that categoricals were encoded ordinally. Is there a canonical/preferred encoding for categoricals? Should both be supported?

We should only be using one-hot encoding (or potentially embeddings) for categoricals. The ordinal probabilistic reparameterization proposed in the paper really only makes sense if there is a inherent ordering to the categorical values (even if the GP is using say a categorical kernel), since to move from theta=3->theta=1 you would have to pass through 2, if an ordinal representation is used. One-hot is much more intuitive and avoids that scenario.