Cache whether solution has a FEASIBLE_POINT #178
Conversation
add has_feasible_point flag
src/MOI/MOI_wrapper.jl
Outdated
| @@ -229,7 +231,7 @@ mutable struct Optimizer <: MOI.AbstractOptimizer | |||
|
|
|||
| # TODO: add functionality to the lower-level API to support querying single | |||
| # elements of the solution. | |||
|
|
|||
| optimizer_called::Bool | |||
There was a problem hiding this comment.
We shouldn't need to add this flag. It's okay for the optimizer to return a previous solution, even if the problem was modified. (JuMP handles these checks so the solvers don't need to: https://jump.dev/JuMP.jl/stable/manual/solutions/#OptimizeNotCalled-errors.)
The test you found was a bit weird, but it wasn't necessarily wrong. Is there a larger problem than the test that you found in your own code?
There was a problem hiding this comment.
I think I had some errors because I was using Xpress 8.5 and ended up adding unnecessary things.
I am solving multiple problems in sequence. But every time I query variable values Xpress has to go through MOI.get(model, MOI.PrimalStatus()), which has become a bottleneck.
I would just like to create a cache so I don't have to call this function so many times. I removed all the lines about optimizer_called and left only the has_feasible_point cache.
There was a problem hiding this comment.
Okay, that makes sense. Can you post a screenshot of the tests passing? You don't have permission to run the CI under your account.
odow
changed the title
|
Why'd you close? 😆 |
|
@odow Sorry, I thought about renaming my branch, because the current name doesn't make sense anymore. But that closed the PR automatically. |
|
|
Querying solution values involves many checks to see if the attribute like
VariablePrimal(result_index)is within the number of available results. This requires a call to get thePrimalStatus, which can be expensive. This PR adds a cache for the primal status to improve things.