ENH: constraint violation #9990
Conversation
|
This PR is part of a roadmap to apply constraints to |
…inuous_basic.py. Added test_nomodify_gh9900_regression() to simulate thread interleaving. Added test_broadcast_gh9990_regression() to validate broadcast for out-of-support arguments, and to check support endpoints.
…inuous_basic.py. Added test_nomodify_gh9900_regression() to simulate thread interleaving. Added test_broadcast_gh9990_regression() to validate broadcast for out-of-support arguments, and to check support endpoints.
|
test fail is a timeout. |
There was a problem hiding this comment.
Looks sensible to me. Only a few minor comments. The .fun.fun is a bit unfortunately, the first .fun could have been named better. But that can't be easily changed anymore.
I'm not very familiar with this code, so I'll let @mdhaber or someone else comment on whether the added methods fit the overall design here.
|
@antonior92 thoughts? |
|
First thought - when constraints are active they are not always satisfied strictly, so I would suggest adding a tolerance. |
|
@mdhaber, @antonior92 I'm not familiar with how constraint tolerances are specified/used elsewhere in This PR is a prerequisite for #10002, where such tolerances aren't needed (not mentioned in the paper I'm basing the modifications on). In fact all that's needed from this PR is the |
|
By what I understood we do not need Besides that, |
|
Based on feedback from @antonior92 the recent commit:
|
|
Great! +1 for merging this and moving on to #10002... |
|
|
||
| assert_array_equal(pc.violation([0.5, 1]), [0., 0.]) | ||
|
|
||
| np.testing.assert_almost_equal(pc.violation([0.5, 1.2]), [0., 0.1]) |
There was a problem hiding this comment.
For consistency with assert_array_equal, we should probably import assert_almost_equal at the top level. But, pretty minor point.
| """ | ||
| with suppress_warnings() as sup: | ||
| sup.filter(UserWarning) | ||
| ev = self.fun.fun(np.asarray(x)) |
There was a problem hiding this comment.
Would it be harmful to pass subclasses through with np.asanyarray? Don't know if that ever happens in practice / is useful for optimize stuff, so maybe just confirm.
There was a problem hiding this comment.
The array-like is passed to a user defined function, so it would be up to that user defined function as to whether it was acceptable. Internally differential_evolution uses np.float64, so the array will be that dtype. However I think internally other minimizers can use other dtypes.
There was a problem hiding this comment.
I was just a little worried that we might clobber ndarray subclasses with the choice of asarray instead of asanyarray, with no strong reason to chose the former.
Anyway, the reviews here are positive and there's a +1 from expert reviewer so in it goes!
|
Not sure if the release notes need a sentence for this PR? Please add one, if appropriate. |
Assesses whether constraints are feasible for a given solution vector (
scipy.optimize._constraints.PreparedConstraint.is_feasible()), and also adds a method to calculate how much each of the constraints are exceeded by (scipy.optimize._constraints.PreparedConstraint.excess_violation())