-
Notifications
You must be signed in to change notification settings - Fork 10
Resolve R2 Allocation test #164
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
Resolve R2 Allocation test #164
Conversation
src/utils.jl
Outdated
stats = GenericExecutionStats(reg_nlp.model, solver_specific = Dict{Symbol, T}()) | ||
set_solver_specific!(stats, :smooth_obj, T(Inf)) | ||
set_solver_specific!(stats, :nonsmooth_obj, T(Inf)) | ||
set_solver_specific!(stats, :xi, T(Inf)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn’t dual_feas
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By dual feasibility, we mean the gradient of the Lagrangian (for smooth problems). Here, the corresponding concept is
@dpo we should be good now I think. |
@dpo @MohamedLaghdafHABIBOULLAH
I think this solves #161.
I added a function that constructs a
GenericExecutionStats
on aRegularizedNLPModel
.solver_specific entries are added during the construction, this removes the allocation in
solve!
caused by adding an uninitialized solver_specific entry in stats.Also, for type stability, I had to specify that solver_specific entries are the same type as the one added in this new constructor, else there are allocations as well. This might cause issues if used without care.