Check feasibility of solutions in PrimalStatus and DualStatus

[odow]

Closes #546

This is one option, but I don't really like it, because it relies on magic constants. Is there a way for Gurobi to tell us whether the problem is feasible according to any parameters the user has set?

[codecov]

Codecov Report

Attention: Patch coverage is 93.75000% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 80.48%. Comparing base (3a6a83e) to head (ae1e4a9).

Files	Patch %	Lines
src/MOI_wrapper/MOI_wrapper.jl	93.75%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #548      +/-   ##
==========================================
+ Coverage   80.36%   80.48%   +0.11%     
==========================================
  Files           6        6              
  Lines        2908     2936      +28     
==========================================
+ Hits         2337     2363      +26     
- Misses        571      573       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[blegat]

The other option is to just return UNKNOWN_RESULT_STATUS

[odow]

Always returning UNKNOWN_RESULT_STATUS will break returning a feasible point on a time limit.

[odow]

Support confirm there is nothing in the API for this, so I guess we're stuck with a magic constant.

[simonbowly]

Support confirm there is nothing in the API for this, so I guess we're stuck with a magic constant.

Why compare with a hard-coded constant instead of the tolerance parameters set by the user?

[odow]

instead of the tolerance parameters set by the user?

I mean, we could. But then we'd need to loop through all tolerances and all violations and account for any nasty differences between algorithms etc (without being able to know what they are). It'd turn into the function I want in the C API that you're running up the flagpole...

[simonbowly]

Sure, this is more to point out that the default tolerances are 10^-6, so you can expect a lot of false conclusions with a hard coded 10^-8. But now I see @blegat's suggestion above for a jump-side parameter.

[odow]

Yeah we wouldn't actually hard-code. And 1e-8 is just a placeholder.

[odow]

Okay, how's this. I assumed that is sufficient to check only ConstrVio, BoundVio, and IntVio.