Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support best value with constraint #5184

Closed
hrntsm opened this issue Jan 14, 2024 · 2 comments · Fixed by #5426
Closed

Support best value with constraint #5184

hrntsm opened this issue Jan 14, 2024 · 2 comments · Fixed by #5426
Labels
feature Change that does not break compatibility, but affects the public interfaces.

Comments

@hrntsm
Copy link
Contributor

hrntsm commented Jan 14, 2024

Motivation

Study's best_value (or best_xxx) will output a value that does not consider the constraint, even if they exist.
I want to output the best value that takes into account the constraints.

Description

For example, best_trials gets COMPLETE trials and creates pareto front trials, but by making it trials that is COMPLETE and feasible, the best_trials including the constraint condition is obtained.

trials = [trial for trial in trials if trial.state == TrialState.COMPLETE]

However, since there are multiple codes related to Study.best_xxx, is it possible to implement them?
Let me know if you have any concerns.

Alternatives (optional)

No response

Additional context (optional)

No response

@hrntsm hrntsm added the feature Change that does not break compatibility, but affects the public interfaces. label Jan 14, 2024
@not522
Copy link
Member

not522 commented Jan 15, 2024

Thanks for the suggestion. I think it is an important feature, but there are a couple of points that need to be discussed.

I have two concerns: first, the loss of backward compatibility with this improvement, and second, the difficulty of efficient implementation at the storage layer.

It is debatable, but since constrained optimization is an experimental feature, backward compatibility may not be too much of a concern. Also, efficiency can be ignored, at least in the current situation.

In my opinion, I am in favor of implementing this feature in the Study's methods with UserWarning.

@hrntsm
Copy link
Contributor Author

hrntsm commented Jan 19, 2024

Thanks for the reply.
I will try to implement it and ask again if there are any questions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Change that does not break compatibility, but affects the public interfaces.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants