Safer parameter boundary enforcement #141
Merged
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.
This PR introduces some changes to help ensure that parameter values always remain within their allowed range. This can be an important safety check because the values suggested by M-LOOP are often used to adjust settings for real hardware. Ideally the user's driver code should make it impossible to set that hardware to dangerous value regardless of what M-LOOP requests, but it doesn't hurt to have M-LOOP be extra careful to remain within its user-imposed limits. These checks are particularly important given that M-LOOP supports using third-party controllers/learners. The particular changes to enforce this check are enumerated below.
Changes proposed in this pull request:
Learner.put_params_and_get_cost()
will now raise aRuntimeError
if its suggested parameter values are outside of the allowed boundaries.Controller._put_params_and_out_dict()
now checks that parameter values are within the allowed boundaries before sending them to the interface to be tested experimentally.