-
Notifications
You must be signed in to change notification settings - Fork 35
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
[WIP] Create specific operator for hprod #423
base: main
Are you sure you want to change the base?
Conversation
I don't like the
|
This is looking good, thanks!
Could it be another constructor? |
Ok, so if I understand. Whenever we reimplemented If we want to reuse the structure for another |
Some comments on the comments
Yes, I think it will be necessary, but only models that feel the need to update
Maybe we need a solver = TrunkSolver(nlp) # solver.H exists
nlp = Problem1()
output = solve!(solver, nlp)
# do things
nlp = Problem2()
### Option 1: Update solver.H ???
### Option 2: Update solver
output = solve!(solver, nlp) Option 1 requires specific knowledge of the solver. Option 2 can be a no-op for many solvers. Also, we can accept keyword arguments to update other solver aspects, like subsolver.
Not like this, because |
Codecov ReportBase: 99.50% // Head: 98.66% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #423 +/- ##
==========================================
- Coverage 99.50% 98.66% -0.84%
==========================================
Files 13 14 +1
Lines 801 823 +22
==========================================
+ Hits 797 812 +15
- Misses 4 11 +7
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
First jab at avoiding the implicit change of
hess_op
is up for discussion.To use it on a code like Trunk, instead of writing
H = hess_op!(nlp, x, Hv)
, we will just writeH.x .= x
. We can probably wrap that underupdate!(H, x)
, but it does not seem necessary.Issues:
x
to create anHprodOperator
, but that could be changed, if we want to. The API is becoming too convoluted, though.hess_op!
withrows, cols, vals
will still suffer from the same implicit issue, unless we also create aHprodOperator
for it.