Require all problems to have an optimal_value; simplify Problem inheritance
#2601
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
facebook-github-bot
added
the
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D60145193 |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2601 +/- ##
==========================================
- Coverage 95.20% 95.19% -0.02%
==========================================
Files 495 495
Lines 47745 47724 -21
==========================================
- Hits 45456 45431 -25
- Misses 2289 2293 +4 ☔ View full report in Codecov by Sentry. |
esantorella
added a commit
to esantorella/Ax
that referenced
this pull request
Jul 25, 2024
…eritance (facebook#2601) Summary: Pull Request resolved: facebook#2601 Context: * Problems that lack an `optimal_value` get a NaN score and cannot really be used for benchmarking except when aggregated. This is a nasty "gotcha." We don't always know the optimum, but IMO it is better to guess. * The inheritance structure of benchmark problems is too complex and will make subsequent refactors harder. This PR: * Adds an `optimal_value` requirement to `BenchmarkProblem` and makes `BenchmarkProblem` the base class to `SurrogateBenchmarkProblem`, enabling `BenchmarkProblem` to be the only type annotation needed. Therefore, the type annotation `BenchmarkProblemProtocol` is no longer necessary. It will be removed in the next PR. * No longer allows for giving an NaN score to benchmarks where the problem lacks an optimal value, because this won't happen. * Updates a lot of annotations. * Raises an exception for constrained multi-objective problems. * Use dataclasses to cut down on code. Differential Revision: D60145193 Reviewed By: saitcakmak
esantorella
added a commit
to esantorella/Ax
that referenced
this pull request
Jul 25, 2024
…eritance (facebook#2601) Summary: Pull Request resolved: facebook#2601 Context: * Problems that lack an `optimal_value` get a NaN score and cannot really be used for benchmarking except when aggregated. This is a nasty "gotcha." We don't always know the optimum, but IMO it is better to guess. * The inheritance structure of benchmark problems is too complex and will make subsequent refactors harder. This PR: * Adds an `optimal_value` requirement to `BenchmarkProblem` and makes `BenchmarkProblem` the base class to `SurrogateBenchmarkProblem`, enabling `BenchmarkProblem` to be the only type annotation needed. Therefore, the type annotation `BenchmarkProblemProtocol` is no longer necessary. It will be removed in the next PR. * No longer allows for giving an NaN score to benchmarks where the problem lacks an optimal value, because this won't happen. * Updates a lot of annotations. * Raises an exception for constrained multi-objective problems. * Use dataclasses to cut down on code. Differential Revision: D60145193 Reviewed By: saitcakmak
|
This pull request was exported from Phabricator. Differential Revision: D60145193 |
esantorella
force-pushed
the
export-D60145193
branch
from
7d8316c to
cf6f286
Compare
esantorella
added a commit
to esantorella/Ax
that referenced
this pull request
Jul 26, 2024
…eritance (facebook#2601) Summary: Pull Request resolved: facebook#2601 Context: * Problems that lack an `optimal_value` get a NaN score and cannot really be used for benchmarking except when aggregated. This is a nasty "gotcha." We don't always know the optimum, but IMO it is better to guess. * The inheritance structure of benchmark problems is too complex and will make subsequent refactors harder. This PR: * Adds an `optimal_value` requirement to `BenchmarkProblem` and makes `BenchmarkProblem` the base class to `SurrogateBenchmarkProblem`, enabling `BenchmarkProblem` to be the only type annotation needed. Therefore, the type annotation `BenchmarkProblemProtocol` is no longer necessary. It will be removed in the next PR. * No longer allows for giving an NaN score to benchmarks where the problem lacks an optimal value, because this won't happen. * Updates a lot of annotations. * Raises an exception for constrained multi-objective problems. * Use dataclasses to cut down on code. Reviewed By: saitcakmak Differential Revision: D60145193
esantorella
added a commit
to esantorella/Ax
that referenced
this pull request
Jul 26, 2024
…eritance (facebook#2601) Summary: Pull Request resolved: facebook#2601 Context: * Problems that lack an `optimal_value` get a NaN score and cannot really be used for benchmarking except when aggregated. This is a nasty "gotcha." We don't always know the optimum, but IMO it is better to guess. * The inheritance structure of benchmark problems is too complex and will make subsequent refactors harder. This PR: * Adds an `optimal_value` requirement to `BenchmarkProblem` and makes `BenchmarkProblem` the base class to `SurrogateBenchmarkProblem`, enabling `BenchmarkProblem` to be the only type annotation needed. Therefore, the type annotation `BenchmarkProblemProtocol` is no longer necessary. It will be removed in the next PR. * No longer allows for giving an NaN score to benchmarks where the problem lacks an optimal value, because this won't happen. * Updates a lot of annotations. * Raises an exception for constrained multi-objective problems. * Use dataclasses to cut down on code. Differential Revision: D60145193 Reviewed By: saitcakmak
esantorella
added a commit
to esantorella/Ax
that referenced
this pull request
Jul 26, 2024
…eritance (facebook#2601) Summary: Pull Request resolved: facebook#2601 Context: * Problems that lack an `optimal_value` get a NaN score and cannot really be used for benchmarking except when aggregated. This is a nasty "gotcha." We don't always know the optimum, but IMO it is better to guess. * The inheritance structure of benchmark problems is too complex and will make subsequent refactors harder. This PR: * Adds an `optimal_value` requirement to `BenchmarkProblem` and makes `BenchmarkProblem` the base class to `SurrogateBenchmarkProblem`, enabling `BenchmarkProblem` to be the only type annotation needed. Therefore, the type annotation `BenchmarkProblemProtocol` is no longer necessary. It will be removed in the next PR. * No longer allows for giving an NaN score to benchmarks where the problem lacks an optimal value, because this won't happen. * Updates a lot of annotations. * Raises an exception for constrained multi-objective problems. * Use dataclasses to cut down on code. Differential Revision: D60145193 Reviewed By: saitcakmak
esantorella
added a commit
to esantorella/Ax
that referenced
this pull request
Jul 26, 2024
…eritance (facebook#2601) Summary: Pull Request resolved: facebook#2601 Context: * Problems that lack an `optimal_value` get a NaN score and cannot really be used for benchmarking except when aggregated. This is a nasty "gotcha." We don't always know the optimum, but IMO it is better to guess. * The inheritance structure of benchmark problems is too complex and will make subsequent refactors harder. This PR: * Adds an `optimal_value` requirement to `BenchmarkProblem` and makes `BenchmarkProblem` the base class to `SurrogateBenchmarkProblem`, enabling `BenchmarkProblem` to be the only type annotation needed. Therefore, the type annotation `BenchmarkProblemProtocol` is no longer necessary. It will be removed in the next PR. * No longer allows for giving an NaN score to benchmarks where the problem lacks an optimal value, because this won't happen. * Updates a lot of annotations. * Raises an exception for constrained multi-objective problems. * Use dataclasses to cut down on code. Differential Revision: D60145193 Reviewed By: saitcakmak
…k#2603) Summary: Pull Request resolved: facebook#2603 Context: Surrogate benchmark problems allow for downloading datasets and constructing a surrogate lazily. Since the surrogates and datasets are only needed for the `Runner`, it makes sense to confine this logic to `SurrogateRunner`. This gives surrogate benchmark problems an interface that is much clsoer to that of non-surrogate benchmark problems. In the future, we should be able to get down to just one `BenchmarkProblem` class. This PR: * Moves lazy construction of surrogates from the `Problem` to the `Runner`. * Moves corresponding unit tests from the problem's file to the runner's. Differential Revision: D60266288
…eritance (facebook#2601) Summary: Pull Request resolved: facebook#2601 Context: * Problems that lack an `optimal_value` get a NaN score and cannot really be used for benchmarking except when aggregated. This is a nasty "gotcha." We don't always know the optimum, but IMO it is better to guess. * The inheritance structure of benchmark problems is too complex and will make subsequent refactors harder. This PR: * Adds an `optimal_value` requirement to `BenchmarkProblem` and makes `BenchmarkProblem` the base class to `SurrogateBenchmarkProblem`, enabling `BenchmarkProblem` to be the only type annotation needed. Therefore, the type annotation `BenchmarkProblemProtocol` is no longer necessary. It will be removed in the next PR. * No longer allows for giving an NaN score to benchmarks where the problem lacks an optimal value, because this won't happen. * Updates a lot of annotations. * Raises an exception for constrained multi-objective problems. * Use dataclasses to cut down on code. Reviewed By: saitcakmak Differential Revision: D60145193
esantorella
added a commit
to esantorella/Ax
that referenced
this pull request
Jul 26, 2024
…eritance (facebook#2601) Summary: Pull Request resolved: facebook#2601 Context: * Problems that lack an `optimal_value` get a NaN score and cannot really be used for benchmarking except when aggregated. This is a nasty "gotcha." We don't always know the optimum, but IMO it is better to guess. * The inheritance structure of benchmark problems is too complex and will make subsequent refactors harder. This PR: * Adds an `optimal_value` requirement to `BenchmarkProblem` and makes `BenchmarkProblem` the base class to `SurrogateBenchmarkProblem`, enabling `BenchmarkProblem` to be the only type annotation needed. Therefore, the type annotation `BenchmarkProblemProtocol` is no longer necessary. It will be removed in the next PR. * No longer allows for giving an NaN score to benchmarks where the problem lacks an optimal value, because this won't happen. * Updates a lot of annotations. * Raises an exception for constrained multi-objective problems. * Use dataclasses to cut down on code. Differential Revision: D60145193 Reviewed By: saitcakmak
|
This pull request was exported from Phabricator. Differential Revision: D60145193 |
esantorella
force-pushed
the
export-D60145193
branch
from
cf6f286 to
0ce9083
Compare
esantorella
added a commit
to esantorella/Ax
that referenced
this pull request
Jul 27, 2024
…eritance (facebook#2601) Summary: Pull Request resolved: facebook#2601 Context: * Problems that lack an `optimal_value` get a NaN score and cannot really be used for benchmarking except when aggregated. This is a nasty "gotcha." We don't always know the optimum, but IMO it is better to guess. * The inheritance structure of benchmark problems is too complex and will make subsequent refactors harder. This PR: * Adds an `optimal_value` requirement to `BenchmarkProblem` and makes `BenchmarkProblem` the base class to `SurrogateBenchmarkProblem`, enabling `BenchmarkProblem` to be the only type annotation needed. Therefore, the type annotation `BenchmarkProblemProtocol` is no longer necessary. It will be removed in the next PR. * No longer allows for giving an NaN score to benchmarks where the problem lacks an optimal value, because this won't happen. * Updates a lot of annotations. * Raises an exception for constrained multi-objective problems. * Use dataclasses to cut down on code. Differential Revision: D60145193 Reviewed By: saitcakmak
esantorella
added a commit
to esantorella/Ax
that referenced
this pull request
Jul 28, 2024
…eritance (facebook#2601) Summary: Pull Request resolved: facebook#2601 Context: * Problems that lack an `optimal_value` get a NaN score and cannot really be used for benchmarking except when aggregated. This is a nasty "gotcha." We don't always know the optimum, but IMO it is better to guess. * The inheritance structure of benchmark problems is too complex and will make subsequent refactors harder. This PR: * Adds an `optimal_value` requirement to `BenchmarkProblem` and makes `BenchmarkProblem` the base class to `SurrogateBenchmarkProblem`, enabling `BenchmarkProblem` to be the only type annotation needed. Therefore, the type annotation `BenchmarkProblemProtocol` is no longer necessary. It will be removed in the next PR. * No longer allows for giving an NaN score to benchmarks where the problem lacks an optimal value, because this won't happen. * Updates a lot of annotations. * Raises an exception for constrained multi-objective problems. * Use dataclasses to cut down on code. Differential Revision: D60145193 Reviewed By: saitcakmak
|
This pull request has been merged in 1bcaacd. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
Context:
optimal_valueget a NaN score and cannot really be used for benchmarking except when aggregated. This is a nasty "gotcha." We don't always know the optimum, but IMO it is better to guess.This PR:
optimal_valuerequirement toBenchmarkProblemand makesBenchmarkProblemthe base class toSurrogateBenchmarkProblem, enablingBenchmarkProblemto be the only type annotation needed. Therefore, the type annotationBenchmarkProblemProtocolis no longer necessary. It will be removed in the next PR.Reviewed By: saitcakmak
Differential Revision: D60145193