Add objective_value method to SolvedModel
#29
Conversation
|
The CI is failing because of new I've opened a separate PR to fix those warnings (#30); that should be merged first. |
Add a method to `SolvedModel` to retrieve the objective value for the solution. If the model failed to solve, this value may not be meaningful. Closes rust-or#25.
alexdewar
force-pushed
the
objective-value
branch
from
575eb15 to
680b9bc
Compare
|
Rebasing to fix CI warnings |
|
Hi @lovasoa. I think this is ready for review now, if you've got a chance. |
|
Is this safe ? I see this is wrapping an unsafe function in a safe method, and I don't think highs guarantees calling the function is always safe (in the rust sense of the term). The following comment in particular makes it sound that the function may be accessing uninitialized memory. If the function is safe to call in all cases, then we should always be able to document what it returns. If it is not well-defined in some cases, then we cannot wrap this in a safe function.
|
|
I think it’s safe. In case of infeasibility, the value doesn’t have meaning, but there is no undefined behavior. The unsafety is on the validity of the pointer, which is guaranteed to be valid by the abstraction. |
|
Yes, this is memory safe. As @TeXitoi says, there is no undefined behaviour: the function will still return a value, even if the optimisation fails. After your comment, I did wonder whether the internal variable storing the objective value was maybe left uninitialised in the error case (which would be memory unsafe), so I checked and it seems to always be initialised to zero: https://github.com/ERGO-Code/HiGHS/blob/8c76346b42e8ff4b555ba40a7a163921c21e827d/highs/lp_data/HighsInfo.h#L227 As it always has a default value, the function is safe to call even in the error case. |
|
Ok, good ! Then let's maybe document that the value is zero in these cases, and add tests for it ? |
| /// Get the objective value for the solution. | ||
| /// | ||
| /// If the model failed to solve, this value may not be meaningful. | ||
| pub fn objective_value(&self) -> f64 { |
There was a problem hiding this comment.
How about changing the return type to Option<f64>? I feel like this would be a lot more intuitive than having to check manually whether the value is meaningful or not. It also feels a bit more rusty?
Just throwing this suggestion into the discussion from the sideline, feel free to ignore me if you have a strong opinion about it.
There was a problem hiding this comment.
I agree in general (zero is a pretty crap default value), though I am wondering if there are cases where the user might want the objective value when the HighsModelStatus isn't Optimal (i.e. it hasn't fully converged). I'm not sure what HiGHS would do in this case.
What do you think @lovasoa? Are you happy to return None if the status is anything other than optimal?
There was a problem hiding this comment.
An alternative would be to panic if the status is not optimal, then the onus is on the user to ensure this doesn't happen.
There was a problem hiding this comment.
Ideally the behavior should match what highs does ? Return None in situations where Highs does not set the value, return Some when highs does have a value
There was a problem hiding this comment.
You definitively want the objective if the search stopped before proving the optimality. The case where this value would be meaningless are unfeasible, unbounded, and no feasible solution found.
There was a problem hiding this comment.
@lovasoa I'm assuming you'd still like to return None in the case that no error has occurred?
Looking at HighsModelStatus, I think the following statuses would indicate that there is a meaningful objective value:
OptimalObjectiveTargetReachedTimeLimitReachedIterationLimit
(We could also include Unknown if we want to be conservative.)]
So if we want to return an Option<f64> from this method, we could return Some(objective_value) if the status matches any of the above, else None.
HOWEVER: I'm not totally confident that an objective value would not be returned for certain other statuses, such as SolveError. It would be good to have this confirmed.
Alternatively, we can just update the doc comment to state that zero may be returned in case of error and put the responsibility back onto the user to check the status before using this value.
Let me know what you prefer.
There was a problem hiding this comment.
I'm fairly certain that the objective value - as with everything in Highs::info_ - always has a value, since it's cleared when HiGHS:: run() is called. I'll confirm tonight, when I'm at a computer
There was a problem hiding this comment.
Thanks for the response @jajhall! I've noticed it seems to have a value of 0.0 when the model is infeasible, for example, but I'm not sure about other cases. I assume zero is the default value.
I think the suggestion here was that we could return None instead for cases where there isn't a meaningful objective value, as that's maybe a bit more "Rust-y" (it would help prevent accidental use of the value in cases where the model is infeasible etc.). But we could just return the value given by HiGHS and mention that it might be zero in case of error in the documentation, which I think would also be fine. That would have the advantage of being simpler and not requiring changes if new statuses are added to HiGHS in future.
There was a problem hiding this comment.
I'm okay with both solutions. If we have a guarantee that Highs_getObjectiveValue does not access uninitialized memory even in cases when no value is available, then we can just return an f64, and be clear about its value in the documentation in all cases.
There was a problem hiding this comment.
That sounds simplest. I'll update the docs and add a test as you suggest.
|
thanks ! |
|
Thanks for looking at it 😄! Out of interest, were you planning on making a release any time soon? No pressure, but I'd like this feature for a downstream project. If there's going to be a release soon, I'll hold off until then, otherwise I'll just pin to |
|
Just published a new version. Thanks for your contribution ! https://crates.io/crates/highs/versions |
|
Lovely! Thank you v much 😄 |
Add a method to
SolvedModelto retrieve the objective value for the solution. If the model failed to solve, this value may not be meaningful.I considered putting this value in
Solutioninstead, but I'm not sure we necessarily want to retrieve it every time we solve a problem, particularly as there are other potential output parameters that may be useful and if we add those then we'd also have to bundle those intoSolutiontoo to be consistent. This seemed the simplest way.Closes #25.