fix: equality comparison where assignment was likely meant #979
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.
As per #976, it looks like in this code in
IPNewton
:Optim.jl/src/multivariate/solvers/constrained/ipnewton/ipnewton.jl
Lines 282 to 288 in adc5b27
...the line
state.ev == equality_violation(constraints, state)
probably meant assignment, not an equality test:true
orfalse
), but it's not, which means that the result of comparison is not used.state.ev
is supposed to be a number, most likely a floating-point, but comparison of floats for equality can fail, because of rounding errors, so this equality test seems suspicious.I changed it to assignment, and all tests still pass.
However, it seems like using assignment doesn't change much:
optimize
first callsupdate_state!
, which seems to leavestate.ev
unchanged (without my "fix"). Then, however, it immediately callsupdate_fg!
:Optim.jl/src/multivariate/solvers/constrained/ipnewton/interior.jl
Lines 250 to 252 in 1189ba0
update_fg!
, however, does updatestate.ev
:Optim.jl/src/multivariate/solvers/constrained/ipnewton/ipnewton.jl
Lines 176 to 179 in 1189ba0