Conversation
|
Okay. I've gone full Rambo and refactored everything so this is breaking. I've also removed many of the "option" controlling attributes. I don't think we want flexibility in how the algorithm runs. We want a simple set-and-forget. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #34 +/- ##
==========================================
+ Coverage 95.44% 97.05% +1.61%
==========================================
Files 4 2 -2
Lines 395 340 -55
==========================================
- Hits 377 330 -47
+ Misses 18 10 -8 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This commit is breaking because it: * Removes SkipFeasibilityCheck * Removes StopIfInfeasibleBounds * Removes StopIfInfeasibleRanges * Removes DeletionFilter * Removes ElasticFilterTolerance * Removes ElasticFilterIgnoreIntegrality In addition, this commit will likely result in a different IIS being returned for many models because it now exploits an infeasibility certificate if one is present.
| # Use of this source code is governed by an MIT-style license that can be found | ||
| # in the LICENSE.md file or at https://opensource.org/licenses/MIT. | ||
|
|
||
| # This type and the associated functions were inspired by IntervalArithmetic.jl |
There was a problem hiding this comment.
Hehehe, I had this file originally, then we merges with range.jl XD
| function _feasibility_check( | ||
| optimizer::Optimizer, | ||
| infeasible_model::MOI.ModelLike, | ||
| ) |
There was a problem hiding this comment.
a solver may say a model is feasible, eventhough its not, that was the reasoning behid the skip.
Maybe the manual needs to tell the user to run before solving in this case.
| return | ||
| elseif !_in_time(optimizer) | ||
| return | ||
| end |
There was a problem hiding this comment.
I think this stops to early and fails to give the user the full picture it could give.
This is doing: you asked for something that might be wrong, here is something, but I am lazy and I will not tell you more before you fix that.
Which, IMO, is bad to upstream packages that want to tell user about all messy data asap, instead of requiring multiple steps and re-runs to fix issues.
I do understand you want to minimize the number of knobs.
This was not the original intent, but I think we can have some in-between solution with a flag:
StopFast (to stop as soon as something is found) or ExhaustiveSearch (to do more work until time is done).
We can send the user data from 1) bounds and 2) intervals at the same time and they will be different and helpful.
Indeed, if one of these find issues we do not need to go to ElasticFilter.
| # looping through the candidates one-by-one, we could use a bisection search | ||
| # to reduce how many searches we need to loop through. | ||
| # ========================================================================== | ||
| for con in copy(iis_candidate) |
There was a problem hiding this comment.
this can be waaaaay slower, thats why skipping.
time limit might be just fine.
There was a problem hiding this comment.
that could be good for this one!
2 participants
This commit is breaking because it:
In addition, this commit will likely result in a different IIS being
returned for many models because it now exploits an infeasibility
certificate if one is present.