Open benthestatistician opened 3 years ago
Notes:
fullmatch_try_recovery
option again becomes reasonable. The LEMON project's max flow finder is documented under the "Preflow" heading. An interface to this function is currently available via rlemon::MaxFlow()
. I note this @adamrauh's reference, as well as for other future contributors considering helping us at moving this sub-project along.
I have a couple questions, for @josherrickson or someone else better situated than me to parse possibilities of our interaction with LEMON.
init()
and startFirstPhase()
as opposed to run()
or runMinCut()
, you can get it to skip the second phase and just return the max flow value. The rlemon
package interfaces with these routines with code in src/max_flow.h#L62-L104rlemon
, max flow and min-cost flow both seem to begin by calling ListDigraph to set up the problem: compare code snippet above to, say, the NetworkSimplexRunner
code. I wonder if there might potentially be further efficiencies to be realized by designing a specialized version of the call to LEMON that set up one and the same Digraph for a max flow problem, first, and then for a min-cost-flow problem that would come afterwards if the max flow value was found to be sufficiently large (otherwise just returning the desultory max flow value).Adding custom algorithms to rlemon would be pretty easy, from the R side.
The C code would be (to me at least) the challenging part. I can take a crack at it, but I'd be more than happy to let @nullsatz go at it. I can help with the R side of course.
The process we call "infeasibility recovery" would ideally be maximizing the
mean.controls
parameter (i.e. seeking out the smallest feasibleomit.fraction
, as opposed to just settling for some feasible value ofmean.controls
as is currently done. I.e., it should be mapped to a max-flow problem, as distinct from min-cost flow.To do's: