Implement `AxClient.get_best_parameters`, returning the parameter configurations on the Pareto frontier
See original GitHub issueHello again!
I’ve reviewed 22acc17 and every change is excellent! I do however find one thing missing from the API, I cannot find an obvious way to get the points on the Pareto frontier. On the one side, gest_best_parameters is deprecated for multi-objective optimization, returning a random point on the Pareto frontier. On the other, compute_posterior_pareto_frontier requires primary and secondary metrics (the reason for which I am not sure I fully understand).
Am I missing a method/function?
Certainly, one could manually compute the Pareto frontier with get_trials_dataframe, but that doesn’t look like an optimal solution.
Edit: For reference, in #654 the example uses compute_posterior_pareto_frontier
with only two objectives.
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
ax.service - Adaptive Experimentation Platform
Calculate hypervolume of a pareto frontier based on either the posterior means of given observation features or observed data. Parameters: optimization_config – ...
Read more >Find points in Pareto set - MATLAB paretosearch - MathWorks
Obtain the Pareto front in both function space and parameter space by calling paretosearch with both the x and fval outputs. Set options...
Read more >Pareto front - Wikipedia
In multi-objective optimization, the Pareto front is the set of all Pareto efficient ... rather than considering the full range of every parameter....
Read more >TunePareto: Multi-Objective Parameter Tuning for Classifiers
ing functions and calculates the Pareto front of optimal parameter configurations. The Pareto fronts can be visualized using plotDominationGraph, ...
Read more >Towards Pareto-Optimal Parameter Synthesis for Monotonic ...
For example, it is possible that a configuration that is ... Pareto front on the space of parameter valuations that satisfy a parameterized...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@josalhor, that’s right, it is for plotting I believe. We’ll add improving on this to our feature requests!
Hi again!
In the meantime, I share how I calculated the points on the frontier in case anyone else is in the same situation / the maintainers want to take a look.
Here is the source code: https://gist.github.com/josalhor/8ca386f0902f1523e0ee4cd17e337b37
I provide a couple of implementations, a basic one with nothing fancy and one that introduces the concept of virtual points. This should reduce the cost of computing the frontier in case the frontier gets big but remains proportionally small with respect to the number of points probed.
I’ll take the opportunity to explain it. Let’s define the Virtual Best Point (VBS) as the least restrictive point that would dominate each point on the frontier. Any point that pareto dominates the VBS will automatically dominate the whole frontier, so we don’t need to compare for each point. By reflection, we could define a Virtual Worst Point (VWP). If the VWP dominates any new point, then the new point cannot be in the frontier.
If necessary, one could generalize this even further, defining Virtual Points that dominate only subsets of the points on the frontier. This would create a tradeoff between the overhead of the virtual points and the decreased complexity of not comparing to each point on the frontier unless required.
I didn’t spend too much time on this, but I can’t find a trivial way to decrease the complexity under
O(n * k * d)
wheren = nº points
k = average nº points on the frontier
d = nº dimensions
. Edit: I’ve found a way, but the solution requires thorough knowledge of the relationship between the points of the frontier.This code is clearly not up to the standard of the library (ignores status quo, absolute_metrics, type hinting etc). But it was a fun exercise anyways.